Fewer JS files
Historically, the number of JS files used by a website was crucial because of the performance penalty of having many small files. Browsers loaded each file with a separate HTTP request. Every request needed a connection between the browser and server, and those took time to establish. Thanks to HTTP/2, the number of files is much less of an issue now. Still, having files bundled together makes sense. Each request is cached separately, so having plenty of files makes it more challenging to ensure that the browser doesn’t get stale code from the cache.
Besides that, until 2018, many browsers were not supporting ES modules. You were just loading many files from the HTML, and they all shared the same global scope. The JS bundlers address both issues, as they
- allow you to keep your codebase split into many, well-defined files and
- bundle the code into big files for deployment.
Easy import from
Bundlers provide you with a way of importing dependencies, which is much nicer than loading them as ES modules. To use node packages from the browser, you would need to
node_modulesto your production server, and
- use a relative path from your file to the file you want to import
The relative path is a big headache because it forces you to write the import slightly differently depending on how deep in the folder structure you are. So, for using Lodash, you would have:
// in ./src/core.js
var _ = require('../node_modules/lodash/lodash.js');
// in ./src/app/main.js
var _ = require('../../node_modules/lodash/lodash.js');
The bundlers allow you to write simply:
var _ = require('lodash');
Import other file types
const template = require(‘./view.html’);
If you’re writing your code as you should, you are doing the following:
- giving meaningful names to variables
- indenting the code
- leaving comments for other developers
This adds clutter that means nothing for the interpreter. Minification is the first step to reducing the payload size. It removes everything that has no impact on your application.
Downgrade for older browsers
As the language receives new features, there is this period during which
- developers want to use it already, and
- not all browsers support it.
Luckily, this period is becoming significantly shorter thanks to the evergreen browser, but there is still a need for a project like Babel. Babel allows you to use the newest language version while coding and transpile it to a version that the older browser will understand.
Separate build for different use cases
Once you start compiling your code with a bundler, new possibilities arise. From the beginning, you will most likely compile the code one way for production and another way for local development. If you write unit tests, maybe you are interested in knowing how well they cover your code. There are code coverage tools that do exactly this. They require a dedicated build that includes tools that count visits to every line of code during the test execution.
How about you?
What JS bundler are you planning to use in your next project? Let me know in the poll, so I know which should get more attention on this blog:
You can check out my article about using native ES modules, or: