Snowpack Discovery Video Tutorial

In this video I invite you to discover Snowpack. A tool that aims to be an alternative to bundlers for working on JavaScript projects.

tldnr : The idea is interesting but certain points of friction make me prefer it quickly now.

The problem

Today, when working on a front-end project, we use a bundler during the development and production phase. However, the approach used by bundlers turns out to be inefficient for development because it has to rebuild a large file with each modification (which can take quite a long time on large projects).

The snowpack approach

Browsers today support EcmaScript modules, which makes it possible to envisage a future without bundling, but several problems must however be resolved:

• We want to be able to install modules that come from npm.
• Some frameworks require the use of an alternative language (vue, jsx, svelte ...).
• We sometimes import code that is not JavaScript (.scss, .svg ...).

This is where snowpack comes in by offering a solution for these different problems to offer a better development experience.

How it works ?

First, let's talk about the npm case. When you go to install a dependency which comes from npm, snowpack will install an ES version of the package which can then be used by the browser directly (This is also the same approach as that used by skypack).

Then when you import a file that doesn't use JavaScript, snowpack will do a transformation to convert it to something that can be used by the browser.

for example

import Demo from './Demo.jsx'
import './style.scss'

will become

import Demo from './Demo.js'
import './style.scss.proxy.js'

During the development phase snowpack will also add additional scripts to set up the HMR so you can see your changes live.

The snowpack configuration is done through a file snowpack.config.js to which we can add plugins to manage different types of files.

// snowpack.config.json
"plugins": ("@ snowpack / plugin-typescript")

And the build?

When you are going to build your project, snowpack will not generate a "bundled" version of your sources but will generate the various JavaScripts modules which can be used by browsers.

Limitations

Even if the "no bundle" approach is interesting, it is not yet viable in production because it creates a cascade problem:

• The browser loads the index.js file, parses it and identifies dependencies
• The dependencies are in turn loaded, parsed, and the dependencies are identified and loaded.
• so on until the entire dependency tree is loaded.

In the development phase, these comings and goings are not necessarily annoying, but this becomes problematic in production with network latency. So it is still interesting today to bundle the files to generate only one output file. We will then find ourselves having to configure a bundler after switching to snowpack, which is not necessarily very practical (especially for loading CSS for example).

Then the second problem that we encounter is the use of npm modules which cannot be used for in-depth inclusions. For example it is not possible to have an import that looks like this.

import Demo from 'module-lol / src / demo'

Because during the installation of this snowpack module will create an ES6 version of the module and that is all that will be exposed to your application.

To conclude

The snowpack approach is interesting but the ecosystem is not necessarily fully adapted to this approach. The development of ES6 modules within the npm ecosystem should improve things in the future. In the meantime, we will have to continue to undergo bundling or look for alternatives as soon as possible.