Webpack: introduction without any code.

There have existed build tools for JavaScript as long as I have been coding with it. I can without doubt say that they are better and easier to understand today than they have ever been. But there are also much more you “need” to know before you get started.

The problem tools like Webpack, Browserify and Grunt try to solve is that on one side you got how developers want to have their code organised to make it as easy as possible to have control over this ungodly mess we have chosen to do, and how a browser prefer to consume it. While you probably prefer to have your code neatly organised in different folders with as small, but not too small, files that only have methods that do “one” thing. This is not how your browser prefer to consume it. And a browser is not the only way to use JavaScript these days.

A browser prefer a few larger files over many small files. What I mean by “prefer” is that it is faster if you do it this way. There is of course a limit to how large those files should be, webpack starts to warn you if you pass a few hundred KB. If you have too many small files, then your browser spend more time opening connections to your web server than it does on downloading them, but if they are too big your bandwidth are not used efficiently enough; if the total is a megabyte, then it would probably be faster to download it as 10 100kb files, instead of one 1014kb files or 1024 1kb files.

There are also many other benefits. You can do all your css processing in the same build procedure, for example compiling from LESS or SASS to css. But the biggest advantage is to use it with Babel to enable the use of JavaScript language features that aren’t available in all browser yet, or css features that are behind prefixes and let babel and css plugins convert everything to something that is safe for what ever browser requirement you define.

You can also use webpack to solve one of the most annoying problems with web development, after the browsers started to become very aggressive in caching resources. That is: you updated index.js, but you can’t see the changes it your browser. Or you have updated the server, but you need to get a customer to clear their caches. That’s not going to happen, right?

So. What you can do with webpack is to get it to generate an HTML, either an empty one or one based on something you define that links all the javascript resources for you, and get it to give the JavaScript files a unique name; so instead of bundle.js you can call them bundle-[sha1].js. And that means that there will be a new file with a new file name every time you update. No more “have you cleared your caches?” e-mails, slack messages or phone calls.

I think every one should use something like webpack for their web development, at least if you move beyond a hundred lines or JavaScript code. There are alternatives to webpack, but I would go for it, because it seems like most of the community have adopted it as the standard.

No code or samples in this one, but I’m probably going to show how I’m doing stuff with webpack in the near future.