Snowpack: 4.0 and beyond

👋🏻 Hello! Wanted to create an issue to provide a bit of a project update and what we have planned. First, some background:

Snowpack launched in Jun 2019 (over 2 years ago!). Since then, it’s had 3 major releases, a name change (originally @pika/web), 1.2+ million downloads from npm, over 18k stars on GitHub, and 300+ contributors. And the best part has been the community—seeing so many excited to push the web forward while simplifying tooling.

In that 2 years, a lot’s changed! For starters:

• Node.js shipped ESM support in core (2019)
• esbuild appears, providing an orders-of-magnitude-faster alternative to Babel for pure building (2020)
• Node.js ships subpath exports, providing built-in CommonJS <> ESM interop (2020)
• Deno 1.0, a 100% ESM competitor to Node, is released (2020)
• Node.js 10’s EOL means package maintainers can now ship ESM-first packages (2021)
• Another ESM build tool appears on the scene (2021)

It’s been rewarding to watch the web progress as we envisioned 2 years ago. And we’re proud Snowpack has played a big role in that direction.

What’s next for Snowpack

Snowpack’s original goal was to simplify the overcomplicated toolchain developers had to wrestle with to ship the most basic of websites. And Snowpack achieved that! So well, in fact, it started doing more than simply building websites; it’s now starting to be used to make new generation of build tools. Nate Moore’s Microsite and our own Astro are key examples of how Snowpack can convert almost anything you throw at it into plain ol’ HTML/CSS/JS (and do it blazing-fast, to boot).

Our vision for the future of Snowpack centers around improving this foundation for new generation of web tooling. Developers should be able to use all of npm and modern JS without wrestling with all the complexity themselves. Here are some upcoming highlights:

• ⚡️ Improved SSR API. The future of the web is SSR. Today, Snowpack’s SSR engine requires hard files and disk access. Snowpack was also originally designed for shipping code to browsers, which can limit an SSR build when Node.js is needed to execute. Snowpack v4 will introduce virtual file support which will allow Snowpack to do more in-memory for flexibility and performance, as well as full Node.js SSR support for people to unlock the full power of Node. Imagine being able to power servers with Snowpack and being able to SSR on-the-fly, all while managing less of that yourself!
• 🐇 All-in on esbuild. Snowpack was quick to adopt Go-powered esbuild, and it’s payed dividends in performance. But Snowpack has also had to build out features while the esbuild project matured, with the end result being duplication between the two. There’s more performance Snowpack could be tapping into, but it could require a bit of work behind-the-scenes. And let’s not forget about esbuild’s list of community plugins that are starting to catch up to all that Snowpack can do, but with theoretically faster performance. By betting on esbuild and letting it power more in Snowpack, Snowpack can focus on providing everything esbuild doesn’t: an HMR-powered dev server, SSR APIs, streaming imports, and everything else to come.
• 🍱 Multi-platform targeting. Snowpack’s original design assumed a browser target, which while a great starting point, it’s incomplete with HTML, CSS, and JS turning into more universal languages that power even desktop and mobile apps, and with webviews becoming a core foundation of software in general. Snowpack v4 will introduce multi-platform targeting which means you’ll be able to use Snowpack to build for more than just browsers.
• 🧩 Improved JS API. The CLI came first in Snowpack, followed by the JS API, and it shows in several areas. Snowpack v4 will take on the remaining work making the JS API feature complete, and moving it to be the core of Snowpack. In the process, we’ll be able to clean up Snowpack and make more room for even more in v5 and beyond.

The overall goal with the next major release of Snowpack is to open up more possibilities for building for the web.

Snowpack Community 2.0

We realize over the past few months Snowpack releases, development, and community management has come in waves. This is largely being limited by only a couple core maintainers. We’d like to do better not only being consistent ourselves, but help shepherd more contributors into becoming more dedicated core maintainers. So in that light, look forward to a new Governance Model for Snowpack that will improve the following:

• Clearer path from contributing to becoming a core maintainer
• Clearer responsibilities for core maintainers
• More regular maintainer discussions & meetings.

Whether you’re new to Snowpack altogether, or if you’ve been following the project for a while but have been confused how to get more involved, all of this will help!

We’re hoping that this feels like a “Day 1” for a new contributor community.

There’s never been a better time to get involved! If you’d like to learn more about contributing, head over to the Snowpack Discord’s #contributing channel!

Thanks so much for making Snowpack what it is today. We couldn’t do it without each and every one of you 🗻.

[FredKSchott]

Hey everyone, I just posted a blog post to dev.to that includes some context on some burnout that I experienced while maintaining Snowpack and some thoughts on the current state of Snowpack. I figured it was worth sharing here: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

It’s hard to summarize the post without losing important context, so I won’t add a tl;dr. But I will say: it felt really nice saying out loud a question that has been bugging me for a while now: what should we do about Vite? We live in a world where Vite is well maintained, has community buy-in across multiple projects/ecosystems, and is a pretty straightforward drop-in replacement for Snowpack in most projects. I’ve personally heard from several users and build tool authors who transitioned from Snowpack to Vite and were happy with the result. We even have an experiment going on inside of Astro that fixes some bugs by converting from Snowpack to Vite.

I have so much love for this project and the people who have used it, contributed to it, and believed in it since day one. Snowpack isn’t going anywhere. But I think it is time for a convo about what path forward is best for existing Snowpack users. The best path forward might be a clean migration to a similar-but-better-maintained project like Vite.

[jacty]

Hey everyone, I just posted a blog post to dev.to that includes some context on some burnout that I experienced while maintaining Snowpack and some thoughts on the current state of Snowpack. I figured it was worth sharing here: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

It’s hard to summarize the post without losing important context, so I won’t add a tl;dr. But I will say: it felt really nice saying out loud a question that has been bugging me for a while now: what should we do about Vite? We live in a world where Vite is well maintained, has community buy-in across multiple projects/ecosystems, and is a pretty straightforward drop-in replacement for Snowpack in most projects. I’ve personally heard from several users and build tool authors who transitioned from Snowpack to Vite and were happy with the result. We even have an experiment going on inside of Astro that fixes some bugs by converting from Snowpack to Vite.

I have so much love for this project and the people who have used it, contributed to it, and believed in it since day one. Snowpack isn’t going anywhere. But I think it is time for a convo about what path forward is best for existing Snowpack users. The best path forward might be a clean migration to a similar-but-better-maintained project like Vite.

I think the reason we are losing users is because of delay. I have been following this rep and trying to help as much as I can in issues and found out that many issues have been leave unresolved for long even without a reply from official member. It is just like a poor customer service. And our official website even has many wrong links and UI problems. All those just make new users feel cold to make a try, I guess.