Written by on 12 October 2015

The evolution of JavaScript build tools

We have gotten used to having Gulp around these days for building frontend code and assets. There is a reasonable chance that you even switched from Grunt to Gulp not even that long ago. But just as you got used to writing your build scripts in code, Webpack introduces a new look at the matter, by replacing code with configuration and general assumptions. You are probably wondering how that can be a good thing and what the advantages are.

When first starting with a JavaScript app, you will find that you need something to manage dependencies. Node.js adds the require syntax, but unfortunately that is not natively supported by browsers. A module like Browserify adds this support to your Gulp build chain and you can start requiring your dependencies. The way this works is you let Browserify build a bundle, which is no more than a single JavaScript file, from you application and dependencies. It will make sure it is done in the right order and as efficiently as possible based on your require statements.

This works fine as soon as you find out how to script this all together in Gulp. But the more tasks you add to it, like minifying, babelifying, the more complex and time consuming this becomes. You have to script everything into the bundle build process. And then you probably also want different build scripts for development, test, distribution, etc.

Webpack simply assumes that with a JavaScript application, building and bundling is a standard procedure. And instead of scripting this build process yourself, you only configure it. So even if it takes away some flexibility in use cases, when it comes to specifically building JavaScript apps (or just JavaScript in general), Webpack will take a lot of work out of your hands. That is probably why these days on a lot of JavaScript projects on Github, you will see this webpack.config.js file.

It also assumes that you use require for every type of file. You can require css/sass, images and even html files. Webpack will build and bundle your application from there based on module loaders. If it sees a scss file required for example, it will load the sass-loader and add the generated css to a css bundle, or as configured. These module loaders, combined with the plugin architecture, will still give you all the flexibility you need.

Because of this generalised approach, Webpack also has some added advantages. For example a code watcher and a webpack devserver with auto reloading are all default functionality. And because this all plays together so well, magical things can happen, as Dan Abramov showed in his talk about React hot reloading during React Europe.

We are using Webpack currently in our new development stack for editor tools.¬†However we are still using Gulp for asset management in our website. It’s all about picking the right tool for the job.

COMMENTGive your two cents.