Snowpack has been promoting an unbundled web development approach that removes the need for traditional JavaScript bundlers like Webpack and Parcel. Today, almost all of the major browsers have support for ESM unlike the past when we relied heavily on bundlers like Webpack. Even though things today have changed to an extent, a large portion of the developer community has not moved from the plain and old JavaScript bundlers.
Snowpack’s way of doing things has been quite productive and blazing fast. Snowpack only rebuilds the files where the changes have occurred, unlike the traditional builders where whole parts of an application are rebuilt and re-bundled. The bundling time for larger frontend projects with thousands of components used to take up to 30 seconds but with Snowpack, this time has reduced to below 50 ms. This January, Snowpack version 3 launched which takes things to the next level.
The experimental features of the previous build are now official and ready to be used in the production. In this blog, you will see the new features in action. So let’s get started!
First, we will have to set up a project in a new directory. Open up your favorite command line tool to make a new directory and enter the following npm commands to install the new Snowpack v3:
$ npm init $ npm install --save-dev snowpack@^3.0.0
npm init
will create our package.json
file where we will be adding scripts for running Snowpack. Open your package.json file and enter the following scripts in it:
"scripts": { "start": "snowpack dev", "init": "snowpack init" }
With the snowpack init
, we will get our snowpack.config
file created. As Snowpack requires an index.html
as an entry point, we create the index.html
file in the same directory and then run the command below:
$ npm run start
You should see this screen in your browser:
After we have the new Snowpack v3 installed and running, let’s dig deeper into the new changes it brings.
This is one of the biggest and the most important changes of this version. Streaming imports is here to revolutionize the frontend development practices. This feature leverages the power of modern JavaScript with the ES modules. By default, Snowpack pulls the locally installed npm packages and caches them, so we will no longer need a bundler.
But in this version, things have gone futuristic, there will be no need for installing the npm packages for the frontend development! Now, you only have to import any package the standard ESM way and Snowpack will do the rest.
Previously, you had to import the package from the CDN URL. But now, when you import a specific JavaScript package, Snowpack fetches the ready-to-run package from its ESM package CDN in the background. The package gets cached locally which enables the support for offline development. The following example will make things a lot clearer.
Suppose you have to use React in your project without npm, you probably write something like this:
import * as React from 'https://cdn.skypack.dev/[email protected]';
This approach is not ideal but Snowpack solves this issue.
Just use the standard ESM import for React and Snowpack which will fetch the package and cache it for offline use:
import React from react;
The above statement will look something like this:
import "https://pkg.snowpack.dev/react"
To use this feature, we have to first enable it by making some changes in our snowpack.config
file:
packageOptions: { source: "remote", },
Setting packageOptions.source
to remote will enable the streaming imports for our project. Now let’s try importing React without npm. Create a new index.js
file and import React like this:
import React from "react";
As Snowpack looks for the referenced files in the index.html
, we add the following line of code in our index.html
:
<script type="module" src="/index.js"></script>
Now rebuild the Snowpack project and check the output in the console. If all went well, you will get the following output:
Below is the screenshot of our browser sources and the project file structure where we can see React in the browser and in the local cache:
ESbuild
ESbuild
is Snowpack’s default bundler for JavaScript, TypeScript, and JSX files but in this release, the team has taken things one step ahead. With this new update, the time taken for bundling, minifying, and transpiling the site for production is faster due to the new built-in build production pipeline. ESbuild
is written in Golang which makes it extremely fast compared to the bundlers written in JavaScript. But being a newer feature, it is better to use it in smaller and noncritical projects. In order to enable it, enter the following lines in snowpack.config.js
:
optimize: { bundle: true, minify: true, target: "es2018", },
Before Snowpack version v3, interaction with the dev server and the build pipeline was possible through the command line having different commands and flags. But now, the team behind Snowpack has given you an API that can be used for more advanced control over the build pipeline and the Snowpack dev server. With this API, the possibilities are endless and it has already resulted in the production of a fantastic server-side rendering solution named SvelteKit. Let us create a simple Snowpack server from the new JavaScript API.
First of all, we have to create a new file named server.js
where our server will live. The whole logic of your server must be inside server.js
. After the file is created, we start to import different functions from our Snowpack API. Complete details regarding the API are on the main website:
const { startServer, createConfiguration } = require("snowpack");
The startServer
function takes a configuration object that is similar to the snowpack.config.js
file we created before. The function createConfiguration
is to create the required object for the server. If you need to load a snowpack.config.js
file, the API has a separate loadConfiguration
function as well which works similarly:
const con = { packageOptions: { source: "remote", polyfillNode: true, }, buildOptions: { htmlFragments: true, }, }; const config = createConfiguration(con); const server = async () => { await startServer({ config }); }; server();
Change the scripts in the package.json like this:
"scripts": { "start": "node server.js" },
Now run the following command:
npm run start
If everything went well, you will have the Snowpack server running. Make sure you have the index.html
file as the server will look for it in the same directory.
This feature was made possible due to the collaboration of the Snowpack and the Svelte team. A new server-side runtime in version v3 powers the SvelteKit which allows the developers to import any Snowpack-built file directly into Node.js. With this feature, the teams were successful to create a unified build stream across the frontend and the backend. Owing to this working scheme of things, the true server-side rendering has been unlocked which is currently being used in the SvelteKit. The runtime also makes the test integrations for testing frameworks like Jest, Mocha, etc. Server-side rendering with Snowpack is a little complex and this is why it is recommended to use libraries like SvelteKit.
With projects like Snowpack, we can see where the future of web development is going. The approach followed by Snowpack is modern and similar approaches are being seen in other projects as well, for example, Deno. The current struggle is to get out of the npm packages hellhole and Snowpack has done a great job for frontend developers. With time, things will surely be improving with the new features. Until then, make sure you get the most out of this new release from the Snowpack team.
Install LogRocket via npm or script tag. LogRocket.init()
must be called client-side, not
server-side
$ npm i --save logrocket // Code: import LogRocket from 'logrocket'; LogRocket.init('app/id');
// Add to your HTML: <script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script> <script>window.LogRocket && window.LogRocket.init('app/id');</script>
Would you be interested in joining LogRocket's developer community?
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 nowCompare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.