The full video and many others like it are all available as part of our Frontend Masters subscription.

Kent C Dodds

Kent C. Dodds works at PayPal as a full stack JavaScript engineer. He host JavaScript Air and co-hosts React30 podcasts. Kent is an Egghead.io instructor and Google Developer Expert.

Kent C Dodds

PayPal

Kent spends some time walking through the Todo application he will be using throughout the workshop. This application will be migrated so it uses the features of Webpack 2.0. The code for this initial walkthrough is located on the 00-original-project branch.

Get Unlimited Access Now

Kent C Dodds: Your scripts should hopefully be done by now. So let's go ahead and explore things. So if you pop open your editor and you're terminal and you run npm start. Actually Iet me. So, you should be on the original project branch if you ran that script that's where you are.

If you run get branch it should be highlight, well I have a lot of branches on here but it should be highlighting the one that you're on. Okay, so now you can run npm start and this will start the http server for your app so it's let me pop this open elsewhere.

Yes question.
Mike: I've got a question in here are we going to talk about code splitting with web pack.
Kent C Dodds: Yes yes we definitely will and true shaking and all the fun buzzworder things things that people want to hear about these days. That are buzz worthy for a reason, because they're cool.

Okay, sorry, just arranging things. So yeah, you should be looking at something like this, except you probably won't have to do's already in there. So yeah, basically the functionality of the app is fairly simple. You can say hello to people, say goodbye to people, smile, frown. Okay, so then I'm going to frown.

Okay, done that and I'm going to say hello, hello. Okay, and so then I can go to active and I see the things that I have yet to do, completed. And you'll see that the URL is updating. As I navigate to these different things. There actually is a bug that I've discovered, but it's hard to reproduce.

So if you can find the bug and submit a patch, that'd be awesome. And then we can also clear completed. There's the bug, well, no, that's not the bug. There we go. So, yeah, I need to give credit where credit is due. Because I did not build this app, I do not have these design skills.

And so this is the TodoMVC Project. Basically the whole idea of the project is, let's take all the TodoMVC* frameworks, and make, build the same app in them, so you can kind of compare approaches. There has been a little bit of criticism of this approach, because it's a pretty simple app.

Things change considerably when you get to like enormous apps, but I think it's a pretty good way to tell whether you like the approach to things from certain frameworks. So this is a fork from a couple like about a year ago actually that I changed a little bit for our purposes.

So that is the to do MVC app that we'll be using. Let's take a look at the code after this question.
Mike: There was a question on are there any of the features except tree shaking that are webpack 2 only?
Kent C Dodds: Great question Martin. So there are several features and I will try to call them out that are webpack 2 only.

Like that and actually I'm pretty sure at the end of the slides I have a link to it just that explain all the differences. There aren't a ton there are a couple API differences and there are yeah just a couple features that web pack 2 that web pack 1 does not, the way that it does code splitting is different, so good question.

Yeah, and we will see those today, Martin, cool. Any other questions before I jump into code? Sweet, so the code, we'll start with our package JSON actually. So we have a couple, one dependency here. We are depending on the app-css because todomvc is more focused on the JavaScript portion of things and so they have a common CSS module that we're using.

And then we have some devDependencies eslint, my own config, which is great and you should use it because no just kidding you can do your own style and stuff. In fact the linting stuff should only be linting for best practices in areas not stylistic things. So you can feel free to use semi-colons you're welcome.

And then yeah just a couple other dependencies ghooks you probably don't really need to worry about it was mostly for my benefit while making the workshop. And then our scripts we're going to become really good friends with scripts today. We have a validate script that hopefully if you run an npm run validate it doesn't produce any errors if it does I am sorry.

Cross-platform problems are hard especially when you don't have a Windows machine. Linting luckily isn't really super important for us right now, or for this workshop, so if somebody wants to submit a patch to fix that problem that'd be great, but we don't actually need it desperately. The start is just going to start up our HTTP server.

So we'll be adding a bunch of scripts to the scripts here. So let's take a look at our index HTML. We have it's actually pretty small, 52 lines of HTML and we have just our the most interesting bit are the scripts here at the bottom. So we have Bootstrap which is loaded last because everything else has to be loaded first because we care about that in this current world of scripts.

We also have our link tag here that has an h ref to that shared CSS. And Henry is asking what is the use of Ghooks. Go check out the N.P.N. page for it's great. I like it a lot and I contribute to it but it's not really important to that workshop so.

Mike: There is one question about that too.
Kent C Dodds: Yeah any thoughts on the effects of HTTP2 on module bundlers I'm under the impression that bundling generally is aimed at getting around issues with HTTP 1. I'll go ahead and pause this and answer that question Mike, that is a common question and lots of people think that HTTP2 is the savior of the app builders of the web.

And in many cases, it is, It helps. So the specific feature that Mike is talking about is called I think it's multiplexing but basically the idea is part of the problems with HTTP1 is every single thing that you go to get from the server you have to have your own TCP handshake and you do a whole bunch of stuff to go get that resource.

And it's and so that's part of the reason why having a lot of script tags is a problem because the browser can only do like six of those at a time and it takes some time to load all those and then you can and then you parse a JavaScript and then you run it and so.

So yeah HTTP2 is cool because it can open up a connection and then just get all the stuff. So it's much faster and so it's going to be great whether you bundle or not, but the nice thing is that actually bundling might not be optimal in that kind of scenario or that's what people think.

What I would say is benchmark it for your app. But it's actually quite likely that you will still want to bundle, because what you get from bundling, or a big piece of what you get from bundling, is all of your JavaScript is in one file and then you can g-zip that file.

So that means is that you compress it. And so like the file size is much smaller. But if you have like a hundred or if you're using NPM and you have dependencies and NPM we love dependencies. You'll have hundreds of separate JavaScript files. Even with HTTP2 and all of it's magic and glory.

Will probably not be faster at loading that than it would be at loading one or two or maybe even ten G zipped files. And so you could say, well, okay well just G zip everything. Well G zip doesn't do much good if it's a small file and it needs to have, like there's a threshold of how much content is in that file before G zip actually starts providing benefits.

And so it's not just so clear cut and dry of whether or not HTTP2 is going to solve all of our problems. I feel like I'll be bundling probably forever even take electronics apps for example. So an electron app is a native feeling app, just built with web technologies.

I'm using an electron app right now, this whole thing is built with JavaScript. Look at that, what?
Kent C Dodds: Yeah, so cool. And so one cool thing about electron apps is you don't have to worry about bundling, because all the files are right there. But bundling in that scenario is useful for shrinking down what you're actually sending to people to download because if you don't do that then you're going to have all the node modules in there that you're sending with it.

And I have to be honest one time I published a nine megabyte gif in my node module, so sorry everyone who is using that. I fix that later but yeah so you'll have, sometimes people will publish test and they'll publish documentation and so by bundling you can just say okay just get the stuff that actually required and then even tree shake that.

And now it's much smaller and when people download my desktop app even that's much smaller less stuff to parse through, ends up being faster. So we'll be bundling for a very long time until there's like something even more game changing than HTTP2. I'm glad you brought that up, Mike, because that's an important point.

Any other questions? Okay, sweet. So just really quickly continuing through this. We're going to get to code here before too long. I'm going to actually delete this, sorry. So we have our bootstrap, that's like our main method if you think about it in non-JavaScript terms. Pretty much all other programming languages have a main method, so this is pretty much it.

We have our immediately invoked function expression. And then we're calling a couple global functions that we have defined here on some global app object. And that is set somehow, somewhere, and that's part of the problem that we're trying to solve with web pack, is we want this dependency of app and this dependency of dollar on to be more explicit.

So quick question though, quiz. Who knows why we are doing an right here in immediately invoked function expression? Anybody have any idea? Yes.
Speaker 4: We actually wanted to execute in real time as it's called.
Kent C Dodds: Yeah, but why would I need to do that because if I just did this right here.

Wouldn't that like do effectively the same thing? So the reason that we do this is because back in olden times when we didn't have awesome things like Webpack. What you could do is you could leak variables onto the global scope and so what we're effectively doing here is we say okay functions in JavaScript are where variables are scoped to.

And so we're providing a closure to scope all the variables that we would create in here so we say it like var foo = bar. And so we don't want to leak those on Windows. Use strict actually solves lots of lots of these problems for us. But yeah so are kind of a really common thing and we'll be getting rid of that.

We're also getting rid of use strict through the course of this workshop.

Ready to take your code to the next level?

Intense courses with world-class teachers and unlimited access to our growing library of videos for the great price of $39 per month.

Get Unlimited Access Now