So the way that we, as web developers, create apps has vastly changed over the past few years. We've started to value more tools over trivia. We value things that can actually help our workflows on a daily basis more than little things that we can perhaps try out in a browser for just a few minutes, like fun demos.
Now, today I'm going to be talking about the bleeding edge of tooling on the front end. And we can't talk about the bleeding edge without going back in time for a few minutes. So we're going to rewind back to 1996.
Now, I first started developing sites using GeoCities. How many people in the room were creating sites back in 1996? There are quite a few people. There are lots in the audience.
Now, back in 1996, this was considered the bleeding edge. It didn't give you a lot. Everybody got their own little personal space on the web, and you were able to go and create sites. You had access to JavaScript, very basic HTML and CSS. At that time, this was considered the most advanced HTML editor that was available. It's basically a text area. Imagine having to code using just a text area these days. No auto-complete, no syntax highlighting, nothing.
Back in 1996, if I wanted to actually start creating an app, I would have to do all of this fun stuff. [applause]
And then, a few years later, it got a little bit better, if you consider better being this, which is so fun and awesome...I really miss this. I don't know if this validates at all, but I'm so glad that I don't have to deal with this crap anymore. I've broken my clicker.
Now, we can't just be using text areas. It's 2012; it's not 1996 anymore. And the tooling that we use for creating web apps has greatly changed. There are a lot of tools that we use these days, and it can be difficult to try integrating them and getting them all to work nicely together. And tools, regardless of whether they're currently in your workflow or not, always have to be reviewed every once in a while, because they have to be changed if they won't evolve.
You should be reviewing your toolkit and the things in your workflow every couple of months to see if you're using the most optimal options that are available, because your workflow's very important. Every single thing that takes more time in your workflow is time that you're going to have to continue to waste on every new project. So you want to optimize that.
So, when you got up in the morning, perhaps not on the conference day, but normally when you get up, you wake up, you brush your teeth, you go get some breakfast, maybe check your email. Of course you check your email; you're developers.
But that's a workflow. We've trained our bodies and we've trained ourselves to go and do repetitive tasks in an optimal way. We know exactly what we need to do to try getting to work earlier or to try catching the fastest train. And I think David Kahneman had this great quote "We're creatures of habit. By intuition, we remember steps in our workflow and their order."
Now, if we can train our body to follow a workflow, why can't we do the exact same thing with our development workflow? I think that craftsmanship is about choosing tools well. It's the difference between a developer that spends 45 minutes setting up at the start of every new project, going and getting all of the base assets they need, like HTML5 Boilerplate and Modernizr, and whatever MVC framework you're using, if you're using one, and getting everything else set up.
And the person that only spends five minutes doing that...Because they already know what their workflow is; they've captured it in such a way that they can just easily repeat it every time they're starting out a new project. That person can start prototyping in less than 10 minutes. They can spend the rest of that hour actually building something that works. And that's what you want to be. You want to be that person that only has to spend five minutes getting set up.
Rebecca Murphy, who is going to be speaking at the conference and is a really awesome JavaScript developer, had this quote from the past year. She said that "We're seeing the emphasis shift from valuing trivia to valuing tools."
Why is this important? Developers are caring less and less about things like, "Hey, maybe there are six or seven ways that you can namespace in JavaScript," to actually caring about tools that can help them on a daily basis, to save time. Because the less time that you have to spend doing your repetitive tasks, the more time you can spend actually building awesome things, and that's what you want to be able to do.
Michael Lopp had this awesome quote as well. He said that "As an engineer, there has to be as short list of tools you must be rabid about," foaming crazy at the mouth about, tools that you wouldn't want to be without when you're starting out a new project.
And you want to know what those tools are. You don't want to be in a position where you start off a new project and you then go and you spend a few hours trying to explore, every single time "OK, what's the new set of tools I should be using?" You want to know what those tools are in advance and just be able to easily replicate your setup each time.
Paul Irish put together this really awesome graph that tries to capture tooling in a web developer's life cycle at the moment. And there are lots of pieces to it. We start off with boilerplate, so things like HTML5 Boilerplate. We then work through to abstractions, so Sass, CoffeeScript and so on. You then have your frameworks if you're building an app. Maybe you're using an MVC framework these days. You have iteration workflows, so maybe you're using tools like CodeKit.
How many people here use CodeKit? OK, so there are a few. Maybe you're using the Chrome Dev Tools. Maybe you're using other tools. You then have performance tuning. Chrome Dev Tools helps with that, but you can also have CPU profiling as well. Build and optimization and deployment.
But there is a lot of stuff to this, and it can be difficult for individual developers to actually go and put together a workflow that does all this stuff for them in a nice way every single time. So we're going to take a look at a typical tooling workflow for web app developers these days.
The first thing you want to do is make your shell sexy. There is actually this great quote from Stephen Hay, who I believe is also speaking at Fronteers. I think this was from Smashing Conf. He said, "Learn to love the command line, because it isn't scary. You know how to use Photoshop, which has 300 buttons. That's scary."
So I would encourage you. I used to be afraid of the command line as well. But over the past couple of years, I've warmed up to it, and it's actually really awesome. You save yourself a lot of time using it.
And what do I mean when I say "Make your shell sexy"? Well, this is what my shell looks like at the moment. And what you'll notice is that it's actually very well color-coded. Every piece of data that's on the screen at the moment has a different color.
I know what user I'm logged in as, what system I'm on, what directory I'm in. And because I'm currently in a GitHub repo on my system, I can actually see what branch I'm on as well. So I can easily switch between lots of different branches, merge one thing from somewhere else and so on, and always know where exactly it is that I am.
And this stuff is useful, because outside of your editor, if you're using modern tools, chances are you will be spending some time at the command line, and so it's always good to try help in improving your experience in there.
How many people here use Dotfiles (dotfiles.github.com)? So, a decent number of people here use Dotfiles. If you're not using Dotfiles, do. Dotfiles will basically help you capture a lot of the configuration that you might have for your shell and Bash and so on. But it's extremely useful.
If you take a look at the Dotfiles community on GitHub, you'll see that some speakers from Fronteers are actually on this list. Mathias Bynens has got one of the most popular sets of Dotfiles that are available. And some of my favorite stuff that's in there includes the ability to do things like just go into any directory, type in "server" and automatically start up a new local server that's hosting my content. I don't have to go use MAMP.
I don't have to go write any custom scripts. I can just go into any directory and serve it up.
Aliases. How many people here actually have custom aliases set up for use? OK. Next year I want to see almost everyone doing this. Aliases are amazing. Imagine how many letters there are in the alphabet and how many numbers there are. If there are any commands that you find yourself using on a daily basis, there is no reason why you can't alias those to just single letters. You won't have to type out complete commands or anything like that, and it's extremely useful.
You can also alias some pretty cool things. So how many people here use BrowserStack or have heard of BrowserStack before? Just a few people.
OK. So for people who haven't heard of BrowserStack, it's quite awesome. BrowserStack is basically a cloud-based way to test apps and sites. And where a lot of people actually go and set up virtual machines whenever they want to test out IE on specific versions of Windows, or Chrome or Firefox or other browsers. BrowserStack allows you to do these things in the cloud.
Now, whenever I'm testing stuff, whether it's local or something on the web, I can just use an alias. So here I want to launch Windows seven using IE8. It's already gone and set me up. I click "start" and this is now rendering in the cloud the Fronteers website. There we go. Which is really, really nice. If I'm doing mobile development, I can just do something quite similar. I can say, "OK, well, I want to load iOS with an iPad three setup, also displaying Fronteers."
There we go. It's going to load up an emulator. If the WiFi was better it would. I can easily load up emulators as well. I don't have to do anything with virtual machines myself because I can easily just call any directory or any site and have them load up in browser stack. Also take a look at auto completion scripts. Imagine not having to worry about remembering a lot of the geek commands, just being able to say I kind of remember the first letter or two, tab and have those automatically complete.
There are bash scripts, and I'll give you the links to these later on, but there are some really nice bash scripts that will give you auto-completion for a ton of the tools that you're regularly using. I advise you to check them out. They're pretty cool.
The next thing that developers really need to pay attention to is the editors that they're using. How many people here are using Sublime Text? Sublime Text is my editor of choice. I'm really glad to see so many people in the audience using it. Consider your editor a lot like an onion application. You should be able to peel the layers on that back and keep discovering new functionality.
I've been using Sublime since it first came out and I still find that every month there are new stuff in there I didn't know it could do and it's really, really awesome because I know that I am constantly improving my workflow in some way. You should prioritize your familiarity with your editor, whatever it is, whether it's WebStorm or Sublime Text. I know there are some people that will also be using some things like Eclipse or variants of it so familiarize yourself with it.
Make sure that you know it inside out because it's the tool that you'll be spending the most time in as a developer. Here are some of the things I've learned over the past year. Sublime Text packages, for people who haven't actually used it that much, are really amazing. You can just go and type in install package. It can't load up Sublime for some reason. Normally you can load up Sublime packages and take a look at the entire list of what's available. OK, the server is down.
Sublime also has a really, really great build system. How many people here using Sublime actively used Sublime build system? I'm seeing three or four hands. Imagine all of those commands you might be using at the command line. You might not necessarily want to be going from your editor back to the command line and so on back and forth. You can actually integrate a lot of the common commands that you use into Sublime and have those called using just some key bindings.
One thing that Sublime supports is custom build systems and this is what it looks like. This is a very, very basic one for a build tool called grunt. All we're doing is passing the name of the binary that we actually want run, we're passing some parameters to it, so no color in this case, and then we're setting the scope for the build process. We're just saying what files is it that we want this to look at in our current directory.
If I'm inside a new project, I can then simply go to tools, select a build system, so in this case grunt, and then just command B or build from the menu and it'll actually pipe that through grunt. Yesterday at my workshop there were a number of people asking that's awesome, what if I want to do this for unit testing and have a menu item in Sublime for my unit testing?
All you have to do in this case is add some custom parameters. Grunt's key unit will run that for you. You can easily run your commands, whatever they are, in your workflow easily from Sublime. It's quite nice. How many people here use Zen coding? A few. Zen Coding is awesome. Recently, Zen Coding, they had a really good plug-in for Sublime, and that project has sort of evolved into a new one called Emmet. If you're not using Emmet at the moment, I advise you to check it out.
So basic Zen Coding allows you to do things like this. So I'm currently in a markup file. Let's say that I want to create a new list and inject some links in there. So all I've had to do is tap. I didn't have to go in and manually write out each line or anything like that. And in just a second, I've got my entire list. I can go and start customizing it. If I know a lot of the Sublime shortcuts for easily duplicating content online, I save myself even more time.
And it also works quite nicely in style sheets. So if I'm inside a style sheet at the moment, and let's say I want to play around with border style, I didn't type the entire thing out. If I want to play around with border radius, let's say I want to do border radius with some prefixes, it can take care of that for me with taps. If I want to do width, it can auto-complete that for me. And I just have to use some shortcuts, which is really nice.
How many times have you been in a situation where you've been working on an app and you've run into some error in your JavaScript that you're not entirely sure of how to fix or what's going on, or you just want to try looking it up to see if anyone has better solutions to it? Well, there is a really nice Stack Overflow package for Sublime that you can get.
And let's say that I'm currently inside, I don't know, some random CoffeeScript file. I can just click on Stack Overflow search or use a simple command, and it will actually try looking it up. In this case, it couldn't find anything. But if I was in a Backbone file, it could easily look up my models. If I was in another type of file, like a Dojo file, I could look up different classes. And it's quite useful. How many people here use MVC frameworks of any kind? Excellent.
So Sublime has some really, really awesome snippet support. Whenever I'm creating new Backbone applications, I always have to end up writing some sort of boilerplate. And it's nice being able to have those auto-complete inside of Sublime. So let's say I'm creating a new model called "attendees." I start off like this.
I haven't typed more than three or four letters at this point, and Sublime is basically doing most of the other stuff for me. I know I need an initialize. I know I need a function. It's populated that out. But it helps you a lot in terms of auto-completing. It just saves you a little bit of time, which is nice.
I'm assuming there are a lot of designers in the room as well. How many people here use Sass? If you use Sass, you know that it can be a challenge at times actually debugging that in a browser. People who are using Firefox may be used to FireSass. People using Chrome can sometimes run into trouble because they're not entirely sure what to use.
There are actually some really great tools that can help you with debugging Sass and just trying to make sure that anything that you change in your Sass flows gets properly rendered out. Sass Sleuth is one of them, and there are some really great blog posts about this that I'll share. And there is also Sass Inspector.
And these tools just mean that, in the same way that you change your style information within Chrome at the moment, within the Dev Tools, you can easily change your Sass information as well and have those apply to the current page. I'm always worried when I ask this question. How many people here unit-test their code?
Excellent. Anyone that had their hand down is brave, but also should probably fix that soon. At Google, we consider code linting as something that you should consider being your first unit test. Some people will say that your unit test should be the first demo application for your app and for the modules that you write. But code linting is actually quite powerful.
Now, I have live linting set up inside Sublime. So let's say that I went to a file that I'm working on at the moment. These boxes that you see around my code at the end are actually live linting exceptions, just saying that I've done something wrong. And whenever I keep on coding...So let's say that I start doing some other gibberish...What you'll see is that it's automatically gone and runs a linter against my code.
When I click on any of these boxes, I know you can't necessarily see it, but at the very bottom it'll give me an exception telling me exactly what's going wrong. So here it's saying it expected an identifier and instead saw something else. It expected other pieces to match something else. And you should probably go and fix those.
I can't tell you how much live linting has actually forced me to improve my code. Mostly because I don't like seeing boxes around it. But it's really nice. You don't even have to touch your build process. You don't have to go to any external tools or jshint.com or anything like that. You have your code constantly being evaluated by something else and telling you whether you should be doing a better job of it.
For the CoffeeScript developers in the room, you can also do things like live compilation. Now, I've disabled it because it was running a little bit slow, but you can basically have things like CoffeeScript compilation inside Sublime run automatically for you.
So whenever you make changes to your CoffeeScript files, those will automatically get converted to JavaScript and displayed for you right underneath, which is quite helpful. You don't have to actually go to your build process again. You don't have to worry about going to the browser and trying to execute your code and seeing if everything works. You have the code right in front of you.
And I'm going to talk about live reload a little bit later. How many people use the live-reload functionality at the moment? Great. How many people here don't know what live reload is? OK.
So I'll show it to you later, but live reload is basically the idea that whenever you make changes in your application, whether it's your markup files or HTML files or something else, those changes automatically cause the browser to reload. So you have a constant view of what's going on in your application. You have a preview, and you have your source.
And then we have in-browser developer tools. So, one thing that I think was discussed at Fronteers last year, in some detail, was source maps. This is a tool by Ryan Seddon. Source URL allows you to get back a source filename for any type of compiled scripting. So in terms of CoffeeScript, if I had a CoffeeScript file, using a source URL I could actually tell you where the original CoffeeScript file was, which can help with debugging.
So here I've got some code. I've got some CoffeeScript code. I'm going to open up the developer tools and take a look at sources. Now, I'm going to name this, so let's call this "fronteers.coffee" and compile it. We see that the code is run. And if we take a look, we now see that we have a "fronteers.coffee" file. But if we click it, you'll actually see that this is the compiled JavaScript.
And at the very end, there is a URL that says "fronteers.coffee," a source URL. And this means that if I wanted to go back and find the source to this piece of code, I can easily do that.
Something that I've been blogging about quite a lot this year are extensions that can help with your developer workflow in Chrome. One such tool is Tincr. Tincr's really awesome. It's an extension that you can install in just a few minutes, and it means that whenever you make changes within the Chrome Developer Tools, whether it's changes to your scripts or changes to your styles, those will automatically get saved to your source files.
How many times have you run into a situation where you've found that perfect fit of design that you want in something. You've found the perfect border and color and everything. And then, for some reason, you've reloaded the page or you've closed the Dev Tools and you've forgotten what those changes were? Tincr allows you to save those to your source files, so you don't have to worry about that. It's quite nice.
And then we have scaffolding. So scaffolding is something that has really only become apparent as something important to front-end developers in the past year or two. There are a few tools that have tried to address it. Brunch.io is one of them.
Now, for anyone that doesn't know, scaffolding basically means using a tool to generate some code for you. So imagine you're writing a new MVC application. You often have to go write a lot of boilerplate code yourself, whether you're writing a new model or a view or a controller or something else. Using a generator, a lot of the code for that can be written for you, and then you can just focus on writing the core logic to those pieces.
So Brunch.io is one such solution. It's quite nice for creating little skeletons you can then reuse. So if you know that there is a nice setup that you like, you can just build a Brunch skeleton and have that be used every time you're creating a new application.
Another nice tool, by a fellow called Tim Branyen that works at Bocoup, is Grunt BBB, which is built on top of Grunt. But Grunt BBB is a backbone boilerplate project, which means that, if I go and open up something new, so let's say I go to a new directory and I want to start creating an app, so let's say I want to create a new backbone app, I can do "bbb init," and this will just go and scaffold out a new backbone application for me.
If you go into the files, this will actually also include a module that you can start coding in. It'll include the basic structure for collections and models, a basic unit-testing setup as well. You'll notice that it actually has both Jasmine and QUnit. And it just means that you don't have to go writing some of those basic files yourself whenever you're trying to create an application.
BBB also has some nice support for creating new modules. So whenever you know you want to create a new piece of a page, you can just use "bbb init module" and it'll similarly allow you to create some pieces of code for your app without you having to write anything.
There are other projects, like Rails Gems, you can get for generation, and projects like Angular Seed, which try to help you do the same thing. But scaffolding is still an area which is quite new to the front end, and we're still trying to borrow ideas from other communities where it's been successful, like Rails and PHP and .NET and so on. We're going to try looking at a solution which tries to help with some of the scaffolding issues on the front end quite soon.
And then we have testing. We're lucky in 2012. We have a ton of ways of properly testing our code. The one that we're probably the most familiar with is testing in the browser. So, something like this. You have your unit tests, you open them up in the browser, and they just run. It's quite straightforward.
If you're using a tool like Grunt for your build process, it's similarly quite straightforward to go and run your Grunt unit tests. So this is me just running the unit tests for Modernizr at the moment, and they've all just gone and executed and passed. It was fairly quick.
I can also do them in a headless browser post-push. So imagine you're working in an open-source project or a project on GitHub, and you want to be able to make sure that you're constantly aware of what the build status is, whether someone's commits have broken the code, whether a pull request is actually OK to merge, because whenever someone sends you a pull request, the first thing you usually do is check the code and run the unit test to make sure that it's actually OK.
Using tools like Travis... So Travis is awesome. It's a continuous-integration tool that runs in the cloud. And we can see that the current status on Modernizr says, "Building OK." But if it was failing, we would see a red light, we would see who broke the build, and what commits and what issues actually ended up causing some problems. It's actually quite nice.
You also have some nice little widgets you can get for your repos that will let you see. So if we go to, say, one project...How many people here actually use Travis, at work or in any of their projects? A few people. I would say it's easily one of my favorite tools.
What we can see here is that the build status on this project is currently failing, which means that someone has committed some code which is either breaking tests or causing issues. But it's nice, because it means that any contributors to this project instantly know what's going on.
And then we have some sexier tools. So Ryan Seddon also created a tool called Bunyip, and the idea behind Bunyip is that it helps you with running your unit tests in different places.
So if you want to run them in the cloud, so in BrowserStack, if you have a BrowserStack account, you can easily do that using the command line and fire up any sort of browser setup, whether it's IE8 running on Windows XP or IE10 running on Windows eight or Chrome running on some other operating system. You can easily specify all of the different setups that you want, and Bunyip will run your unit tests in those browsers in the cloud.
It also helps with local unit testing. So let's say I went back to my to-do MVC repo and I wanted to just make sure that it actually runs my unit tests in all of my local browsers.
So, I run this. And as you can see, it's gone and it's started up Chrome, Safari, and Firefox. And I don't have unit tests currently in this directory, but it's listening out for them, and it will run them as soon as I actually point it to some unit tests. What that means is that you can easily script this into your build process if you want, so that, you can run any unit tests in any browser setup that you need. And again, these little things help you.
Finally, we're on to the build system. Now, the build system is very interesting because, for modern front-end developers, it can be quite intricate. You have to resolve your dependency chain. You have to concatenate, compile, flatten your CSS imports, remove debugging statements, pre-compile templates, run tests in a variety of environments, rev your assets, affirm code quality.
There are lots of stuff in there. And you don't want to have to set this stuff up every single time, and you don't want to necessarily have to set this stuff up for modern development on different projects, because it can vary.
So, Paul Irish and I took a look at the web-developer landscape and the web-developer workflow over the past couple months, and we thought, "Maybe this stuff could be more smoothly integrated. Maybe this could be done better and given to developers in a more easy way to set up."
So we created Yeoman. Now, Yeoman is basically an opinionated workflow for creating beautiful, compelling web applications. And it tries to tackle a few issues. The first thing we thought about was we want developers to be able to go from an idea to a prototype in just 10 minutes. We don't want developers having to spend an hour setting up or anything like that. We want you to be able to just code right away.
Yeoman limits the time that you spend writing boilerplate code. Any time that we think you're going to end up writing boilerplate code, whether you're trying to create a new basic site or an app, we try to take care of that for you and simplify the process. We try to automate as much of your workflow as we can, because we know that that precious time can be spent improving the apps that you're going to build.
I want to reduce the friction for things like unit testing, because unit testing is scary. It's still scary to some people. You have to set up spec runners. You have to go and start writing tests. You have to make sure that your tests are properly covering everything that you're doing. And maybe it would be easier if some tests were actually being generated for you. When you create a new model, wouldn't it be nice if it actually included some tests right beside it, so you can code both of them at the same time?
So we try to automate a lot of what you do. We try to give you tools to accelerate how you build apps. We try to seamlessly integrate a lot of open-source projects. So look at the open-source landscape at the moment. We have Sass. We have CoffeeScript. We have frameworks like Compass. We then have developers heavily using things like RequireJS, and of course, tons of other libraries and frameworks. It's a lot of stuff to get to work nicely together in a neat workflow.
So we've tried to capture that stuff in Yeoman. So we provide you with authoring abstractions. Best practice things like linting, testing; a really kick-ass build process; and generators, which I'll be showing you soon.
Now, Yeoman is built on top of Grunt, which I mentioned a little bit earlier. Grunt is, basically, probably the most popular JavaScript build tool at the moment. It works in Node. And there are a lot of open-source projects that are using it on a regular basis now.
How many people here use Grunt? So a few people. I think that number's going to grow over the next couple of months. It's pretty awesome. But Grunt basically has a very task-based architecture. I should mention it's a tool by Ben Alman, who some of you will be familiar with as the guy who wrote half the jQuery plug-ins out there. He is pretty awesome.
But Grunt uses a task-based architecture. So if there is something you want to achieve in terms of building on the front end, whether it's your CoffeeScript or your Sass or whatever LESS variant that you are using and so on, you can easily just drop in a task and have that done for you.
There are people building Grunt tasks for deployment. So if you want to push out your apps to Heroku or Amazon S3 or anything like that...I should probably also mention Google App Engine. There are tasks that can do those things for you.
So we've talked about abstractions. I'll briefly talk about modules. So whenever you're creating modern JavaScript web apps, you're going to be using some sort of modules. Now, we notice that a lot of developers are using AMD.
I love AMD, personally. And so we've given AMD first-class support. Whenever you try installing a dependency using Yeoman, we'll actually go and wire up your RequireJS configuration for you, so you don't even have to go and add any scripts you're adding to the config files.
One thing that we thought would be interesting to try out as well is adding experimental support for ECMAScript six module syntax. I'm not sure how many people are familiar with this, but let's go and take a look at some examples.
This is the Harmony wiki. Now, the JavaScript that you'll be writing tomorrow, when I say tomorrow, I mean the next year or two. It is going to be vastly different to what you're used to writing right now. There are proposals for things like modules and classes and lots of other different bits and pieces.
Now, for modules, we wanted to play around with the idea of helping developers get used to what the new syntax might look like. So here is a very basic module. So I'm using keyword module. This is just a math module.
Now, you're probably familiar with the module pattern. For anyone that isn't, the module pattern basically allows you to define some semi-private behavior that you as an app developer might use and then return an object which can contain behavior that the public or other people can easily consume. Think of this module as supporting both private behavior and public behavior. Whatever we're exporting can be easily used by other people. Whatever we don't export is used by us ourselves.
The syntax also supports things like importing. So I can import different dependencies from other modules that I've previously created. And it's a little bit different to what we're used to doing at the moment. It's certainly a bit different to AMD. But some of these examples are quite interesting and quite promising in terms of what they let us achieve tomorrow.
But Yeoman has first-class support for this. And if you wanted to write your app using ES6 module syntax, we allow you to do that. We're also, in the future, going to explore better integration with another Google tool called Traceur, which allows you to play around with a lot of other ES.next features, like classes and the "let" keyword and so on.
Yeoman also has great support for boilerplates, because we know that developers are often using HTML5 Boilerplate and jQuery and Modernizr and things like that when they're starting off their projects. We have good support for Twitter Bootstrap. Again, because it's great for prototyping.
And then we have some useful things for testing and building what you're doing. So we have baked-in support for Mocha, which is fast becoming quite popular as people's unit-testing solution of choice. We have support for Jasmine and QUnit. And we pass all of your tests through PhantomJS, so a headless WebKit browser, in order for you to just make sure that everything is working OK.
We also optimize quite well anything that you've built. If you're using AMD, you're probably familiar with the r.js Optimizer, which allows you to optimize your modules. Now, what we actually do is we'll not only optimize your AMD modules for you, but we'll go and we'll apply some additional optimizations of our own on top of that. You'll make sure that your application is as small as it can possibly be.
We'll go and generate you an application cache file manifest, in case you were interested in off-line development. We'll compress your images, your scripts, your styles, and do a few other things to help. I'm going to talk about package management for a moment, right after I show you a very quick demonstration of one of the things you can do with Yeoman.
So the way that you begin an application using Yeoman is with the init command. So I just typed in "yeoman init." I wait for this to kick off, and when it runs, it's going to ask me a number of questions about what I'd like to do. So, "Would you like to include Twitter Bootstrap for Compass? Do you want to include the Twitter Bootstrap plug-ins? Would you like to include RequireJS support?" And finally, a question about ECMAScript six module syntax. And now it's gone and it's scaffolded out my application.
If I run "yeoman server," this will go and launch a local server so I can take a look at what's going on. Just waiting for it to fire off. And there we go. This is a preview of what it's generated. So we're using Compass for the Twitter Bootstrap files. We're using HTML5 Boilerplate, Bootstrap plug-ins, and a few other pieces that we've included.
Now, Yeoman also has support for live reload. Let me show you how that works. So let's say I go to my editor. And let's get rid of this thing. And I want to go to my application. Let me try getting this side-by-side so you can see what happens. So let's say I make a change and I say, "Wotcha Fronteers." "Wotcha" is one of those terms that are quite colloquial to the UK. I'm not entirely sure what it means. I think it's "hello."
But as you can see, I didn't even have to refresh my browser. The change automatically caused a reload. And that'll happen whenever I make changes to scripts, to styles, to any files inside my project. So I have a constant, real-time view of what's going on.
Now, let's talk about package management for a moment. Now, whenever we want to get new things into our project...New scripts, new libraries, new frameworks, it's still a very manual process.
Normally, you'll read on Twitter that, hey, maybe jQuery has a new version available, or maybe Backbone has just released something new, or someone told you that they're out of date. You'll go and open up the site in your browser, you'll find the download, download it somewhere on your system, move it to your app folder, wire it in with some scripts and some tags and stuff, and it's a very manual process. In 2012, you shouldn't have to do all that stuff yourself.
So we figured that we try to give developers an easier way to handle packages. Now, packages can be scripts, frameworks, libraries, or they can just be CSS and HTML. Any web technology, basically. So why do we think you need package management? Mostly because client-side dependencies can be a real chore. There is a lot to it. You can often end up with a lot of common code that's duplicated.
I don't know about everyone else, but I can certainly remember a few years ago, I find jQuery plug-ins that I want to use, and the authors to those plug-ins would think, "Yes, I'm going to keep on maintaining this plug-in. Screw the jQuery version I'm using. It doesn't matter."
And then I'd end up in a situation where deadlines are tight and I have to make a call about whether to use multiple versions of jQuery on my page or go and try fixing the plug-in to work with the latest version of jQuery, and it was a real chore. And we still have this problem today. So you can end up with a lot of common code. And you don't want to be running multiple copies of the same library on your page. Just doesn't make sense.
And there tends to be a lot of library fragmentation these days. People want to use different utilities, want to have different dependencies that they rely on, and often developers will want to switch them out. One example of that is Underscore versus Lodash.
So we wanted to allow developers to have longer dependency chains. So imagine if you wanted to use something, so a jQuery plug-in. That plug-in might have a number of dependencies. Maybe it's some sort of amazing Lightbox plug-in, and it relies on another plug-in as well as jQuery. You shouldn't have to worry about going and getting all of those dependencies yourself.
So what we do is we support an install command. Let me take you through a very quick example of that. Waiting for this to load. So here I've got a to-do application. And if I take a look at the Developer Tools console, I'll see that it currently says undefined is not a function. Now, if I go back here and I open up a brand new tab, I know that in my source code to this application, I'm actually missing one dependency called backbone local storage, which allows me to persist the to do items in this file to local storage.
I don't really want to go searching for it online, so all I do is yeoman install backbone.localstorage. It will go and query a package management registry called Bower, and it'll install this for me. So it'll go and get the latest version, fetch it, cache it locally, and if I now go back to my application, you'll see that everything works. It's installed the dependency locally, and I can easily use it.
You can also easily update dependencies locally and manage anything that you've installed without even having to leave the command line, which is quite useful. The final thing I'm going to talk about are generators. Now, generators allow you to capture a lot of the things in your typical application workflow.
If I'm writing a new backbone application, they'll write out the models and the views and the collections and so on for me.
If I'm creating a new Amber application or an angularJS application, same thing. So the way that scaffolds work is quite similar to a normal init. If I go and I do...Let's create a brand new directory. If I do Yeoman init and pass help, it will go and show me some of the generators that are available.
I know that I already want to use a backbone generator, so I just use Yeoman init backbone. And this will go and scaffold out a complete backbone application for me and check to see if I've already created anything in my project previously.
If I want to go and create a new piece of that application, so let's say I want to create a new model, all I have to do is pass in the same command, type in the type of component that I want to create, and then the name of that component. And it'll automatically go and write out all of the boiler plate that I need for that. And then I can just go and write my logic in there.
So generators can be easily written by anyone. They can capture your workflow. They can avoid you having to write boilerplate code for almost any framework, really. And you can easily go and fork them and create your own. We would love for the community to start creating some more generators. We know that people have some really awesome app setups, and we think that it would be great if you could share those with others and help them easily get set up whenever they want to create new apps.
And I'm going to give you one very quick final demo, because I don't think I have too much time left. I'm going to show you how we actually go and do things like compilation of ES6 module syntax and CoffeeScript.
So, I'm going to serve up another application. Oops, looks like the port is in use. I'm going to serve up another application, and this application is going to be composed of a few different pieces. It's going to be composed of some CoffeeScripts, it's going to be composed of RequireJS, and ECMAScript six module syntax for a few pieces as well, just in case I want to use that.
So I'm going to run Yeoman Server to preview what the application looks like at the moment. It's gone and it's compiled all of my CoffeeScript files. And if I go back to my code and look at the application, you'll see that this is composed of a few different pieces. So, here we go. HM corresponds to ECMAScript six syntax files. And we've decided to put a specific file extension to this, just to make it clear what is ES5 or ES3 code and what isn't.
So here I am using a module that was defined somewhere else. I'm importing some animation behavior from a different module. I'm defining some privates, some exports that can be used by other people. This is what my other module looks like. And I also have my CoffeeScript behavior in here.
Now, whenever I run Yeoman Server on this, it will actually go and automatically compile my ECMAScript six files into code that will run inside any browser. It will compile the CoffeeScript so that it works. And everything will just work fine. I don't have to do anything else.
So our build system will compile your CoffeeScript, compile your ES6 modules and your Sass files. It'll minify and concatenate all of your scripts for you, optimize your AMD projects, compress all of your images, generate an application cache file, and a number of other things that will save you time.
So in summary, Yeoman will scaffold out new projects for you. It'll give you watch, recompilation, and live-refresh capabilities. You will easily have access to all the tools that you love using on the front end. You can run JS linting very easily. It'll robustly build anything that you stick at it into production, optimize it all so that you can easily deploy it, and again, it will compile your AMD modules quite easily.
Yeoman 0.9.3 launched yesterday, and it's readily available at yeoman.io for anyone that wants to try it out.
And to wrap up, remember that tools are your friends and will increase your productivity and save you time, so please consider using them. Hopefully by now, you're at least as happy and as excited about this stuff as this guy. That's Paul Kinlan, who works at my office. I really want you guys to feel like this guy. He's got crazy eyes. But that's it. Thank you very much.
Chris Heilmann: Thank you. We are out of time, so there is an option now. We have a half-an-hour break coming up. Come back here at 11:10, because there is going to be a book raffle and also some stuff from PPK, book raffle. OK. Do you want to do a quick Q&A, five-minute interview with him, or do you just want to go into the break right now? Break? Interview?
Audience: Yeah, No.
Chris: The ones who want break, go out. The other ones, come here. So, the back channel was burning. Among the insults, there were some interesting things as well. First of all, what about those poor, poor people out there that have to work with Windows?
Addy: So, our current official response on that is Yeoman does support Windows at the moment. It's considered beta support right now, but we have had a number of people use it without too many issues. Most of the people in my workshop yesterday were using Yeoman without any trouble on Windows. It's really just a case of trying to get it properly set up.
Chris: You called that the tool belt of web developers. It looks more to me like the Batman belt, with grappling guns and stuff. A few questions, and I agree with this, there are so many moving parts in there. Is it really good to just use them and hope that magic happens, or should we understand the tools that we're using as well?
Addy: I think it's very important for developers to understand the tools that they're using. But at the same time, it can often take a lot to put together a build process and a workflow that works with modern tools, and sometimes it can be nice to just rely on someone else to give you the first step of that.
Now, with Yeoman, because we're built on top of Grunt, it's easily possible for people to extend it and customize it as much as they want. So if you want to go under the covers and investigate what's going on, you can do that. If you want to just rely on what we give you, you're also free to use that option.
Chris: What if one of the things in there is not as hot and cool out of a sudden anymore and doesn't get maintained? Because it happens that these things are being built, and then people get hired and get hired by large corporations and have to do other things.
So I rely on Bootstrap, for example, right now. And we heard the two Bootstrap guys just left Twitter and did something else and said "Oh, it's going to be open source. Somebody will maintain it, and we will dedicate our life to it." Are we relying on things that might go away too much?
Addy: I think there is always the chance that some dependency that you are used to using in your projects is going to go out of date or stop being maintained. But because the architecture we are using is quite easily extensible and customizable, you can switch it out with something else. If you don't want to use Bootstrap.
You can create your own generators that use something else if you find that there is something better than Bootstrap that works for you. And we think that the solution that we've put together isn't too coupled. It's fairly easy to extend it.
Chris: But again, we're using a lot of things here that I don't understand, at the same time with responsive web design, I have to learn a lot more things. Not everybody has time to set up their environment like this. All of these things are good and fast, but they also mean a step first to try to understand them.
Like changing my editor is, for a lot of developers, a big, big change. So, is there a way to actually make that easier for people? I, for example, I sync my Sublime text over Dropbox with other people. So that's the next step for something like Yeoman, isn't it?
Addy: Yeah, I think so. I think sharing the workflows that people have is certainly something that a lot of developers have expressed interest in, and it's going to be an area that we're going to look at quite soon and try to solve better. It can be a challenge.
In terms of Yeoman, we don't recommend, necessarily, that someone just use Sublime. But, because what we've built is done so in a way that should hopefully work with most editors and most environment setups, as long as you have Ruby and Node installed, it should be OK.
Chris: As long as you have Ruby and Node installed. It's amazing how we throw these things out there, and half of the designers in the audience, or people who love just HTML, "What the hell is Node, and how do I set it up?" Isn't it partly part of the operating system to do these kind of things?
Addy: It should be. I would love if most modern operating systems actually came set up with some sort of nice stack that you don't have to go and install yourself. For developers that perhaps aren't as comfortable with installing all these dependencies, or perhaps designers that aren't very used to things like Node, we do have install scripts available for most platforms, including Windows.
So if you don't want to use our manual recommended process, you can just use the install script and it will go and install all the dependencies and set them up for you.
Chris: Can you see in the future a Chrome OS that will come as a developer OS with that?
Addy: I think it's certainly possible. There have been a lot of developers experimenting with using Chrome OS as their default system, especially when they're traveling. And I think there is still a good solution that needs to be put together for allowing you to edit on those operating systems. Cloud9 is great at the moment. It still has a long way to go, but perhaps there is more that can be done there, and I think that Yeoman will try its best to integrate with whatever developers come up with for an editor.
Chris: A last, very important thing, I think, is, doesn't any of that also lead to overcomplexity? We talk about, "Do one thing and one thing well." And people will do static pages with every library under the book because they started with Yeoman.
Addy: Yeah.
Chris: Don't we clutter the web with things that are not necessary at times?
Addy: I think so. So, when I described Yeoman, I did call it an opinionated framework, or workflow. And there are some sane defaults that we think people should consider using, but if you don't want to use those things, very similar to HTML5 Boilerplate or other projects, you're free to delete the parts that you don't want. With our generator system especially, you can easily go and copy any of the defaults. You can strip out Bootstrap, for example, or HTML5 Boilerplate, or whatever you don't want to use.
And then, whenever you go and create new projects, it will only use the features that you want.
Chris: That's the same promise that jQuery had, and now we've got 15,000 plug-ins on every website.
Addy: True. But we think that if you're using something like our package management, via Bower, that that will hopefully solve the problem.
One of the nice things about Bower is that it's also quite opinionated, and it won't allow you to use more than one version of a library in your application. So if it detects that you're trying to install plug-ins with different versions, it'll actually automatically try finding and forcing you to use the latest version of jQuery and the latest version of those plug-ins.
And that's just something sane that we think you should be doing. We think that you should try developing in a way that uses...
Chris: What about backwards compatibility?
Addy: For plug-ins?
Chris: For example, if jQuery wants to kick out IE6 support now, if I need this in my project and I get forced to upgrade to the newest one.
Addy: It's easily possible for someone, even jQuery, to stick up a version on the Bower package management registry that just has IE6 support in there. So you would just install it via something like "Yeoman Install JQuery IE6" or something similar.
I think the projects have discussed the idea of moving IE support into a plug-in. So, imagine that you do something like "Yeoman Install JQuery IE6." It will install a plug-in for you as well as jQuery, and then everything will just work. It is a little bit magical, but we want to give people a bit of magic.
Chris: OK. PPK is having kittens here, so we have to have a break now. I'll see you here at 11:10, on the dot, because there will be books for you. See you soon. [applause]