>>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
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.
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
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
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
up as real files. That’s pretty nice. Ember actually uses sourceURL to great effect
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.
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,
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
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
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
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
via ecmascript 6 module into our CoffeeScript application compiled down into ecmascript
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
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,
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
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 ]