Article originally posted on InfoQ. Visit InfoQ

The pika team released the second major iteration of Snowpack. Snowpack 2.0 self-describes as a build system for the modern web and claims start-up times below 50ms even in large projects. Snowpack 2.0 achieves its speed by eschewing bundles during development. Bundles may still be generated for production. Snowpack 2.0 ships with a set of Create Snowpack App (CSA) starter templates targeting miscellaneous stacks.

Snowpack’s release note explains the value added by the second iteration of Snowpack:

Snowpack 1.0 was designed for a simple mission: install npm packages to run directly in the browser [without] requiring the use of a bundler during development. […] Thousands of developers started using Snowpack to install their dependencies and build websites with less tooling.

Snowpack 2.0 is a build system designed for this new era of web development. Snowpack removes the bundler from your dev environment, leveraging native ES Module (ESM) syntax in the browser to serve built files directly. This isn’t just a faster tool, it’s a new approach to web build systems.

The release note proceeds to illustrate how Snowpack achieves constant build time (characteristic summarized as O(1) build time) by removing the bundling stage in development:

(Source: Release note)

The previous illustration shows that bundling is often a time-consuming task. This is so because bundling has O(n) complexity, i.e. the time to produce a bundle of entities is proportional to the number of entities being bundled. As bundling became more common in development in the last few years, bundlers have been performing an ever-larger list of tasks, including code-splitting, tree-shaking, and more. According to the release note, in some cases, bundling may be much slower (growing quadratically instead of linearly with the number of bundles entities), as the bundler may require a second pass over the entities.

Snowpack explains how it starts fast and remains fast in development:

Every file goes through a linear input -> build -> output build pipeline and then out to the browser (or the final build directory, if you’re building for production). Multi-file bundling becomes a single-file build step.
[…]
With no bundling work needed to start, your server spins up immediately. On your very first page load, Snowpack builds your first requested files and then caches them for future use. Even if your project contains a million different files, Snowpack will only every build files needed to load the current page. This is how Snowpack stays fast.

Snowpack includes a development server which offers TypeScript and JSX support, Hot Module Replacement (caveats apply), CSS modules, custom routing, proxy requests, and more. Non-js files (such as Svelte files) can be supported via plugins. Running snowpack build will generate a static production build which will be a working copy of the same development code. For optimized production builds, Snowpack 2.0 has official plugins for integration with other bundlers such as Webpack and Parcel.

While one user questioned the no-bundling differentiating aspect of Snowpack (What means “no-bundling” really?) and failed to see the difference between Webpack and Snowpack besides the first-class support for ESM modules, the initial reactions on Twitter seem to be positive. The user chadhietela said:

Increasingly I believe the idea of O(1) builds is correct for development. Evergreen browser support + native imports demand a change in tools.

The full release note contains many more technicals details on Snowpack 2.0. The documentation site provides an overview of Snowpack behavior, concepts, configuration, tooling, plugins, and common recipes.

Snowpack is an open-source project with an MIT license. Contributions are welcome and should follow the contributing guidelines. Feedback can be given through the project’s GitHub repository.