Tag: Snowpack

Migrating from Parcel to Snowpack

I find build tooling endlessly interesting, especially right now as we’re in a juicy next-gen transitional period with players like Vite, wmr, Snowpack, and esbuild. Hugh Haworth has a good run-down of the new players, and we’ve chatted on ShopTalk about them several times. I especially like it when people blog their personal journeys in moving build tools, like Ben Frain has done.

It’s not like buying a new car where the new one is faster, but they both have steering wheels and doors and brake pedals and stuff. They share a similarity in that they are trying to provide DX locally and UX (via performance) on production — otherwise their approach, what they provide, and what they expect are all quite different.

Those differences mean re-training your brain in how you expect things to work. Here’s Ben on Snowpack:

In Snowpack land, your index.html file needs to reference the transformed version of the files – even though they don’t exist on your file system.

Wait, what?

Let me say that again as it’s jolly important. You link to files that don’t exist.

That’s just weird, right?

But Ben was switching from Parcel to Snowpack, and Parcel was weird too. In the Gulp days, we were super explicit about what files we were selecting, running tasks on, and where the transformed code went. In webpack, there are very explicit entry and output destinations, and it’s very focused on JavaScript being the input. But Parcel really wanted an HTML file to be the entry point and it would explore itself from there.

I always thought Parcel would have struck a nerve with the WordPress crowd harder, since you could point it at the template file where you link up your assets in a WordPress template and have it do its thing. I guess WordPress is too funky with all the wp_enqueue_style stuff and it just didn’t work?

Ben gives Snowpack a tentative thumbs up.

If you are starting a greenfield project I’d have zero qualms opting for Snowpack. It doesn’t have the depth of support documentation or stack overflow questions if you find yourself in the weeds, but generally speaking, it is solid enough to pick up and run with.

Me, next time I get a chance to play with build tools, I think my bar is going to be incredible speed. I’ve spent too much time on projects in my life where the developer experience is slow. I want smokin’ fast updates for whatever I’m working on.

Direct Link to ArticlePermalink


The post Migrating from Parcel to Snowpack appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,

Snowpack

Snowpack. Love that name. This is the new thing from the Pika people, who are on to something. It’s a bundler alternative, in a sense. It runs over packages you pull from npm to make sure that they are ES module-compatible (native imports).

This is how I digest it. When you write a line of code like:

import React from "react";

That’s actually invalid JavaScript. It looks like a native import, but it isn’t. (It would start with a filepath character like ./ and end in .js to be valid.) It’s just an agreement from Big Bundler like, “Oh, I know what you mean. You mean I should go look in node_modules for this thing.” Then it goes and does it.

A lot of stuff on npm isn’t ready for ES modules. It’s in some other module format (e.g. CommonJS) and assumes you’ll be using a bundler with it. An assumption served them just fine for a while, but it’s an assumption that is starting to be a bit of a thorn for front-end developers.

UNPKG has had a feature where you could add ?module to the end of their URLs to get it to serve up an ES module-friendly version of the package, but it’s been in an experimental stage for a long time because, presumably, it’s a hard problem to solve. Which packages are ready for ES modules? Can they be processed to be ready on the fly?

Even the Pika CDN doesn’t solve the issues of packages that aren’t written to be used via ES modules. For example, since React isn’t written to be used with ES modules directly, so you just can’t (but you can still use it via <script> tag).

Snowpack has apparently dealt with this. It runs its magic over the packages that you install (locally) and prepares them for ES module usage. So, after Snowpack has ran, now you can do this (which you haven’t been able to do before):

import React from '/web_modules/react.js';

Which is valid code for ES modules. Plus, if you run Babel anyway, you don’t even have to change that original line.

Hence their marketing/explanation:

1) Instead of bundling on every change, just run Snowpack once right after npm install.
2) Snowpack re-installs your dependencies as single JS files to a new web_modules/ directory.
3) Write code, import those dependencies via an ESM import, and then run it all in the browser.
4) Skip the bundle step and see your changes reflected in the browser immediately after hitting save.
5) Keep using your favorite web frameworks and build tools! Babel & TypeScript supported.

It’s kinda like you get native code splitting for free, and you’re just crossing your fingers that ES modules will be just as fast as bundling with that benefit. I’m optimistic. I think it’s early days and would be nervous on Big Production Stuff, but I also think native ES modules are probably the future.

The post Snowpack appeared first on CSS-Tricks.

CSS-Tricks

[Top]