[APPLAUSE] (Wes Bos) Thank you.

Hey, everyone.

How's it going? Doing pretty well? Awesome.

Thanks so much for coming out.

I'm really excited to be here.

My name is Wes Bos.

I come all the way from Canada.

I'm actually 100% Dutch, so I have Dutch blood.

However, I grew up in Canada, so I've got culture but not the language, which kind of disappoints me, because there's a lot of nostalgia here walking around and listening to everyone speaking Dutch.

So I've got a whole bag of stickers.

And if you want a handful of stickers, come teach me a Dutch word.

And then I'll give you some stickers.

So I'm a front end developer.

And I work with start-ups and agencies to actually build their products.

I bet on JavaScript.

Yesterday, we heard a lot of just bet on JavaScript, just do everything JavaScript.

This talk is going to be very similar.

I also do a lot of teaching.

I sort of pride myself in being able to simplify tough things for people to kind of easily understand.

These slides are going to have lots of links.

They're going to have all kinds of really great tools that we can use.

So I'm going to tweet out the link to the slides.

I'm @wesbos on Twitter, w-e-s-b-o-s.

And I'll be sure to tweet it out, as well as the actual source of these slides will be on GitHub as well.

So I'm going to be talking about a lot of the tooling today.

And these slides are built in JADE, Stylus, Gulp, all kinds of these-- SNES-- all of these different tools that we're going to be using today.

So I love tooling.

I absolutely obsessed with it.

And one of my favorite tools is Sublime Text.

I wrote a book and video series.

Just over a year ago, it's been out now.

And it's just aimed at getting people to absolutely master Sublime Text.

I also wrote or recorded a 20-video series called Command Line Power User, which is targeted at getting front end developers comfortable in the command line, because a lot of these tools are actually going to be running via the command line.

And what I've noticed through my teaching is that people open up the default terminal in OS X or they open up to the Windows whatever that car wreck is.

And it's hard to move around in it.

And there's a lot of tricks that can be gained.

So if you're interested, it's a free video series.

And then I also recently released What The Flexbox?! It's at flexbox.io.

And again, Flexbox is really hard to actually understand.

And I recorded a 20-video series just aimed at getting you to master all of the different pieces of Flexbox, as well as how you can use it.

Sorry, is this-- I feel like it's-- is it on still? Yeah? OK, cool.

So let's talk about tooling.

And in order to talk about tooling today, what I want to talk about is I just want to tell you a story about another industry altogether.

It's about the plumbing industry, which has nothing to do with the front end development scene.

However, I'm seeing sort of a lot of the similar things happen there.

And in the plumbing, plumbers have a lot of traditional tools.

To put just two pipes together, we have sort of three main ways.

We've got copper soldering, which is sort of the way that most people do it, use a blow torch.

It often starts fires.

It's prone to cracking at the joints, especially in Canada.

It's very cold in Canada.

And when it gets cold, what happens is the water freezes and the joints pop, causing leaks inside of people's walls.

There's a high level of experience actually needed to get up and running with that.

There's also messy glues.

If you have PVC, like plastic pipes that you want to put together, you've got like three seconds in order to put them together.

If you screw it up, you've got to saw it off and start all over again.

And then we have compression fittings, which is based on the compression of the water.

It's always prone to leaking.

And it's extremely difficult to install.

So these are kind of the three things.

And people in the industry are just like, well, you just learn to sort of be good at it, and that's why.

However, a couple years ago-- at least in Canada and the States-- something came around.

It's called SharkBite.

And it's just totally rocking the industry.

And what SharkBite is it's a new type of fitting that allows plumbers to attach any type of pipe together.

It's essentially just LEGO for plumbing.

It's just making it super easy to do any sort of plumbing.

It just snaps together instantly.

It can connect any material to copper.

So if you're switching between copper and PVC or copper and Pex, what it does is, you can just [CLICKING SOUND] click them together, and it just works.

It can be redone at any time.

If you screw it up or you want to redo it, all it takes is like a $2 tool to just snap it off and try again.

It's much less prone to leaks, which is at the end of the day, that's the only thing you want out of your plumbing-- just don't leak.

So SharkBite is more expensive.

I think it's something like 10 times more expensive per joint.

However, it allows you to work much faster.

And it's much less error prone.

Many plumbers have sort of look in-- or look in-- [CHUCKLING] they've looked at this SharkBite, and they've written it off.

It's too fancy.

It's too expensive.

It's not the way that I've always done it.

And I don't see why I would switch now.

But it's absolutely changing the industry.

It's absolutely changing how much plumbing costs for people, how fast you can get something done, and also who can do the actual plumbing.

Many of the plumbers in the industry, they're just blind to the benefits.

And I think that we're seeing something similar.

Web tooling is evolving in exactly the same way.

Some developers, they're writing it off as over-engineering.

We here a lot of jokes, as like SNES and stuff like that.

And I think that's hilarious, because the scene is moving really quickly right now.

However, others are absolutely realizing the benefits and how it can help you.

So what I want to say is, before we get into any of this, there's a absolutely fine line between tooling for tooling sake and getting real work done, because at the end of the day, all of us here have jobs, and we need to ship the website by Friday.

We need to get our work actually done.

And we've all spent half a day, a day, trying to get our tooling work just to throw our hands up in the air and be like, it's not worth it.

It's really just getting in the way.

So we need to be smart about the tools that we're using.

Any time that we're investing in our tools should be brought back by greater efficiency or even better is better, more resilient code.

We should be writing better code, because of these tools, not just because it's the new hot tool on the block.

So I know a lot of you right now are saying there's way too many out there.

We saw last slide, SNES, joke, whatever you're going to call it.

What should I use.

It changes way too fast.

I'm extremely overwhelmed.

And I hear this over and over and over again, both by people who are new to the industry trying to break in, like Bruce was saying, as well as people who are in the existing industry.

And they've sort of had their tool set down pat.

And now, it seems like every four months everything changes over and over.

So this talk, I want to bring you from crying emoji all the way over to happy emoji.

I'm going to talk about some of the popular workflow components.

And I hope that you can sort of take away three or four things.

You might not take everything I'm talking about today and go ahead and implement it on Monday.

But I hope that there's a couple little nuggets in here that you can take back and implement in your own workflow.

So before we do that, let's talk about build tools.

And I think that this is the absolute biggest barrier to entry.

We've got Grunt, Gulp, Broccoli, NPM, Webpack, all these different tools out there.

There's probably 100 more.

Not all of them are created equal.

First of all, what are they for? Well, they can be for compiling, converting your styles.

They can be for concatenating your scripts, your styles together.

They can be for running your tests.

They can be for deploying your actual website from your local to your server.

They can be for any sort of tasks that you want to automate.

Anytime that you feel like you're doing something and you only know the steps of it, just automate it.

So the two kind of big ones out there right now are Grunt and Gulp.

They essentially do the same thing.

There's some minor differences between the two, where Grunt does one task at a time and Gulp will do sequential tasks.

A Grunt files is more configured, so it's a big JSON file.

Whereas, a Gulp file is coded.

You can write your JavaScript in there.

And Grunt will write to the file system, while Gulp uses-- it pipes it through streams and uses buffers.

There's also NPM as a build system.

Recently, we've been seeing a lot of people being like, you don't need the bloat, bro, of Grunt or Gulp.

And what you can do is, if you're using Node and you have an NPM package like JSON, right inside of there, there's a little object inside of your package JSON called scripts.

And you can put any bash strings that you want in there.

And the way that it works is, rather than using like a plug-in for Grunt or Gulp, like gulp-uglify or grunt-autoprefixer, it uses the exposed command line interface that all of these tools give you.

And you can just run it right from the command line.

So a lot of people have been saying, it's so simple, it's so easy, why would I ever use Gulp.

And it turns out to be something like this, where a lot of the simple examples-- and if you've got a really simple site, then it might make sense.

However, I've found that if you like righting bash tasks and stringing them together and piping in all your arguments, then go nuts.

However, I find that it's a little bit difficult to follow, especially when we're talking about working on teams and maintainability and onboarding our new developers who are joining the team.

I think it's a little bit hard to sort of throw that at them and say, hey, could you change this to add source maps? Webpack is another big one right now.

It's more focused on JavaScript modules.

It's sort of Gulp meets Browserify.

I'm going to talk about JavaScript modules in a future slide.

And it sort of does both.

It comes batteries included for a lot of the common tasks, which is something that's really nice.

It's not always great to have to find a plug-in for everything that you want.

It's super powerful.

It's got a bit of a hard-to-learn API.

And it's really popular in the React community right now.

There's something called React Hot Loader, which will swap out your bundles without having to reload the page for you.

So which one should I use, is what everyone's talking about.

I taught at the workshop on Gulp on Wednesday here at Fronteers.

And a lot of people feel kind of burned that they use Grunt now that they're trying to learn Gulp.

And they're worried that next six months we're going to be changing to something else.

It really doesn't matter which build tool that you're taking-- whatever is best for you, whatever is best for your team.

I personally think Gulp is best fit for myself and for a lot of people just because of the build speed.

It's got packages available for pretty much anything that you can think of.

The ease of authoring and understanding, I find it's easiest to jump into a Gulp file and just understand what's going on.

It just reads like regular JavaScript, especially someone who's just used to writing maybe some just regular jQuery, something like that.

And it has overall industry acceptance.

So there was a poll that was put out to, I think, about 1,500 developers.

And 47% of them use Gulp.

And that 20% of them don't use a build system at all, which is really worrying.

And I have a feeling that it's a little bit higher in the areas of people that don't take online surveys about JavaScript tooling.

So what I want to say here is that having a build tool is probably the most important thing that we can do here.

Once you have a build system in place, you can use all of the packages that are available to us.

And it's really easy to just insert one of these things I'm going to be talking about into your tooling chain.

So I think that's the biggest barrier to entry.

And I want to thank Sass for really getting people on the build tool train, because before that, almost nobody was using build tools, unless you were sort of a back end developer with some really advanced stuff.

So let's talk first a little bit about performance.

I'm really glad that we've had-- we seem to have a lot of performance talks, a lot of underlying ideas about performance here at Fronteers.

And the first one I want to talk about is something called Critical.

Yesterday, Jake was up here talking about first paint.

He was talking and he was complaining about people that put these huge CSS files in their head, because the CSS files are blocking.

And ideally, what you do is that you use something like load CSS, which is going to load your CSS file asynchronously.

It's not going to block your render.

And your page is going to be way faster, which I totally agree with.

And then he also said that you need your first paint or your critical path to be like immediate for people.

So what Critical does is you pass it your HTML or your web page.

And you pass it your CSS.

And you pass it how big you want your viewport to be.

And what it will do is it's going to strip out all of the actual CSS that's needed for that first paint of the screen.

You can call it above the fold if you wish.

And you can either inline that, writing your elements, or it will kick off a style sheet, which you can put in some style tags or something like that.

So it looks a little something like this, just a couple lines, where you pull in your source.

And you give it your destination as it walls your width and your height.

And it's going to kick out a whole bunch of CSS that out of your entire project you need this CSS to get your first paint to that really nice and fast first load for your user so they can start to orient themselves on the website before you go ahead.

Next one up is something called Purify.

And what this does is it removes unused CSS for you.

So we all are a little bit embarrassed, but we all have projects that have been around for a couple years and they're starting to get a little bit crusty.

Or we're all using Bootstrap or Foundation or whatever thing.

And we know that there's probably some CSS in there that we're not actually using all that much.

So what Purify does is it will just look at your HTML.

It'll look at your JavaScript, which is amazing.

And it will figure out what classes are using in your HTML, as well as what selectors are you going to dynamically generate in your JavaScript in Angular, in jQuery, in React, whatever you're using.

And it will take your CSS and just trim it down to what you're actually using.

And you can deliver a much smaller CSS file to the browser without the stuff that you don't necessarily need and without the like two days of just kind of searching through your website and running difs.

So it works a little something like this.

This is just a Gulp task.

But again, all of the stuff I'm talking about today, it's not specific to Gulp or Grunt or Webpack.

These are just tools that run on your computer.

And Gulp and Grunt are ways to access them.

So you pipe in your CSS.

You give it access to any your JavaScript or your HTML or any of your templates that you're going to be using.

And what it will do is it will spit out your CSS without the stuff that you don't need.

Next up is imagemin.

Image compression is so hard.

I think that most devs, they don't care enough, or I think it's just a little bit too hard to actually implement it into their workflow.

And that's really a bummer, because generally, the images are what slows your website down.

Like we can talk about 20 meg or 20K JavaScript file, and then you load like a 3 meg hero image on the landing page that you have on your hero.

So what imagemin will do is it provides a common easy-to-use interface for 17 of the different image compression libraries, because these image compression libraries, they're written by really smart people in really low level languages, like C. And it's often

really hard to install them and compile them and run a makefile or whatever it is that we use on them.

So what imagemin does it gives you a JavaScript interface for using all of these different ones.

So this is the way that it looks, is you just pipe in all of your source images.

You can set a whole bunch of different settings, depending on how much.

The default is generally pretty good.

You can-- also by default, it comes with four plug-ins for GIFs, PNGs, JPEGs, and SVGs.

However, you can use any of the additional 17 that I said.

For example, I really like Maas.jpg.

If you've never used Maas.jpg before,

I absolutely recommend you do.

It does a great job of just getting all the extra size out of your JPEGs.

And then once you're done with that, it will compress them into a compressed folder for you.

So like, do you have 7.75 seconds?

A lot of people say like, I don't have the time to actually implement that.

First of all, this is just, what, 10 lines of code or something like after I've installed it.

So that's not an excuse.

Do you have 7.75 seconds?

Probably.

I've asked that question twice now.

And that's what-- oh, I did.

So I made a Gulp task.

And I ran through a couple of my really big images that I had, or just a whole bunch of different SVGs and PNGs and JPEGs.

And out of that, I saved 60.5%.

It saved me 3.69 megs, which

by default, that's quite a bit.

So I definitely recommend you do that.

Next one up is called UglifyJS.

UglifyJS, it's kind of standard when you're trying to minify, compress, or mangle some of your code.

And it's really great, because often your code that you write has lots of spaces, lots of comments in it.

Maybe the parameters you're writing in your methods are really long.

For example, if you use the word background color as a perimeter, that's great, because it's very descriptive.

However, it's very long.

And the longer your parameters, the bigger your actual file size.

So what I did is, I took a huge JavaScript app that it has, 2 and 3 megs.

And it went down to 405K with just the defaults that we have there.

And you can get even a little bit deeper.

Here's an example of what the code looks, where I've got some React on the left hand side right here.

And you can see that I'm using the variable key, key, key and key, four times.

And if you look at the Uglified version, it just strips all the comments, all the spaces, and everything.

And then it replaces key with e, just because the computer doesn't care what the variable is called.

It can be called e, it understands what it's going to be doing.

And it sort of just saves you quite a bit of space.

Let's talk about dependency and module management.

So I've actually heard quite a bit about this.

We had a talk from Chris on Saas, where he was talking about CSS dependencies.

And guess what it was using? It was using node.

So we'll be talking about that.

So I think right now we're seeing a huge shift in how we manage front end dependencies.

The old way that we used to manage dependencies was something like this.

We would download it from GitHub.

We would unzip it.

And we would move the files over to our project after we figured out which ones we actually need.

We would pop in another script tag.

And we would rinse and repeat for every single plug-in, library, script tag, whatever you need.

And one day you wake up you got 79 script tags in your document, because you just sort of kept adding them in.

Or you've got five different versions of jQuery being loaded, because you've got all these different plug-ins and you don't know what's going on, or three of your plug-ins are all loading lodash as sort of a helper library to use internally.

And we don't want to be doing that.

And I think that the answer to this, the future is using modules.

And we've actually had modules in JavaScript a long time.

We've had them in node since the beginning of node.

We've had module builders and bundlers for quite a while.

However, I think with the rise of the popularity of build tools, we're starting to see a bunch of uptake in people using JavaScript modules, rather than just writing a whole bunch of script tags and putting them into the body.

So how do something like this to work? First of all, you need to go ahead and install your library.

So I'll use jQuery here as just an example, as probably everyone here has used jQuery before.

So you use some sort of package manager-- and I'll talk about these in a second-- where you run NPM or Bower or JSPM install and then the name of the project.

And what that will do is it'll go off to the registry, download it, and put it in a folder for you.

So that's how you install it.

Then you go ahead and write your actual code.

So there's a couple of different ways that you can do it.

Here's two of them, which is CommonJS, which is the node style.

You probably have seen this quite a bit if you've ever written a Grunt file or a Gulp file or even done some node yourself.

So you say var dollar equals required jQuery.

And instead of having just something in your window called dollar, what it will do is it will load jQuery into your dollar variable.

Or even better, we have seen ES6 being standardized now.

And ES6 has a spec for modules, which you can import dollar from jQuery.

And as long as jQuery is set up or your packages are set up to export that, it will work in the same way.

And then finally, you've got to compile into a single or multiple bundle.

So you can take all these import statements.

You might have like import lodash or import jQuery.

You might have a whole bunch of them.

I'll show you some code in just a second.

And then we need some sort of tool that is going to compile them into one.

So Browserify is the biggest one.

It's got pretty simple API.

Webpack also does this.

So Webpack is sort of like a task runner, as well as a bundler, which will bring it in.

It also handles CSS.

It has built-in watching, which is great.

Browserify, a little bit tricky to get set up with watching by default.

And then we have JSPM, which is client side by default, which is great.

I think-- was it Scott that talked about HTTP2, which is coming? Eventually, we won't need some sort of bundler that will bundle it for us.

Eventually, we'll just import it right inside of our JavaScript files.

And the browser will be able to request like eight assets all at once without having to do eight separate requests.

It'll be able to just say to the server, I need these eight things.

And it will come on back.

So that's sort of the idea with the ES6 spec.

And JSPM has started trying to replicate that.

So that's a really simple one-line example of all of these.

You could spend all day.

I'm sure some of you will come up and have a nice heated discussion with me as to what your favorite is.

I like Browserify just for quickest setup and for your team.

But again, whatever works for your team.

So hold on, what about Gulp? What about Grunt? Where do these fit in? Well, I get this question a lot, where people are like, OK, should I be using Browserify or should I be using Gulp? And do they fit together, or are they two separate things? So I want to just clarify this.

Gulp and Grunt, they're task runners.

They simply just sit there.

By default, they don't really do much, except move your files from one place to another.

But they sit there and they say, run this task, run this task, put these files here.

And it will do all of the sort of orchestrating for you.

And one of your tasks inside of your Gulp file is going to be bundling your JavaScript.

So that's just one part, where Grunt and Gulp, they can call Webpack, they can call Browserify, they can call JSPM for you and bring back an actual bundle for you.

And then you'll also have a styles task, an image compression task, a deployment task, whatever fits with your workflow.

So back to modules.

Let's look at some code here.

Right here, what I've got on the left hand side, I just got an example of some cart.js, where

I wrote a little module to handle all of the shopping cart stuff, where I created an object called cart.

And inside of it, I've got check out an add, which is two methods that I'll probably need to access.

And inside of that, it has dependencies of Stripe, MailChimp, and jQuery, which-- this is just fake code, by the way-- it will just charge the customer.

It will email the customer.

The add, when someone adds one, it will hit the shopping cart end point and then do a whole bunch of stuff.

Then on the right hand side, we've got app.js, which you are

going to actually write it in.

And what we can do is we can import the cart from that other module.

You see how we've exported the cart from this file here? Now, it's sort of just like this little module that you can pull in, in whatever bundle or whatever project that you actually need.

So we import it here.

Notice how I'm also importing jQuery, because it looks like I need jQuery here to handle my event listeners.

And the beauty of that is it's not going to include jQuery twice for you, and it's not going to bloat your file size.

It's going to figure out that, OK, well, you used this dependency twice.

We'll only load it twice-- or only load it once. [CHUCKLING]

So sort of the whole idea behind this packages thing is small modules that do one thing and one thing well.

And we've seen this in a lot of different software landscapes.

And I think because of node, because of all these things, we're starting to see it move on over to the JavaScript scene to the front end JavaScript scene.

So only need Ajax.

I've been using jQuery in these, but you might not necessarily need the whole thing.

Then what you can do is you can just get a module that just does Ajax for you.

So you can npm install fetch, import fetch from fetch, or var fetch equals require fetch, if you're using the CommonJS syntax.

And then you can just go ahead and use that.

There's no-- I know a lot of times when you have a problem in front end development, someone will suggest a library to you.

And you go, [SIGH] I don't want to install another library.

I don't need another dependency.

I don't need another plug-in to do this.

However, these little modules, they're tiny.

Sometimes they're 20 lines of code or 30 lines of code, just to get that one thing that you need done.

And you'd write that much code anyway if you needed to do cross browser Ajax.

So again, small modules that do one thing well.

Pick and choose from lodash, so I love lodash and underscore lodash more.

But I never acquired it in all of my projects, because I always thought to myself, like, yeah, it's great.

I need like one thing from it, and I don't need the entire library, and I feel like it's a little bit much to load the entire library.

So what you can do is, lodash is coded in such a way that every single method inside of lodash-- and if you don't know what lodash is, it's like a helper library for working with arrays and objects and stuff like that-- and what you can do is just create a variable called underscore.

And inside of that, you can just cherry pick.

Like here, I only needed Object.assign

or the assign lodash method here.

So I just cherry picked that one in there.

And lodash is smart enough to just export that one module plus any of the dependencies that assign needs from the lodash library itself.

So NPM, show I use NPM? Should I use Bower? Should I use JSPM? What is JSPM? I haven't even heard of it before.

These are all registries.

So when it comes to installing your actual dependencies, there are sort of two main ones.

We have NPM and we have Bower.

JSPM just sits on top of the NPM registry.

The main difference that we have here is that NPM supports nested dependencies, while Bower has sort of a flat tree.

And the nested dependencies, it's really nice, because again, small modules that do one thing.

Sometimes, your module need to pull in someone else's module to actually work.

So what I recommend is just use NPM for everything.

You might've come here saying like, isn't NPM just for node? Isn't it just server side JavaScript? And it initially was, but we're starting to see NPM used for absolutely everything front end.

What NPM is getting is a thing called ecosystems, which is essentially just categories inside of NPM.

And it's going to allow us to just categorized all of the different modules in NPM.

So sometimes, they're only going to be Gulp or Browserify or for Windows.

Sometimes, they're going to be specific for using like Tessel, or Johnny-Five, or something like that.

And what you can do is you can just search inside of these ecosystems for the actual package that you want.

And often these modules are going to work both on the server, as well as in the client, which is kind of cool.

So the future, I'm really excited about the future.

JavaScript, CSS, they're evolving super rapidly right now.

And what's cool about that is that we can actually start writing future code today.

We don't need to wait.

When CSS3 came out, everyone's response was yeah, it's great, but I can't use it yet.

I need to support IE8, or I need to do support-- I guess at the time, it was like IE6.

And that was kind of a bummer, because we had to just kind of sit on it and wait for us to actually use it.

So let's talk about the future of JavaScript.

Then we'll go to CSS.

We've got the next versions of JavaScript coming out.

We've got ES6, ES7.

I called they're called ES2015, 2016.

I think those are dumb names.

ES-next, all kinds of useful new features coming to JavaScript.

For example, we have arrow functions.

Rather than writing the word function, we have arrow functions, which allow us to scope the keyword this.

We've got let and const variable declaration.

So instead of using var for everything, we can use let and const, which allow us to have scoped to the block rather than actually to the function.

We've got template strings, which I always get really excited about template strings, and then everyone is like, uh, we've had that in PHP or Java or Ruby for 20 years, Wes.

But what template strings let you do is, rather than having to concatenate your variables and your strings together, is you can just dollar sign, curly bracket, and then put your variable or even put your own JavaScript, or you can even put another template string inside of it, which is pretty cool.

So that was huge for me, because I hate concatenating strings together.

I always screw it up.

And there's many, many more features that are coming to the browser as part of ES6, ES7, ES8.

And we can start using them today.

So has anyone here used Babel before? A couple of you, awesome, that's great.

What Babel will do is it allows you to write ES6 code and compile back to ES5 code.

It allows you to write the code that we want to write today, and it will sort of shim it for the code that works in the browser today.

It will compile it to something.

So let's take a look at that template string one that I'm so excited about, where I've got these variables right here.

They're using let, and they're popping them in there.

And once I throw it through Babel, it compiles down into ES5 that's compatible with all of our browsers today.

So it uses concatenation.

It switches them over to var.

It takes care of all of the scoping issues that you might have with that.

So absolutely fantastic tool.

I definitely recommend putting that one in.

It works with Gulp, Grunt, Browserify, Webpack, or even the command line.

It works with all of these things, where you can just stick it into your tool chain and start writing ES6 code today.

But what about new language features? So that stuff I just showed you, that's just syntax.

That's just kind of-- they call it syntactic sugar, where it's just like kind of fun to write it, and it's a little bit easier.

But it doesn't actually add any new features to the language.

So we're getting new things, new methods, new loops, new features that are actually coming to the language.

And for almost all of those features, we can polyfill them.

And if you're using Browserify, Webpack, whatever to bundle your JavaScript, you simply just need to require babel forward slash polyfill.

And it will figure out which ones are using and polyfill them for you.

So you don't have to worry about, can I use Object.assign

yet, or is it not supported? You don't have to go to can I use and figure out, all right, we're supporting these ones right now.

It'll just work for you.

It'll just recreate it in ES5.

So CSS4, it's not actually called CSS4.

It's-- I don't know, it's some like the next generation of CSS.

But it's really exciting to call it CSS4, because everyone was all jacked up about CSS3.

So I'm get excited about CSS4.

So everyone loves, loves, loves Sass, LESS, and stylus.

These are some of the best fantastic tools that we've been using.

And CSS is sort of taking note.

They're saying, well, if everybody uses Sass, LESS-- like who uses a CSS compiler here? Everybody does, right? Nobody just writes regular CSS anymore.

So CSS, the language is evolving.

We're getting the things that you know and love in Sass and moving it over to regular CSS.

So we're getting variables.

We're getting nesting.

We're getting scoping, all the things that you love.

And it's actually going to run in the browser for you.

So we have the ability to make things a little bit more dynamic than just compile time.

So just as we use Babel to compile from 6 to 5-- ES6 to 5-- we have cssnext, which allows us to write feature CSS today then compile back into the CSS3 that we know and love today.

So that allows you to start writing your new features today.

It's written in JavaScript, and the compile times are lightning fast.

So it's not something that you really have to worry about having a slow compile time.

It's part of the postcss ecosystem, which means that if you haven't heard of postcss before, it's sort of like another compiler, except rather than having everything batteries included with something like Sass or LESS or Stylus, you can write your own transformers forward or pick from many of the hundreds that we have available in the community.

It's sort of-- I don't know, it's both good and bad.

Part of postcss is that you have to require all these plug-ins every single time that you need it.

And it's actually what autoprefixer.

So if you're using autoprefixer, autoprefixer is just a transform built on top of postcss.

It's going to add the prefixes in for you.

So it looks a little something like this, where you grab the CSS that you've written, the CSS4 that you've written.

And then you pipe it through postcss, and you pass postcss any of the other plug-ins that you want to use.

So cssnext is a postcss plug-in that will compile it down to your other ones.

And then there's other things like quantity queries.

So has anyone heard of quantity queries before? It's basically this trick that like some weird nth child, negative nth child trick, that allows you to say, if I have four children, style them this way.

However, if I have more than six children, style it a different way.

So you can select your elements based on how many of them there are, which is really cool.

However the syntax for it is just absolutely bizarre, because it's a hack with nth child.

So quantity queries lets you do something like pseudo-selector at least four, and then it will compile onto the weird nth child one for you.

And then you can pipe to the build directory once you actually want to save your CSS.

You can run it through anything else at that point as well.

So workflow treats, so these are just some of the small things that I think that you should add to your workflow.

You may already have a couple of them as well.

And the first one is probably one of my favorite tools for doing development.

And that is Browsersync.

So anyone here use Browsersync? OK, maybe about 10%.

Hopefully, after today, it will be 100%.

And what Browsersync allows you to do, you can see I've got my terminal open here, and I'm running a Gulp task that when I change my CSS file, it recompiles it.

And then it automatically refreshes your browser.

Sort of like, you remember LiveReload? It's like LiveReload, except it actually works.

LiveReload never worked for me.

What is it? So that's just one part of it.

It has instant reloading after live changes are made.

You'll notice that in that video there, the page isn't refreshing.

Just the CSS in the background is actually refreshing and allows you to just work much faster.

I find myself not living in the dev tools changing things around as much with it.

It includes a server with assert for easy local HTTPS.

So if you've ever tried to install SSL on your local host computer, you'll know that it's not possible.

It's so hard to actually get up and running unless you're like a sys admin who knows how to assign keys and put them in the right place and set up like an Apache server, whatever it is on your desktop.

It proxies existing applications or servers.

So a lot of times, people come to me and they're like, yeah, it's great, but I already use a server; and Browsersync has a server built in; our application is hosted on Rails, or it's wordpress.org,

or it's some sort of Python app that we've built.

What it will do is it sits on top of your application, and it does all the find and replace on the URLs for your own local host URL.

And you can view it through that and allow for these immediate changes, as well as all the other stuff that Browsersync has.

It exposes a server via local IP, so you can test on multiple devices.

If you've ever tried to work on an app that has local host hard coded everywhere throughout the source code, you'll know that you can't just pull that up on your phone.

You have to deploy it to a server or somewhere that it's accessible to you.

So what it does is it gives you a local IP.

And then anybody on that Wi-Fi can access that IP address and see your website in real time.

It also has local tunnel built in, which allows you to expose it to the internet, which means if you have a client on the phone and they're complaining about something, you can say, hey, go to this URL real quick.

You can edit it in real time, and it will just refresh immediately before their eyes.

It syncs, clicks, submits, scrolls.

So if you've got a device wall-- I know some people have shown me the pictures of the device walls at their companies; they're pretty cool-- if you click on a page on one, if you submit a form on one of them, if you scroll on one of them, the rest of the pages are all going to follow suit the rest of your device as well.

It's just absolute magic.

I just absolutely love it.

And I think that everyone should be using it.

So if you haven't, definitely check out Browsersync.

It's pretty simple to get up and start it.

And in fact, these notes right now are running on a Browsersync server, which is great that no one has found my IP address.

Sourcemaps, it's not uncommon-- so this is something different-- it's not uncommon for your code to go through a few steps.

We're not just writing JavaScript and popping in a script tag anymore.

We might have Stylus.

That gets turned into CSS.

That gets piped through autoprefixer.

That finally gets put into CSS.

We have ES6 that gets piped through Babel to Browserify to UglifyJS.

And finally, it's just JavaScript in the browser.

So what happens when there is original-- when there's an error in your code? What happens when we want to trace back.

I've got this error in my compiled code.

But where does it exist in my actual source files? So for example, you have a bug in a Sass partial, called underscore typography on line 10.

However, once you've fed that through Sass, where does dev tools tell you where it is? It tells you it's in app.css on line what?

One, right, because it puts all of your CSS on one line.

So it's not very helpful to know, OK, you need to edit this thing on line one.

Same with JavaScript, if you've got an error in like a React JSX component on a component called store.js on line 25,

but once you run it through Babel and transform the JSX and through Browserify, it's unrecognizable at the end point.

I showed you that code earlier.

So Sourcemaps are essentially treasure maps for your bugs.

If you've got a problem with your code, what you can do is it will allow you to bring it back to your original file.

So it looks a little something like this.

And thankfully, in the Gulp ecosystem and most of these tooling, Sourcemaps are standardized, meaning that different tools can communicate to each other with Sourcemaps.

So the way that works is you start your Sourcemap.

Then you run it through any of the plug-ins that you want.

In this case, I'm running it through Babel.

I'm concatenating it.

I'm stripping all my console logs or debugger statements out of it.

And then I'm uglifying it.

And then after I've done all that, I write the Sourcemap.

And all through these four steps here, what's been happening is the Sourcemap is just keeping track of where do I point arrows to store.js

to where it now is in the final outputed buffer.

CSS works the same way.

So I'm using Stylus here, but works with Sass, LESS, whatever you're using.

You start your Sourcemaps.

You run it through Stylus, autoprefixer.

And then you write your Sourcemaps.

And what that then does is in your dev tools-- if you've got an error in your JavaScript console or you're trying to debug it via something like this-- is your dev tools will show you the actual source file, because your browser doesn't understand Stylus or Sass.

However, you can see exactly where they were typed in your actual partials, rather than the compiled source.

And if you click it, you'll be able to see the entire file.

So, ooh, that was a lot.

I know that I threw a lot of tools at you.

But really what I want to sum it up with was that tooling is extremely, extremely important.

I think that we should all have some sort of build process in place, because once we have a build process in place, the sky is the limit.

We've got hundreds and hundreds of different tools that are going to be perfect for our workflow.

We can pick and choose the pieces that we want.

And our websites and our code is going to be better for it.

So that's it.

Thank you so much.

I'd love to chat with Mr. Bruce here.

[APPLAUSE] Well, that was really cool.

Is this on? I'll just sit here by myself.

Can you hear me at the back? Whoa.

That was really cool.

Thank you very much, Wes.

And a lot of people said it in the comments that you energize them with your energy on the stage when everyone's feeling hungover and certainly feel more vibrant.

There's lots of questions, like shed loads, so we won't get through them all.

And some of them are highly specific.

Don't feel embarrassed about saying, I just don't know the answer to that particular combination of stuff, OK? Yep.

But they're a mean lot, and they like to ambush you.

But the first one is a wider question from self-confessed, grumpy, old man, Remy Sharp, who asks, what's the cost of learning some of these tools, as opposed to just learning bash? It feels to him a little bit like learning jQuery rather than learning JavaScript.

Yeah, I think that I hear that a lot from people that already know bash.

And you hear that a lot from people that really know JavaScript.

They say like, oh, why don't you just do it yourself? It's just coding 6,000 lines and just place it into another.

And I think that's great.

If you know the tools and it works for you, then absolutely go the bash route.

But a lot of people don't know it.

And I think that it's just such a huge barrier to entry.

I teach a lot of people who are new to web development or have not necessarily went down that road.

And it's really hard for them.

You can't just tell them, pop open your console, and start running all these things, and pipe them into each other, and turn on Sourcemaps with dash dash Sourcemaps.

So I think the cost is-- I don't think it's any-- I think it's less.

I think because people already know JavaScript, you can start to use Gulp.

I teach a one-day class in it, in which that we get into everything there is to know about it.

Whereas bash, I think, might take a little bit longer.

So I definitely think that it can speed you up, especially for front end developers who aren't necessarily as technical.

They're coming from CSS, HTML, and others.

They're starting to dip their toes in JavaScript, because the front end dev scene is starting to change Yeah, I used to use command line stuff when I was an assembler programmer in the late '80s.

And I think that the last 20 years of computers means that I should never have to look at a command line again.

That's like my wife likes to go camping, but I pay money for central heating and double glazing, because I don't live in the Stone Age, is my personal opinion.

A couple of specific questions, people-- there's a general interest in things like Purify and Critical CSS.

But how well do those work with very dynamic sites, where there are many, many different kinds of pages? Any tips? Yeah, I haven't done it on a huge site before.

But definitely with something like that, you'd need to run-- you can't just pipe it HTML, because we all don't just have HTML files.

So at that point, you'd need to pull up some sort headless browser that sort of analyzes your code and kicks you back the CSS for that page.

So if you have like a CMS or something, you'd need to actually build that part into your CMS.

But you can still use node, critical CSS.

It's not specific to Gulp.

You can still use node to generate that for you.

And a very specific question from Bowser Vanden Eynden-- taking a punt on the name there, or the pronunciation of the name.

Super dutch, Vanden Eynden.

Vanden Eynden.

I don't know.

How to combine critical CSS into Gulp that's not a plug-in of Gulp.

Yeah, so on the Critical docs , there's a Grunt plug-in.

However, it says, when you're using Gulp, you can just call it directly.

So I guess it's set up to be able to pipe in a buffer from Gulp.

So you can just use it directly, like I was showing you in the notes there.

On the question of Gulp, a question from somebody whose name rhymes with Fitzalee Breedman.

Anything worth mentioning for generating markup with responsive images, all the hideous-- Yeah.

---feature elements with Gulp? There is a great plug-in for imagery sizing, which is great if you've got like a whole bunch images that you pulled off the internet and you want them all to be at least a certain size.

So it's called Gulp resize.

I don't know one that's specific for responsive, but I would imagine you can use it for that.

Beann or Bjorn Bunen said about something you said, why is it worrying if someone does not use a build tool? I'm betting he or she doesn't use a build tool.

Yeah, I think that it's not necessarily worrying, but I think that the front end dev landscape is changing so quickly.

And I'm worried that people will sort of get left behind in that.

And I see a lot of anxiety in people, where they feel like their skills are becoming out of date, because they've got work to do, and you don't necessarily have time to actually learn these tools.

So I think that like, if you can get past that initial couple hours of learning Gulp, I think you'll feel a lot better in your skill set, because it's really not that hard.

It seems pretty daunting to run all the stuff off here.

But it's really not that hard once you've got it up and running.

And then every time a new tool comes out, nothing is more than five or six lines in your Gulp file.

And it's not something you should feel too worried about.

And the last question, because they're going to keep my head in if I don't do some housekeeping announcements before the break.

This is a lot to take in.

I mean, you were having a high energy 50-minute presentation with lots and lots of information.

If I'm a beginning dev, straight out of college, where should I start to get my head around, not just the intricacies of the individual tools, but a general understanding of the landscape at the moment? My recommendation for something like that is just to start to build something, so have a need for compiling your Sass into CSS, have a need for compiling your Jade into HTML, and then just try it, build something yourself, look at examples.

Take a look at the source behind my notes here.

And you'll be able to see how I've done it.

I've got a whole bunch of different websites online.

Have a Gulp file, just sort of pick that apart, and try to build your own, rather than just sitting on your hands and reading through someone else's, because that really doesn't help too much.

So learn by doing, than by reading.

Yeah, just do it.

People ask me that all the time.

How do I get better at x, y, and z? Do it, do it, do it, do it, do it.

Do it 1,000 times, and you'll be amazing at it.

Good advice for almost every activity you can think of.

Everything, exactly go to the gym, you'll get fit.

Brilliant.

[LAUGHING] And you're putting your slides online, you said, soon afterwards.

Yeah, I'll tweet them out @wesbos in three seconds.

And I have stickers as well, if anyone wants a sticker.

I'll have a sticker.

[LAUGHTER] Look at this, I'm taking bribes on stage.

I said I won't ask difficult questions if he gives me a sticker.

Thank you very much, Mr. Bos.

You're welcome.

Wes Bos, ladies and gentleman.

[APPLAUSE] Thank you.