What is webpack

Sergej Koschkin

Some probably remember the ancient dark times of web development. You remember the horrors of managing your JavaScript dependencies by downloading some .zip file, put the needed .js files in a /scripts directory somewhere and including those files with a <script> tag in a specific order in you document. The same went for CSS and static assets. For maintainability and page loading time this was a nightmare.


After a while task runners like Grunt and Gulp appeared and the nightmare was over. With these tools developers could concatenate and minify their code into a single big file. This reduced the overall size of the content and the number of HTTP requests needed.

In addition plugins turned Grunt/Gulp into powerful development tools, capable of automating bacically every task, like linting, unit testing and LiveReload.

But bundling all your assets into a few files has a downside to it. Bundling all your assets into one or even several files and including them to every part of your application means loading a ton of assets that aren’t required most of the time. The alternative would be to go back to aforementioned old way of maintaining the included files and dependencies manually.

Luckily at this point module bundlers are used to splice various assets and produce bundles to implement a structure into these giant piles of unreadable code. There are quite a few out there like Webpack, Browserify or jspm.io which have their respective strengths and weaknesses. But comparing all of them is out of scope for this article.

Instead I want to talk about the – in my opinion – two main strengths and coolest features of Webpack. Code splitting and Hot Module Replacement.

What does Webpack actually do?

Webpack lets you use require() not only on JavaScript modules but also local static assets, meaning non-code files.

Through different loaders and plugins Webpack can be configured to work with any sort of file. Need LESS support in your project? Configure the appropriate loader and you get it.

module: {
    loaders: [
        test: /\.jsx?$/,
        exclude: /(node_modules|bower_components)/,
        loader: 'babel',
        query: {
          presets: ['es2015']
      }, {
        test: /\.js$/,
        loaders: [
          'react-hot', 'babel'
        include: path.join(__dirname, 'src')
      }, {
        test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
        loader: 'file'
      }, {
        test: /\.less$/,
        loader: 'style!css!less'
      }, {
        test: /\.(png|jpg)$/,
        loader: 'file'
      }, {
        test: /\.css$/, loader: 'style!css'

Webpack starts from an entry point and then traverses through your code looking for require and import statements, building a dependency tree for all your files.

import React from 'react';
import {connect} from 'react-redux';
var imgLeft = require('./img/left.jpg');
var imgBottom = require('./img/bottom.jpg');
var imgFront = require('./img/front.jpg');

Code Splitting

Code Splitting lets you define split points in your code base where the code is split into self-contained chunks which can be served on demand. Webpack will take care of the required dependencies, output files and runtime stuff.

In short, Webpack will only download the needed code for each individual part of your application if the need arises. Common modules don´t need to be re-downloaded. This is a huge step forward to more efficiency.

Hot Module Replacement

If you used Grunt, Gulp or any other task runner before you should be familiar with setting up a watch task to listen for changes in your files and then telling the browser to reload itself on changes.

The Hot Module Replacement feature of Webpack takes things a step further. It also watches your files for changes but instead of refreshing the browser to apply changes it swaps out only the changed modules and updates your code in-place.

What is the advantage in this method? Well, if you require your UI to be in a certain state during the development – like filling out a form, which can take quite a while – you will not lose your state and have to waste time putting everything back together to how it was.

The application state also stays the same. All your global variables, that need to be set a certain way. They stay right like they were before. A little spoon of sugar, that sweetens up the day for every developer working with Webpack.


Is Webpack the next holy grail of web development? Hmm … maybe?!

Should you take a look at it? Definitely.

Just like almost all of the other tools available to developers it gets the job done while offering some nice features. And if you are using Grunt or Gulp already you can easily integrate it into your existing setup to complement it.