Why Webpack?

Learn about Webpack and why you should use it

Credits to cqlcorp.com

The field of Front-End development is changing so rapidly on how we do things these days. Back when life was so simple and before front-end libraries and frameworks started appearing, there used to be just a simple javascript file that you have to include in your html file and you’re good to go.

In CSS we have a couple of libraries and frameworks to use these days. This makes front-end development more and more challenging. The same can be said with JavaScript ecosystem. Not only that we have changing libraries and frameworks to use, but we also have changed the standards these days like ES6 and beyond. Big three frameworks like Angular, React, Vue came into play the past few years.

Then came these so-called “module bundlers” or build tools, namely webpack, browserify, and gulp.

If you’re wondering how did our tooling became more and more complicated that we have to use build tools like webpack, let us go back in the days where web development was so simple that including a simple script is already enough.

Tip

Use Bit to encapsulate components with all their dependencies and setup. Share them on Bit’s cloud, collaborate with your team and use them anywhere.

Components with Bit: Easily share across projects as a team

Bit.dev | Github

What is Webpack?

First, let us define what is Webpack. According to the official site, Webpack is a static module bundler for modern JavaScript applications. It builds a dependency graph that is responsible for bundling all your javascript modules into one regardless where they are located when one javascript file depends on each other.

In short, Webpack is a bundler that is responsible for bundling all your javascript files to make it work.

The time before libraries, frameworks, and build tools like Webpack

Back then life was so much simpler that we just need to include a single script in our HTML such as this then solve problems right away:

<head>

<script src="main.js" type="text/javascript"></script>

</head>

But then, libraries came so we have to include them one by one and in the proper order to make them work interdependently:

<head>

<script src="library1.js" type="text/javascript"></script>

<script src="library2.js" type="text/javascript"></script>

<script src="script.js" type="text/javascript"></script>

</head>

Then the ecosystem added frameworks such as Ember, Backbone, Meteor, React, Vue, Angular and things got complicated from there. Add in some more changing standards of javascript like ES6, ES7 and beyond.

Then lastly came build tools such as browserify, grunt, webpack and we totally got lost in the sea of uncharted waters of Front-End ecosystem:

I have to admit that when I heard and read these stacks to learn in the developer community, I was one of the developers that got intimidated in climbing the Front-End ecosystem until I gave it a break then started giving it a shot again.

How did we get into this mess?

First, let us ask how did we actually get into this mess and what problems do build tools like webpack solve.

These are the problems webpack was trying to solve:

Automation

You might not be a big fan of including every javascript libraries in your HTML headers but prefer to use npm for including such libraries you want to use in your functionality.

Webpack does that for you. You just simply need to install any library of choice you want from npm then webpack can automatically include that library in the bundle for you if you’re making use of them in your modules.

Load Speed

Loading individual scripts within a webpage is very costly if we were to create a modern web app.

Webpack helps us improve the loading speed by bundling every javascript modules we have into one since we only ask once in fetching our script from the webserver. It makes sense since when we just fetch our javascript files one by one, we’re putting stress on webserver by fetching those files a couple of times in contrast to one big file being requested from webserver.

This might be true prior to the advent of HTTP/2, but things might have changed since then.

Only load necessary scripts when needed

Under normal circumstances, your app will load every javascript modules and libraries you had regardless if you need these functionalities or not. But what if at some point you don’t need some of the libraries in that particular functionality or module the user is using as of the moment?

Take a look at this graph in our developer console:

The red on the graph indicates the percentage of scripts unused in your app, while the green ones indicate it is being used. When you think about it, we have more unused scripts that are unnecessarily loaded during loading time.

With this, webpack provides a feature called “code splitting” to solve this problem. What this does is that you have a choice to load individual scripts “on-demand” or “asynchronously” only when the app needed it. This gives us the performance edge we need to load the app at blazing speeds.

Because of this feature, we don’t need to load any unnecessary scripts that only hampers the performance when the user is not using some particular modules or functions.

For more information about code splitting, visit webpack’s official documentation for it:

Dependency Issues

Another reason why webpack is so popular because it solves the common problem in building javascript apps: Dependency issues.

As mentioned earlier, before the dawn of webpack, we used to arrange our scripts and libraries in the proper order to connect the dependencies correctly:

<script src="moment.min.js"></script>

<script src="typeahead.min.js"></script>

<script src="jquery.min.js"></script>

<script src="otherplugins.min.js"></script>

<script src="main.js"></script>

This is fine. But as your list of libraries you depend on gets broader, you will encounter some dependency issues because you haven’t imported the script in proper order. I encounter this issue a lot when my list of libraries I depend to gets broader and broader.

But as I used webpack, this solves all the dependency issues I previously had because you will know ahead of time which dependencies were missing during the build time through the use of ECMAScript Modules (ESM) like so:

//helper.js

export const sqrt = Math.sqrt;

export function square(x) {

return x * x;

}

export function diag(x, y) {

return sqrt(square(x) + square(y));

}



//main.js

import { square, diag } from 'helper'; console.log(square(11)); // 121

console.log(diag(4, 3)); // 5

These import/export modules will automatically be detected by webpack and will serve as an indicator which javascript modules will it include during the bundle. This effectively takes away the pain of arranging your libraries in proper order just to make everything work.