Traditionally, in order to build a web app, we would need to use a tool such as Webpack to bundle our dependencies AND source code into a single JS file that our browser can understand. But now, leveraging the power of ESM (ECMAScript modules) support in the browser, we can use a tool like Snowpack to build our files INDIVIDUALLY. This leads to a better developer experience for a number of reasons. But first…
What’s the purpose of a module bundler anyway? Why do I need one?
Simply put, you likely need a module bundler because your code is reliant on external packages (i.e. node modules) and uses file types that must be compiled down to html, css, and javascript. No modern day web app is without the use of modules, because they abstract out common functionalities that are repeatedly used (software reuse ftw). Perhaps you’d like to use a frontend framework like React to replace the html, a css preprocessor like Sass to replace css, or TypeScript to replace javascript. To do this, we would need a build tool to serve our code to the browser in a palatable format.
Snowpack vs Webpack: What’s the difference?
“Build once, cache forever”
The main difference between Snowpack and Webpack (and all other module bundlers) is that Snowpack will only bundle you dependencies ONCE, and WILL NOT bundle your source code. The traditional approach to module bundling was to bundle EVERYTHING into a single JS file that must be continually rebuilt anytime there’s a change to the source code. Because Snowpack leverages ESM, your files are shipped to the browser individually (connected via the import / export syntax). This enables individual files to be rebuilt during development, instead of the entire project.
What are the benefits of using Snowpack?
Save Time/Better Scalability
Every time you make a change to your source code with Webpack, the entire project must be rebuilt to account for your recent change. This could be a few or several seconds. That may not seem like a big deal, but those seconds can really add up, especially if your app gets much larger and compilation times increase. With Snowpack, the changes are reflected nearly instantly because the files are shipped in an unbundled way.
Natively Supported Files/Less Configuration
Snowpack supports many different file types out of the box, including JSX and TypeScript (see all types here). For supported types there’s no need to install additional dependencies and refactor unwieldy configs. For contrast, if you plan on using .jsx files with Webpack, you’re gonna need: webpack, webpack-cli, webpack-dev-server, @bable/core, babel-loader, and babel-preset-react-app… Not to mention a bloated configuration file to account for all the other unsupported file types. To use .jsx with Snowpack, you need only install snowpack with no configuration file. For unsupported file types you would need a config that includes the corresponding plugin.
// Example: snowpack.config.js
module.exports = {
plugins: [
/* ... */
],
};Less Differences Between DEV and PROD
When your application is ready for production and you run the snowpack build command, it uses the same exact unbundled approach as when you ran snowpack dev so it’s guaranteed to be the same app as what you saw in development.
“You should be able to use a bundler because you want to, and not because you need to”
While not required, you can still use Snowpack to bundle and optimize your code for production. You can even use Webpack with Snowpack using the @snowpack/plugin-webpack. The way Snowpack views bundling is more from a code optimization perspective (intended for production). Differences between dev and prod could arise from this, but the code itself that was built prior to being bundled is exactly the same.
