Webpack can get slow when you’re rebuilding a large app. Enter Snowpack. Find out how Snowpack serves your app unbundled during dev, and why this matters.

In this article, we’ll take a first look at Snowpack — specifically Snowpack 3, which at the time of writing has just been released. Snowpack is a front-end build tool that’s been getting a lot of attention in the community for offering a different approach from tools like webpack, and I’ve been keen to check it out for a while. Let’s dive in!

A History of Build Tools

Before we look into Snowpack, we need to take a quick moment to understand how and why bundlers like webpack came to be. JavaScript’s lack of a module system prior to ES2015’s modules meant that, in the browser, the closest we could get to modules was to split our code up into files that put code into the global scope, as this was how we shared it between files. It was common to see code like this:

window.APP = {}

window.APP.Authentication = {...}
window.APP.ApiLoader = {...}

When Node.js arrived and gained popularity, it had a module system in the form of CommonJS:

const Authentication = require('./Authentication.js')
const APILoader = require('./APILoader.js')

Once this became popular as part of Node, people wanted to be able to use it in the browser. That’s when tools started emerging that did this; they could take an application that used CommonJS modules, and bundle it into one large JavaScript file, with all the requires removed, that could be executed in the browser. Browserify was the first such tool that I can remember using to do this, and, to be honest, it felt like magic! This was around the time that webpack came to be, and other tools also supported using CommonJS.

When ES Modules were first introduced (see “Understanding ES6 Modules” for a refresher), people were keen to use them, but there were two problems:

1. Whilst the spec was done, browsers didn’t support ES Modules.
2. Even if a browser did support ES Modules, you probably still wanted to bundle in production, because it takes time to load in all the modules if they’re defined as separate files.

Webpack (and others) updated to support ES Modules, but they would always bundle your code into one file, both for developing and for production. This meant that a typical workflow is:

1. Edit a file in your application.
2. Webpack looks at which file changed, and rebundles your application.
3. You can refresh the browser and see your change. Often, this is done for you by a webpack plugin such as hot module reloading.

The problem here lies in step two as your application grows in size. The work for webpack to spot a file change and then figure out which parts of your application to rebundle into the main bundle can take time, and on large applications that can cause a serious slowdown. That’s where Snowpack comes in …

#snowpack #webpack #javascript #web-development