Google I/O 2012 - Better Web App Development Through Tooling

>>Paul Irish: Cool. All right, guys. My name is Paul Irish and I am a developer advocate
on the Chrome team. I want to talk a little bit about tooling.
So this is about building Web apps, finding the right software to make your process of
building Web apps fun, awesome, enjoyable, less stressful, more productive, things like
that. Now, I'm going to talk a little bit about
kind of how we're building Web apps today and how I think we can build them in the future,
but for a second I want to take a few steps back and walk back a few years, back to 2006
because this is the year that I wrote like my first website where I was like doing all
the right things when it came to Web standards. And I felt so good about the way that I was
doing it, so I was actually here and I did something probably like this, and I was doing
a little bit of this and then this and then that and then that and that, da, da...
This is typical, right? [Laughter]
>>Paul Irish: Oh, there we go. Nice! Cool. [ Applause ]
>>Paul Irish: All right. I'm really glad we don't have to type that out anymore. That's
really nice. But this is like -- so what I actually did
is when I made this site, and it turned out to be really nice, I did the whole thing in
Notepad. And I think we consider it a little funny now that I would write like pretty significant
site in Notepad, but at the time I was like, "I'm a craftsman over my markup and I will
be one with it, and the closest I can be in it is in Notepad exe." So I just used that.
And it just seems kind of silly. I thought I was so close to it, but really it's not
really craftsmanship. That was handcraft. That was like the Web's development equivalent
to whittling a stick. And handcraft is more about choosing tools
well, finding the right tools to get the job done and assist you.
And I noticed this too, I started at Google about two years ago, and looking around when
you're surrounded by really smart people, and you notice what the really productive
developers do. And they know their -- they have tools that they use, they know them really
well, and they embrace them. And so I kind of like noticed that there was a theme going
on here. And so I want to talk a little bit about tools.
And this is not about, you know, Google development tools. This is about -- you know, you don't
have to be building the next Gmail for this kind stuff to apply to you. It's for everyone.
A lot of people have been noticing this recently. And I just want you to, like, think about
remember there was a point at which you didn't actually use version control. You might have
been on a team and you're like, Hey, I'm going to be editing, indexing HTML. Can you hold
on just a second? Okay, you can do it now. Like source safe. It was, like, annoying,
but version control made it a lot better. And we can focus on development, not tiresome
debugging when you don't want to be doing it.
And then how much time have you lost when you actually had a colon where you were supposed
to have a semi colon or an extra comma at the end of your little object in JavaScript,
and you were like ah! There's lots of funny things. I'm not going
to click to it. It's a little not safe to work, commit logs from last night, pulling
in logs from GitHub where people happen to use expletives because they're a bit frustrated.
People that are making silly mistakes that they probably don't need to.
So we're seeing a little bit of shift towards looking at tools assisting us. And Rebecca
Murphy did a great post about this sort of shift recently, and she said we're seeing
us focus from valuing trivia to valuing tools. And a similar thing was said a little bit
ago by Michael Lop, known by Rams online. He's an engineering manager at Apple. He said,
There's a short list of tools that you must be rabid about, rabid, foaming at the mouth
crazy. And he went on to talk about how he used his editor, his terminal and what made
him productive. And I think this is important to really identify
what you feel great about. And so I've done a little bit of research and it talks about
this, and there's a lot of tools. When I say tools, it like covers a lot of
things. So this is a quick way of trying to visualize from start to end what are all the
tools that I use from the birth of a project to deploying it out to the world.
And we're going to kind of walk through a little bit of this, but focusing on your developer
workflow. So I'll just -- we're going to walk through
the current workflow for Web app developers. And really the way we'll start this off is
in your shell. In your shell -- I'll bring mine up right
now. Cool.
The first thing is I think you should make it sexy. Feel good about this terminal that
you're typing into. There's a really great community on GitHub around dot files, configuration
files for your bash prompt or your ZHS prompt, other application configurations. So I encourage
you to go check that out, see what other people are doing and customize your shell and share
your customizations with other people. There's a few favorites that I have. One of
them is a directory jumper called Z. I'll show that now. I can jump to any folder that
I've been in somewhat recently. I'll jump over to the modernizer project.
You can type any portion of that word, hit Z. We jump right into that. Now we'll actually
go over to the HTML Please project. Just type in "Z please," and we jump over into that
folder, nice and easy. Cool. Now, moving on past my shell -- actually,
first, the server alias. This is pretty cool. This alias, this is just a bit of bash. We
are just firing up a simple Web server, no big deal. At the same time we're opening up
browser tab. Configurable port if we want, but we'll default to 8,000 if we want. I'll
do that now, type in server. Cool. And refresh. Yeah, cool, awesome, good.
So we have my local HTML5 Please running right here.
Now, coming back, the next part is the editor. And the editor, you might have your own preferences.
That's fine, but the key to a good editor is that it's an onion application, which is
to say that there's a nice learning curve where you can kind of peel back the layers
of functionality and kind of grow from novice to expert at a very easy pace.
So the other thing with an editor is that more than any other tool, this is where your
investment in time and learning it well and learning the features inside of it will pay
off huge dividends. So I'll bring up mine right now.
Let's see. I'm actually using Sublime text and we'll bring this up and move it over here,
and we're going to bring up actually my script for this file.
Nice. Cool. Now, one of the things that I've noticed developing
recently is that I've kind of, like, learned new tricks, I like some of the features in
this editor. And one of the things that I added to my editor workflow recently was having
linting. And code linting built-in write live. So I'll show you what I mean right now.
So here I have these three variable declarations. It's cool. I didn't actually write these three
lines, but maybe I'll refactor them a little bit. Select them. I will align -- that's nice.
Good thing. I'll do a multiline select. Move that over. That's cool. And then I'll go over
and fix that. And good. Now, one of the things that it's helping me
out with here is I have this white box right here and this is linter plug-in that's running
inside Sublime and it's telling me I have a problem.
Now, way down at the bottom it says "H2 is not defined."
And I'm like, but you're right here. Hmm. And what is the problem in this right here?
Yes, my semi colon should be a comma and I should be stringing my variable declarations.
That's so nice. Yes. It's cool.
All right. So yeah, I got lifing back and it was able to, like, save me from an implied
global variable, which we don't want. I probably would have caught that. It would have been
a syntax error when I refresh the page, but I'm getting it caught right here immediately.
So I like this. In fact, I think code linting is your first unit test. Typically the first
unit test that you might write is the global there, does this thing exist. And even before
that you get feedback on if it's available. And in JavaScript this is particularly important.
Some of the languages have rich static analysis features. JavaScript is a little hairy in
that sort of thing, but we have code linting. I'm using JS right here, and I can get immediate
feedback on is my code syntactically sound and is there anything that I should watch
out for, like what we just saw? So one of the parts of this is I really like
getting the realtime feedback. If you've seen the talk by Brett Victor, Invented on Principle,
one of the things that he talks about is having immediate feedback between your code and your
results and getting that feedback. And so I'm going to show a little bit of kind
of what kind of tools provide this sort of workflow these days.
So I'll move this back over here and I'll open up the style folder or the style sheet
that we have. I think it's style.scss. So we're using Sass and Compass, and I'm going
to jump down to H1. So what I'm going to do is just make an edit
in the text shadow and we'll just change this part of the text shadow from this right here
up to 41 pixels and save it. Now, nothing happens. I refresh the page.
Okay, cool. That's good. But I can turn on this library load extension, which is just
available inside Chrome. It communicates with the system application back here. And now
any changes that I make are in fact live. So I make a change, I just hit save. I don't
have to go over and hit refresh. That's good. So I'll actually just say that that sounds
pretty good. And I will go down here and add a little bit more functionality.
Let's see, I'll do a CSS transition that I want to see .4 seconds. I'll apply that to
all things. And then add a hover state to it. I think this time we'll do a transform.
Nice. Okay. So I just hit saved, I come over here
with my mouse and -- nice. This is definitely an improvement and I will be committing this
to the repo right now. [Laughter]
>>Paul Irish: Or not. But that's cool. But I'm getting my immediate
feedback, so I'm getting my Sass immediately recompiled on the fly and then my CSS is being
served back to the browser. Without even the browser refreshing I can change the page,
my scroll position is maintained and just the style sheet is being swapped in, which
is really nice. All right. So I'm going to show a little bit
of the browser dev tools inside Chrome, some features that help especially with building
applications that you may not be aware of. The first is sourceURL. And this is a feature
that's been in the browser for quite awhile. This is a little demo set up by Ryan Sutton,
and so we have a little bit of Coffescript right here in the middle.
I'm going to make a small little edit to this Coffescript first.
Nice. Cool. I'll bring up the Chrome dev tools. And -- that's
pretty good. Nice. Now, normally I can take this Coffescript,
I can run it through Coffescript.js, compile it into its JavaScript form, and if I run
it, it goes through eval. And normally when you take text and run it through eval, it
evaluates, but it just kind of disappears into thin air.
SourceURL is a way to basically treat that as a file. So if you see down at the bottom
I'm adding googleio.js and adding to compile. Now you see it over here in the Chrome dev
tools. And if you look over here we have what I just added in the Coffescript, now compiled
to JavaScript, and at the side over here is the sourceURL.
So this little line is indicating, hey, dev tools. I got this text, I threw it into eval,
but can you treat it as a file? Thanks very much, that would be great.
So this is really nice, too. So not only is it a file, but I get all the features that
I would expect. So let's say break points. First I'll just make sure that my cube function
is working all nicely. Yes, good. Cube files 125. At a break point
cube of five we break. I can't actually check the value of X right now. We're looking good.
Yes, sure, we'll continue. Or I can do a live edit. I can immediately
change this file on the fly, we'll return 2 from square so now let me ask for a cube
and it should be 5 times 2. Cool. And we get our result, which is 10.
So I'm getting live edit and break points on some JavaScript which was compiled down
from Coffescript all on the fly. I'm showing up as real files. That's pretty nice.
Ember actually uses sourceURL to great effect to -- Ember the JavaScript library, to emulate
modules, which is really, really cool. Another feature I want to show real quick
is source maps. So if I bring back open my local HTML5 Please and view the source, down
at the bottom is my original sources for the project.
Looks like we had some script tags pulling in a few libraries and then this script.js
that I did before, but what really gets served to the browser is script.min.js, which is
minified. My Chrome extension is critifying this for me, but I really want you to see
that it's minified. Okay, cool. Thank you, Chrome extension.
All right. So the browser is actually receiving the minified source, of course,
But down at the very bottom of it is a little indication similar to what we saw with sourceURL,
only this time it's source mapping URL. And this points over to a map file. And this
map file does -- basically takes the identifiers in this compiled source and maps it back to
my original sources and says these are the files.
And so what I can get are the results. I open up my dev tools and instead of seeing
script.min.js I see my original sources all in here.
And the cool thing is that the same thing works over here. Here's my nice edits that
I made. I can apply break points and click on any -- and now we're actually broken in
my original source even though the browser is interpreting the minified version. So this
is great for an environment like production where you're serving up the compiled sources,
but you want to be able to debug the original things you typed up.
All right. Cool. Lastly, if you noticed, this might look a
little different to you. First of all, the dev tools are on the right-hand side. If you
open up the settings panel which is down here in the bottom right, we have a few things
in there. So doc to right, which moves it over there. Really like it in doc to right
mode. We have our step to bugging on the right-hand side and I can get that out of the way. My
file's over here and I can get that out of the way and view my scripts in their full
glory. I can also jump to different scripts. Instead of using this menu I can kind of hit
Command O and see all those scripts that are available. It's kind of get completion there.
Or Command Shift O and see all the functions that are defined in this file, and now I'll
just bind -- yes, the sort function is what I'm looking for. I can jump immediately to
that definition. So a lot of nice things to make dealing with
a large JavaScript code base a bit easier instead of the dev tools.
All right. Now, I wonder about testing for a moment. And this right here is actually
a picture from a series that we have up in the bathrooms at the Googleplex in Mountain
View, California. The series is called Testing on the Toilet. So each week there's a new
sheet that gives you some good tips for writing test against your software. Good reading material,
too. But it's important to write unit tests, so
I have a few ideas here. First is that you should author your test
in whatever you feel most comfortable in, so these days for JavaScript it would probably
be Jasmine Q unit or mocha. They all have kind of different assertion styles, and find
whichever you like and you feel comfortable writing those assertions in. Build up a large
test suite and then it feels so nice as a security blanket when you're doing refactoring.
The other thing is you can execute these tests that you've written in a variety of different
sessions, so like -- settings. The first one is, of course, in the browser, so this is
the HTML5 test suite. Run inside Q unit, inside the browser. Pretty common. You can also run
the same tests inside a headless browser, on demand, on the command line, so I'll show
that right now, I'll use grunt, which is a node-based command line tool and type grunt
Q unit. So this is actually going to fire up phantom.js, which is a headless WebKit
instance, toss in those Q unit test suite and then check that those indeed five assertions
did pass. So I'm able to run the exact same tests just without leaving my command line
here. I can also run this -- run tests after I push it up to version control, and let something
like continuous integration server test these things, so we do this on the modernizer project.
So this is Travis. Every time we put up a new commit on GitHub, Travis comes in, pulls
down the latest, and actually does a similar thing, it takes our Q unit test, throws it
into phantom.js, and then -- and then we're looking good. It tells us if we're indeed
passing or had a little bit where I made some commits and broke some things. We fixed that.
It's good. Another cool one. This is really nice, again, from Ryan Setton. He wrote a
tool where we can take tests, not only get results on the command line, but be able to
test browsers in the cloud, so I'm going to take this same test suite that's in Q unit,
and toss it to bunyup, and bunyup will then take that and call up a browser static, which
has a lot of browsers in the cloud and also mobile emulators. I'm not going to wait for
this finish, but it just called up some IOS emulators, and it's gonna -- and it can check
my test suite against those and get the results back.
So this is really nice. I can write my tests, be able to execute them, in a number of different
devices and browsers on the fly without ever leaving right here. All right. When you have
a build system, you wrote all this stuff, you need to get it out to production. A lot
of things you need to do with a pretty hefty Web app, and tackling all of these on your
own every time -- every time you make changes is not going to work out so well, so you're
going to need some help. I'm going to get into a little bit of this later. But after
you deploy, one of the things that I think that we often forget is keeping track of your
errors that clients have. So this is a screen shot from errorception, and it's showing my
report from a Web app that I somewhat hastily put up with some friends, and telling me that
I actually have -- people are hitting some JavaScript errors in I9 and Chrome, and, you
know, I didn't hit any of these errors, and none of the other developers did, but -- but
real users in the field are hitting these, so I can get these reports and make sure that
I can fix all these for everyone. Okay. So that was a lot of stuff, and sorry, but -- so
I was showing a lot of things, and it was kind of like this is here, this is here, and
the feeling that I got was that this was kind of like -- I mean, there's a lot of tools,
and they're all useful, but they kind of didn't have this smooth integration, so me and some
people on my team thought about this and we thought maybe there's something that we could
do to kind of make this work flow a bit more smooth. And so I'm going to talk to you today
about a project that we're going to show off called Yeoman. So the ideas behind Yeoman
is that we think you should be able to go from your idea to a rough prototype in ten
minutes. I say "rough", but I mean like a prototype that you're actually going to continue
developing, like you're using all the tools inside that prototype that you would normally
use in a Web app, and you're going to keep going from that. We also want to make sure
that we can reduce friction from the things that you should be doing, such as testing.
And now, you probably heard that you should not repeat yourself when you're coding; same
thing applies to your tools. You shouldn't have to type -- you shouldn't have to run
build.sh every single time you change a file. So these things should be automatic. So what
Yeoman is is it's an open source set of tools, frameworks, libraries, that accelerate building
good Web apps. So has some things in it, so authoring abstractions, linting, testing,
build tools, these things that I've been talking about, but we've been focusing on providing
nice, smooth developer ergonomics so it feels good to use. So there's a few things inside
of it. Things -- these names you should be familiar with: Compass, sass, CoffeeScript,
module support, by the way of AMD, and ecmascript 6. We'll get to that in a minute. Twitter
bootstrap, stripped HTML5 boilerplate, some testing things, Jasmine, phantom jas, image
compression. All right. So I'm going to do a demo and I'm actually going to skip the
first step, the first step is a little shell script that gets your developer environment
all set and going, gets you installed with node and NPM and home brew. Get a few of the
dependencies out of the way. You're going to want, because, you know, sometimes I'll
end up switching to a new machine, and getting your own developer environment going takes
awhile. So we wanted to make sure that you could get rid of that -- an old set in a few
minutes. All right. So I'm going to go to temp. Nice. All right. We're going to kick
off a new project. So a lot of what we have in Yeoman is accessible on the command line,
and so I can just type Yeoman command, and we have a few things available in here. We
have init, build, server, test, and some other stuff we're going to get to later. So what
we're going to do here is we're going to start a new project. I'll name this project IO app.
And inside our app, we're going to type Yeoman in it. Cool. So we're starting off a new project.
Things are good. It's going to ask us a few questions. What's the name of the project.
Description. It's going to pull a little bit of the get metadata from my get config, so
some of these defaults probably will make sense for me. And that's good. Now, it's going
to take all of this and create a nice little package .json file which I might want. Now
there's a few things it's going to ask me if I want. Do I want Twitter bootstrap? Yeah.
Required JS? I'll pull that in for now. And experimental support for ecmascript 6 modules,
let's do it. All right. I say yes, we get a bunch of files written and we're good. Just
to show kind of what this created, I'm going to take a tree and pipe it through to Les,
so let's see, we've got a good deal of bootstrap here, and then bootstrap -- a little bit of
HTML5 boilerplate going on here, some more bootstrap, Jasmine going on down here. Cool.
Now -- now, the next thing I'm just going to open this up inside my text editor, and
so we have here a little stripped version of HTML5 boilerplate and I'll add in some
text, and I'm actually just going to use a little bit of zen coding to save some time.
Nice. Hello I/O. Yeoman in action. Now, we have a server built into Yeoman. And the cool
thing here is that we're actually taking -- because when you run a server, you actually want to
be able to watch your changes too. So you set up a server. It immediately actually opens
up that result inside the browser as well, and you're off. So now I'm going to open up
my style sheet. All right. And we have in here, we're going to pull in Twitter bootstrap,
and I'll bring that in here, and now watch as I hit save on this file. Hit save. I'll
watch task. Notice that it immediately changes. And then we run it through compass, we hit
the reload task and you saw that it changes up here. So I'm now able to add whatever I
want inside my text editor, and get immediate results down at the bottom, or in my browser.
So do a little bit of styles here. Save. That looks pretty good. A little bit of color over
here. Save. Nice. Cool. So I'm able to just go run all this immediately through Coffee
Script -- sorry, through compass, compile it down to my resulting CSS and then get the
results immediately showing over here. The cool thing is that we're actually not even
using any sort of Chrome extension to get the lab reload functionality inside -- inside
the view in my browser. Now, this is cool, and I wanted to bring up testing, because
I mentioned that before. We can just go over to slash test, and we have our Jasmine test
suite, all green, looking good, we see in the browser, looks good. Like I said before,
I think it's really nice to have this available at the command line two, so we'll type in
Yeoman test. We're going to take that jasmine suite and throw it into phantom.js and get
our same passing results. Cool. I should mention here that we're using grunt again to use a
lot of this system level functionality. It's a great project for this sort of thing, and
we're leaning heavily on it. All right. Cool. Now, let's move over to another project. I
want to bring up this application, and we'll kick it off right now. Bring this up. Nice.
All right. So this should look pretty familiar to you. This is your standard to-do app. Common
-- a large portion of this came from the to do MBC project where you can see a basic to
do app built in a number of different frameworks and libraries. So let's see, go to I/O, do
a talk. Nice. Cool. So we've got this basic functionality, and that's good. I want to
show a little bit of how this was built. So right inside here, we view source, and we're
pulling in required.js and the main module that we're pulling in is main. And so I'm
actually going to take a quick detour and talk about modules. All right. So modules,
the quick elevator pitch on modules is that the key to building a large Web app is to
not construct a large Web app; it is to break it up into small libraries and small parts.
Writing code into small files feels good, and we can do that when we use modules. With
structured modules we can also define what our dependencies are, and when we do this,
we're actually able to just define our dependencies a single time, so let's say we're not using
modules, so you would probably have your HTML file, you would have bunch of script tags
in the order that they need to be in, and then you have your build system which is going
to, you know, concatenate all your files, and you have to specify your order and your
dependencies over there as well. Modules we can only -- we can just define that structure
just in one place. Another advantage is that as you develop, you might stop using code,
and in modules, code you stop using just gets stripped out when it goes out to builds. So
there's a few different ways to write modules, and I'm going to show two of them here. The
first is AMD modules, so these are asynchronous modules. They have dependency resolution,
help you to not write global variables, and it has a very rich plug-in ecosystem that
I'm going to show as well as smart-build optimization. So this is an example of, let's say, a to
do controller, and we're going to pull in this file, and bring it in to our app as a
to do view, and then our to do controller is going to return an object that includes
some stuff and then a render method. All right. Cool. Now, on to the next module. This is
ES 6 modules, ecmascript 6 also ecmascript harmony.
Now, this is actually coming from ecmascript committee, TC39, who thought that, you know,
people were kind of doing this in the JavaScript world; let's find a way to make this actually
happen in the language itself, so offering a native solution. Has a flexible syntax,
beyond what we have just down here, so what we have is we're pulling in a module called
"to do view", from this file, and importing it into this file, we have some functionality,
and then we can export whatever we want, so in this case we're going to export a function
called render where we do some stuff. Actually point out I am saying ES 6. There is a little
bit of conversation happening like right now about if this is going to make it into ecmascript
version 6 or the next version after that, so we'll see how that goes. But we wanted
to experiment with this, and see if Yeoman could give us an ability to try out this style.
So back to -- back to the code. I said that this was using required.js, so I'm going to
open up the -- our source of this app, and I'll open up main.js. So this is the module
it's pulling in, and looks like we're initializing an app right after we pull in the task app
module, and we have a little coffee script pre-filter on this, so looks like -- all right,
cool. So this is indeed AMD, but it is of course CoffeeScript. You can see at the top
we're playing in a few other modules into this file, and then we have our application
set up where we're defining our structure of our to dos. Now, one of these modules that
we're pulling this is this fun module, nice. And we're pulling it in with an HM pre-filter,
stands for harmony. So I'm going to go over to that real quick. Fun. All right. So this
here is an ecmascript harmony module. We are pulling a few things into it. So we're pulling
in speech, from -- from this guy over here, and this is actually the E speak speech synthesizer
client, and the cool thing about this speech synthesizer is that it's actually written
in C++, but it was run through emscripten which is a research project by Mozilla that
can port C++ into JavaScript, and so now we're taking that and we're exposing it through
ecmascript harmony modules and bringing that out, so we pull in this module, and we also
got this guy going on here, and down here we're going to use this speech module at the
bottom, and pull out this speak method. Cool. Coming back into our app. I can see down here
when we create a new item, I'm going to uncomment out this guy, and comment out this guy. Nice.
Come back here, and refresh the page. Good. And now let's try this out.
>>> Remember to ace the demo. >>Paul Irish: Yeah. Nice, cool. So nailed
it. Awesome. All right. So the cool thing here is that we have a C++ library that was
ported into JavaScript via emscripten, exposed via ecmascript 6 module into our CoffeeScript
application compiled down into ecmascript 5 JavaScript, and now we've got a (indiscernible),
so I think we're in a good place. Cool. All right. One of the things that we wanted to
do with Yeoman is find out how we can iterate on it in a way that kind of was based on how
people are using it. So we have a thing in there that can report exactly anonymous metrics
around what are the commands that are typed in, so any kind of Yeoman commands, and this
way we can get a better idea on how people are using it, so they can make good changes
and really make sure that the tool fits its users. Another thing that it can do is answer
questions like what's the popularity difference between backbone and ember, or what's the
adoption rate of ES 6 modules? So I think this is really cool. And we also
want to make sure that all this -- all this data is accessible to anyone that wants to
see it. I want to take a moment just to talk about package management. So I don't know
about you guys, but if I have to update like a library that I depend on somewhere, the
first thing that happens is someone probably tells me, hey, that Jay creates 1.5 up to
1.8 alpha. You should probably update. Okay, okay. I'll go to the site, I'll find the download
button, and I'll download that to my downloads, then I'll move that into the app folder, and
then I'll like fix the script tag because it's a new version file and fix that, and
that's -- that's not great, so why do we need package management for clientside JavaScript?
Because what I just described is not fun. And then more like an Ecosystem level, common
code gets duplicated across a good size app, you probably have code to bind a function
to a scope like four times. Another thing that happens is that libraries get fragmented.
This is why we have things like the jQuery empire and then the YUI and dojo and closure
areas where things are not really interoperable, and we have fragmented communities and libraries.
So with package management, we can have something like a longer dependency chain. A good example
of this is the Chaplin project which helps building applications in backbone. Chaplin
depends on backbone and some other libraries which depend on jQuery and underscore. That
comes really easy. Better package management, we can define that dependency tree which informs
a build system to be really smart about building that out for a very optimized output for production.
Then as a library author, it's really nice for your users to both consume your library
as a regular old install and also as a dependency of something else. How about instead of all
of those steps, we just have something Yeoman installed backbone, we have to update it instead
of all of these steps, Yeoman, very casually, hey, man, JavaScript library update, you have
got to update your backbone, it's the new thing. You're like, cool, cool, I got it,
Yeoman, update backbone. So I'm going to show you a quick look at Bower.
Bower is a package manager, it's being built by Jacob Thorton, who is one of the devs behind
Twitter bootstrap and Alex MacCaw behind The Spine (indiscernible).
And what we did is we basically took Bower and wrapped it right inside of Yeoman so that
again this accesses through the same interface. So we're over here in the I/O app and we'll
do Yeoman install backbone. So right now, what it's doing, is Yeoman is
talking to Bower, Bower is going to go and talk to the registry, say, Hey, I need backbone,
cool. I just got the backbone package, it's dependent -- my dependencies are underscore
and jQuery, please get those, okay, cool, got those.
And now we've installed into our app into the js browser modules backbone jQuery and
underscore. So if I go into js browser modules, we have
all of our files right there. So I'm saving a lot of time not going and
getting all of these things and keeping them up to date. I'm able to manage my dependencies
from my app right here on the command line, which is really nice.
So this is -- this is where things are going with that. So -- so in summary for Yeoman,
we can start out new projects really easily. We get a fast, iterative loop when we are
doing development. Understanding preprocessors like Sass and CoffeeScript, module systems
like AMD and ES6. I didn't show how we can run our files against
js hint. Or even the build script, which is pretty robust. It's built actually on the
original build script for the HTML5 boilerplate. But we have done a lot of research into image
optimization and found the most effective loss list image compression we can do.
So Yeoman is available on the dev val for preview, if you go to Yeoman.io you can sign
up and get notified when it's totally ready. We're just doing a little bit of buckling
to make sure that we're looking good. We also want to make sure that our package manager
has enough packages so that when you want to start an app and add things, everything
is there for you as you want it. So we're letting in a few people, just to
kind of kick the tires and we'll have it out available for everyone publicly soon.
All right. So ... summary. Tools are your friends, they're good, they increase your
productivity, lower your stress, help you out when you use them in a work flow that
works really well for you. We're working on Yeoman. Tell -- make it easier to consume
these smart tooling choices and help you build compelling web apps.
And thank you very much. [ Applause ]
>>Paul Irish: If you have any questions, go ahead and step up to the mics in the aisles
and that would be rad. >>> Thanks, Paul.
>>Paul Irish: You're welcome. >>> So Paul.
>>Paul Irish: Sir? >>> I saw Jasmine, is there going to be other
testing like plug-ins or -- >>Paul Irish: So since we are built on -- on
Grunt, if you are familiar with that, swapping it out for -- for a different testing suite
is as easy as editing the Grunt file. So it's not too bad. But we -- we made choices that
-- we wanted to have some smart defaults in there, so we went with Jasmine because we
really like its style. So it is configurable, but we wanted to have something that gets
you off and going from the start. >>> Awesome.
>>Paul Irish: Cool. >>> Can I get an invite? [Laughter]
>>Paul Irish: Yeah, yeah. You talk to me, talk to me.
>>> Um, when you -- after you installed Yeoman and you were making changes, changes were
loading in the browser, was that live reload or was that something in Yeoman?
>>Paul Irish: So we are actually leveraging the JavaScript shim that the live reload project
used and we're injecting that into the page. And so we're using a portion of the live reload,
but it's really just JavaScript that's making that happen.
>>> Okay. So ensure one doesn't have to have live reload to have that feature.
>>Paul Irish: Right. That feature comes through Yeoman, so you don't even have to have anything
else installed yet. >>> Okay, thanks.
>>> So you showed us the testing and the development side. I'm guessing part of the build process
that you didn't have time to show us was building for deployment. Would that also include being
able to use the closure compiler to have source mapping? Um ... yeah. Right now, um -- right
now our build step goes through uglify, but we're looking at a nice way to run it through
a closure compiler, because I like source maps just as much as you do. So there's -- there's
a few issues and discussions open to get source mapping into Uglify and to CoffeeScript, neither
of them have landed yet. So we're waiting for that, but in the meantime, yeah, I would
really love to find a nice way to get source maps into the closure compiler.
>>> Right. And there was an issue around having multiple source maps and trying to read from
each other. I'll catch you at the code lab. >>Paul Irish: Sure, yeah, sounds good. Sir?
>>> All right. What kind of requirements do I need -- for my server when I want to deploy
this Yeoman created app? >>Paul Irish: Um, no specific requirement.
It's completely up to you. So -- so it's -- it's basically we don't make any requirements as
far as your back end. It stays completely client side only whereas another solution
might say this is your database on the backend or we're going to serve it up to Engine X
or something like that, but that is completely up to you.
>>> I see. Okay. >>Paul Irish: Yes, sir, one more.
>>> This one is for Louie. So how much do you know about like the Bower package manager,
how hard is it going to be to get a package into it?
I noticed that it looked like it was cloning, so if you push that back up to GitHub, like,
is there like weird issues? >>Paul Irish: Um ... well, I can answer the
first part at least. So it was previously called nest and I'm accessing
it, this way. And registering a new package is as easy as that. Bower. Register the name
and the URL of the get repo. It's very, very easy and there's a package.json file that
has the meta data available for the package. There's no strict dependency on GitHub, but
there is a strict dependency on git, and clone each package, find out its dependencies and
the team is finding ways to optimize that and say, for instance, grab the zip download
if it's a GitHub situation instead of cloning the entire repo, finding out how to make that
really nice. Cool? All right. Thank you guys, appreciate
it. [ Applause ]