【第2403期】打造Snowpack到20,000 Stars的5个经验之谈





My name is Fred, and I created Snowpack. If you're not familiar, Snowpack is a web build tool that fundamentally unlocked the "unbundled web development" movement that Snowpack, Vite, SvelteKit and other modern dev tools leverage today.


In this post, I want to share 5 things that I learned growing Snowpack from the initial commit to almost 20,000 GitHub stars and over 1,000,000+ downloads.

在这篇文章中,我想和大家分享我从 Snowpack 中学到的5件事情,这些事情从最初提交到将近20000个 GitHub stars 和超过1000000次的下载中学到的。

This post is meant for anyone interested in Open Source software. The highlighted lessons are directed at anyone who is interested in starting their own open source project or contributing to an existing project.


This will be a 2-part series: In this first post I focus on lessons learned creating Snowpack from scratch and finding our first set of users. In part two, I will focus what it's like to maintain a popular open source project, at scale.




A couple of years ago, I started an experimental JavaScript project. Codename: Pika. It had a cute, blue mouse mascot and a fun vibe that a bunch of smaller experimental projects could live under. Its unifying mission could be best summarized as, "ESM is this cool new technology, lets do more stuff with it."


That first year of Pika may have been the most productive year of my life. I created @pika/pack (a publishing tool for npm package authors), Pika CI (a Github action that let you npm install or even import() any GitHub PR), a failed in-browser code editor, and a next-gen JavaScript CDN that went on become Skypack.

Pika的第一年可能是我一生中收获最多的一年。我创建了@pika/pack(一个为npm包作者的发布工具),Pika CI(一个Github action,允许npm安装甚至导入任何GitHub PR),一个失败的浏览器内代码编辑器,以及一个继续运行的下一代的JavaScript CDN,后来成为Skypack。

The biggest standout of the bunch was @pika/web, which let you install any npm package to run directly in the browser without a bundler (ex: react -> /react.js). You probably know this project better under its newer name: Snowpack.

其中最突出的是@pika/web,它允许你安装任何npm包,直接在浏览器中运行,而无需bundler(例如:react -> /react.js)。你可能更了解这个项目的新名字:Snowpack。

Below are five lessons that I learned while growing Snowpack from its first commit to the official v1.0 release, and how we found our first set of users.


Lesson 1: Start with a personal frustration


Snowpack began as a tool to convert any npm package to a single JavaScript file that you could run in the browser. Sounds boring, right? Wrong!


This small, straightforward tool would unlock an entirely new mode of web development that is now referred to as "Unbundled Web Development". Unbundled development introduced features like instant reloads and near-instant startup time during development, using a process that wouldn't slow down as your project grows to 1,000 or even 10,000+ files. Compare this to more traditional bundled dev environments, where multi-second startup and reload times are still the norm today.

这个小巧简单的工具将开启一种全新的web开发模式,现在被称为 "Unbundled式网络开发"。Unbundled式开发引入了一些特性,比如在开发过程中即时重载和近乎即时的启动时间,使用的流程不会随着项目增长到1,000甚至10,000多个文件而变慢。相比之下,几秒的启动和重新加载时间今天仍然是常态。

The original idea for Snowpack came out of a simple, personal frustration that I had been having at work. I was working on the Polymer team at Google, where I had helped create some alterative build tools for the (now dead) HTML Imports spec. The tool itself was lovely, but it didn't work well with npm and very few people ever used it.

Snowpack的最初想法来自于我在工作中遇到的一个简单的个人的挫折。我当时在谷歌的Polymer团队工作,在那里我帮助创建了一些替代性的 HTML Imports 规范构建工具。这个工具本身很好,但它与npm不兼容,很少有人使用它。

I eventually left the Polymer team, but that problem still stuck in my head: Why had bundlers like webpack become the only way to use npm packages in the browser? Something has to solve the problem of getting npm packages to run in the browser, but did it have to involve bundling your entire website? Snowpack was my attempt to find out whether another path was possible.


Lesson for open source maintainers: Build for yourself, first. If you're frustrated by something, chances are other developers are too. Question everything.


Lesson 2: move fast, stay small


When you're working on a new project, you rarely know what code will be important long-term and what code is about to be deleted. I've thrown away enough code in my career to have learned that there's sometimes value in fast, messy coding. When you're starting a new project, it's okay to be a bit messy.


Internally, almost all of Snowpack's complexity was handled by Rollup. Snowpack was really just a wrapper around Rollup that would bundle only your npm packages instead of your entire website. Realizing that Snowpack could leverage Rollup internally saved me weeks (or maybe even months) of development time.


To be honest, Snowpack was just a single index.js file for the majority of its life.


To keep the project on track, I focused on a single feature: "give me a package name, and I'll convert it to ESM." This would be too low-level for most web developers. In fairness, Snowpack really didn't take off with a large audience until we added a built-in dev server and build command in v2.0. But even without the dev server, Snowpack's small v1.0 focus was enough for a certain kind of low-tooling/no-tooling web developer.


My overeall recommendation is to test your idea and get together a working demo as quickly as possible. In practice, this means four things:


Use existing tools! Fork a similar open source project or use an existing tool internally if it can save you time.

使用现有的工具! 如果可以节省你的时间,那么就Fork一个类似的开源项目,或者在内部使用现有的工具。

Write messy code! At the earliest stage, you probably don't know exactly know what you're building. Premature refactoring can sometimes be worse than never refactoring at all, so keep your code flexible for as long as possible.

编写混乱的代码! 在最初的阶段,你可能并不确切知道你在构建什么。过早的重构有时会比根本没有重构更糟糕,所以尽可能的保持你的代码的灵活性。

Keep scope small! Don't build half-baked, half-working features. Instead, focus on doing one thing very well.

保持小范围! 不要构建半成品功能。相反,要专注于把一件事做得非常好。

Skip tests! Confirm that you're building something useful before spending your free time writing tests for it. Nothing is worse than writing tests for something that you end up never using.

跳过测试! 在空闲时间编写测试之前,确认你正在构建一些有用的东西。没有什么比为一些你最终不会使用的东西写测试更糟糕的了。

I know that some of this could be considered a hot/controversial take. "No testing??? Blasphemy!" All I can say is that this strategy has worked well for me over several popular projects and countless unpopular projects that went nowhere.

我知道这其中有一些可能被认为是热门/有争议的观点。"没有测试?亵渎!" 我所能说的是,这个策略在我的几个受欢迎的项目和无数不受欢迎的项目中都很有效。

The obvious downside to this "move fast" advise is that it is not sustainable long-term. Moving fast means taking on tech debt, which you will absolutely need to repay at some point if your project becomes successful. As soon as you have some users who like what you're doing, you should begin to re-prioritize stability, refactoring and testing. More on this in the next post.

这种 "快速行动 "的建议的明显缺点是,从长期来看,它是不可持续。快速行动意味着承担技术债务,如果你的项目成功了,你绝对需要在某个时候偿还这些债务。一旦有一些用户喜欢你所做的事情,您就应该开始重新优先考虑稳定性、重构和测试。在下一篇文章中会有更多这方面的内容。

Paying down tech debt can be a slog. But, silver lining: If your project never takes off, then congratulations! You didn't waste any time testing something that no one wanted :)

偿还技术债务可能是一件苦差事。但是幸运的是。如果你的项目没有成功,那么恭喜你!你没有浪费任何时间去测试那些没有人想要的东西 :)

Lesson for open source maintainers: Write messy code, keep scope small, and skip any unnecessary work until you know that you're building something useful.


Lesson 3: Fix fast


You just received your first bug report. Oh no, someone tried your project out and it broke! But what matters is that they cared enough to tell you about it.


One of the best things that you can do in a new open source project is fix bug reports right as they come in. Prioritizing fixes over everything else becomes much harder as a project grows, so enjoy the freedom to move quickly while you still can.


Sebastian McKenzie (creator of Babel, Yarn, and now Rome) summarizes this theory well:

Sebastian McKenzie(Babel、Yarn和现在的Rome的创建者)很好地总结了这个理论:

One of the reasons Babel was successful is how quickly I was able to quickly fix bugs and release new versions. I would regularly have releases out within minutes of a bug report. This was critical during the early days when adoption was low. Being able to unblock users quickly would often make them more excited to use Babel even though they ran into a bug. -- Sebastian McKenzie, Rome

Babel成功的原因之一是我能够快速地修复bug并发布新版本。我经常在接到错误报告后几分钟内就发布了新版本。在采用率低的早期,这至关重要的。如果能够快速解锁用户,他们就会更乐意使用Babel,即使他们遇到了错误。-- Sebastian McKenzie,罗马

Lesson for open source maintainers: Your first users are essential. Prioritize fixing their issues over everything else.


Lesson 4: Practice good storytelling


Something about marketing always seems to make developers squeamish. Unfortunately, if you want people to use your project you eventually need to tell them about it. Even organic, viral word-of-mouth sensations tend to have a cheerleader acting behind-the-scenes.


To start, just share your project with a friend or colleague and ask them for their thoughts. It's okay if you don't hit the front page of Hacker News on day one, all you're looking for is early feedback and maybe your first users.

首先,与朋友或同事分享你的项目,并征求他们的想法。如果你没有在第一天就登上Hacker News的头版也没关系,你所寻找的只是早期的反馈,也许是你的第一批用户。

When you're ready to share your project with a larger audience, you have a few options for how to do it. One popular choice is to tell your story in small, visual pieces over time. This is how Sebastian built excitement for Rome for almost 2 years before its launch. Mark Dalgleish has also done a great job of promoting vanilla-extract on Twitter this way.

当你准备与更多的人分享你的项目时,你有几个选择来做这件事。一个流行的选择是,随着时间的推移,用小的、可视觉化的作品来讲述你的故事。这就是塞巴斯蒂安如何在《罗马》推出前的2年时间里为它制造兴奋。马克-达格利什(Mark Dalgleish)也用这种方式在推特上推广了香草提取物。

You can also get creative, and do something unique. Ben Holmes has been having a ton of fun recording announcement videos in front of a whiteboard for his new project, Slinkity.

你也可以变得有创意,做一些独特的事情。本·霍姆斯(Ben Holmes)为他的新项目Slinkity在白板前录制了大量有趣的宣传视频。

With Snowpack, I decided to tell our story in one big blog post. This took some serious time to write, but gave us the space to really explain the "why" of the project. I figured that we had to make an emotion connection to our bigger goal to change the web. Even though this was just a single post, it made a big splash when it was released and then got re-shared and referenced over the next year.


Lesson for open source maintainers: Promote your work. Find a style of storytelling that fits you and your project.


Lesson 5: Ignore your haters, listen to your users


If your work ever gets posted to Hacker News, expect some haters.

如果你的作品被发布到Hacker News上,恐怕会有人讨厌你。

If you're lucky, you can tell the difference between ignorant criticism and constructive criticism. Ignore the ignorant stuff (aka haters) but listen to the constructive feedback if you can. If someone shows that they took the time to at least attempt to understand your project in good faith, their feedback will usually have some value if you can spot.


A common constructive criticism is when someone clearly tried understand your work, but still misunderstood some key part of it. It's easy to call that person dumb and move on, but remember that clear communication is your responsibility. When someone misunderstands your work, it usually means that you could improve your README or documentation or general storytelling in some way.


Lesson for open source maintainers: Haters gonna hate, ignore them. Learn how to spot the good-faith, constructive criticism.


Main Takeaway: Support your early users


If you're starting a new open source project, the best thing that you can do is make sure that your first 10 users are happy. All of the lessons above are really just about finding and supporting these first users in some way. If you do right by them, then you've already built something meaningful.


And if this all sounds like too much work, remember that open source software has no rules. It's supposed to be fun. Building for yourself or a smaller audience is totally fine, in which case you can go ahead and ignore most of this advice.



作者:@Fred K. Schott


【开源】双十一前的一把火 —— NutUI 大促组件火热发布

【开源】企鹅电竞高性能动画组件 - VAP