Snowpack is a build tool for web applications that can be used without bundling in development. This is entirely thanks to the power of native browser ES modules, which allow the tool to remove bundling steps in the development environment. As a result, Snowpack helps make the development environment build faster and remains fast even as your codebase grows.
Snowpack also introduced the concept of unbundling your application in development, which helps you avoid the need to rebuild and rebundle entire chunks of your application every time you save a single file. It just does an instant update of the changed file via Hot Module Replacement.
The official website describes Snowpack as “a modern, lightweight toolchain for web application development.”
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
When version 1.0 was released to the public in January, it came with exciting features such as:
The Snowpack team released version 2.0 on May 26 with a number of exciting new features, including:
The official website describes snowpack 2.0 as “a build system designed for this new era of web development.” O(1) file building involves the process of only rebuilding or rebundling a file that is changed in development without rebuilding the entire application. In other words, if you make a change to a file in development, only that file would be rebuilt without affecting other files.
This is different from other build tools such as webpack, which is an O(n) build tool. They are called O(n) build tools because traditional bundling has a complexity of O(n). When a file is changed in traditional bundling, the build tool will rebuild the entire chunks in the application because of just a single file.
Snowpack 2.0 was shipped with support for O(1) file building, which allows it to make updates at lightning-fast speed because when a file is changed in development, only that file is rebuilt.
O(1) file building includes many benefits of traditional O(n) bundling, including:
The development server is now faster than ever because of the O(1) file building. When you run snowpack dev, you’ll notice how fast the startup has become. It starts up in <50ms because no bundling work is carried out.
Snowpack only builds files that are essential for a particular page, no matter the number of files contained in your project. This is possible because of dynamic imports, which will load a module only when it’s needed.
Snowpack uses Hot Module Replacement to carry out instant updates in the browser, which is a very cool feature.
In version 2, Snowpack was shipped with automatic support for the following out of the box:
The Snowpack team attached a hot() function to the general ESM-native import.meta HMR API.
Snowpack 2.0 improved the use of build scripts to connect your favorite build tool to Snowpack. It looks and feels like how you’d configure scripts in a package.json file.
With build scripts, you can take total control of the entire build process. You can either tweak it to suit your needs or build your own build process. Snowpack offers third-party JavaScript plugins and enables you to build your own project-specific plugins without any hassle.
Build scripts are usually saved as snowpack.config.json. This build script will run every run *.js,*.jsx,*.mjs,*.cjs files through the Babel plugin we specified above. It will also run every *.css file through the PostCSS CLI.
{
"scripts": {
// Run every "*.css" file through the PostCSS CLI
"build:css": "postcss",
//Run every "*.js,*.jsx,*.mjs,*.cjs" file through the babel plugin
"build:js,jsx,mjs,cjs": "@snowpack/plugin-babel",
},
"plugins": [
"@snowpack/plugin-babel",
],
}
One of the coolest features in Snowpack 2.0 is zero-config prototyping, which enables you to use the tool without the need to configure basic things. In other words, you won’t need a snowpack.config.json file until you really need it.
🧵 Snowpack v2 Preview: Zero-Config Prototyping
One of my favorite things that we got right in Snowpack v2 was its default behavior as a zero-config, fast-prototyping dev server.
Here’s some screenshots of Snowpack running in a static, config-free directory: pic.twitter.com/bB55JWq5fh
— fks (@FredKSchott) May 18, 2020
By default, Snowpack comes with out-of-the-box configuration for:
If you need to do extra processes, you can create a script or add a plugin to help you with it.
Snowpack 2.0 comes with new and improved starter templates to suit your needs. A CSA is a starter template that consists of a preconfigured, Snowpack-powered development environment. It’s similar to the popular Create React App, only powered by Snowpack instead of webpack.
CSA templates are available for some popular JavaScript frameworks and static site generators, including:
You can also create your own Create Snowpack App template and share it with the community.
Snowpack 2.0 comes with myriad new features and improvements to existing features that help streamline and simplify the build process.
To learn more, check out the official Snowpack 2.0 release post.
What’s your favorite new feature in Snowpack 2.0? Let us know in the comments section.
There’s no doubt that frontends are getting more complex. As you add new JavaScript libraries and other dependencies to your app, you’ll need more visibility to ensure your users don’t run into unknown issues.
LogRocket is a frontend application monitoring solution that lets you replay JavaScript errors as if they happened in your own browser so you can react to bugs more effectively.
LogRocket works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app’s performance, reporting metrics like client CPU load, client memory usage, and more.
Build confidently — start monitoring for free.
A CTO outlines his case for how leaders should prioritize complex thinking over framework knowledge when hiring engineers for the AI era.
Build dynamic, AI-generated UI safely with Vercel’s JSON Render using structured JSON, validated components, and React.
Learn practical techniques to reduce token usage in LLM applications and build more cost-efficient, scalable AI systems.
Build dynamic forms using a JSON schema-driven approach that keeps frontend and backend validation in sync.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn more →
