从批评到万星：Wasp 全栈框架的市场验证

“你们正在打造的是开发者梦寐以求的圣杯。迄今为止，还没有人成功过。” 🏆 ☠️

这是 2020 年 5 月，我和 Martin（我的双胞胎兄弟）第二次带着 Wasp 申请 Y Combinator 时收到的反馈。当时，我们已经开发 Wasp 一年半，其中最近九个月是全职投入。我们辞掉了之前的工作，押上了一切。

如今，Wasp 在 GitHub 上已经收获了超过 15,000 个 star。更重要的是，不同背景的开发者使用它构建了数千款 Web 应用：从后来被收购或开始盈利的业余项目，到获得风险投资的初创公司，再到部署于《财富》世界 500 强企业内部的工具。

有些人逐渐爱上了 Wasp，以及它所追求的愿景。正因为有他们，我们才能乐在其中地继续这项工作。如果没有聚集在 Wasp 周围的社区——我们的 Discord 中已有超过 4,000 名开发者——我们根本不可能走到今天这一步。为了他们，我们会继续向自己承诺的那个圣杯迈进。

我们的工作才刚刚开始，但我们从未像现在这样兴奋。

这段旅程：从 0 到 15,000 个 star

和大多数成功故事一样，成功很少是线性发生的。它通常始于一段漫长的“干旱期”，其间偶尔显露出一丝生机；随后，某个时刻一切突然严丝合缝地衔接起来，事情开始飞速向前发展。我们也经历了同样的过程，大致如下：

起点：“为什么不试试？”

最初，Wasp 只是一个想法——或者更准确地说，是一个问题：“为什么至今没人做出这样的东西？如果我们尝试一下，会发现什么？”

在十年间，我们一直在构建 Web 应用，也用遍了各类主流技术栈：服务端从 PHP、Java 到 Node.js，客户端则从 Backbone、Angular 到 React。我们深受“框架疲劳”之苦——换句话说，每接触一套新技术栈，都要重新发明一遍轮子。

于是，我们开始认真思考这个问题，并把想法写在纸上（好吧，其实是 Google Slides）。Wasp 最初的构想由此诞生：我们能否创建一个框架，通过提供更高层的抽象来消除大量样板代码，同时又保持足够的灵活性，不被特定的技术栈和架构牢牢绑定？

现在回过头来看，这听起来确实像是一个圣杯。

进入 YC，一切开始成为现实

一年前，我们就已经辞掉了工作。那时，我们身心俱疲，也开始怀疑整个概念是否真的可行。虽然项目已经获得了一些早期关注，并在 Reddit、Hacker News 和 Product Hunt 上收到了令人鼓舞的反馈，但我们也逐渐意识到，要把一个全栈 Web 框架打磨到真正可用的程度，需要投入多么庞大的工作量——尤其是我们还为自己设定了如此雄心勃勃的要求。

最终，在第三次申请时，我们成功进入了 YC。此前一年，他们一直在关注我们的进展；看到社区表现出的兴奋与期待后，他们决定在我们这个疯狂的想法上押一注。

Beta 及其后：MAGE 与 OpenSaaS

从图表中可以看到两个关键的拐点。第一个出现在 2023 年 7 月，当时我们发布了 MAGE——一个底层使用 Wasp 的 GPT SaaS starter（你可以把它理解为一次生成式的 Loveable/Bolt）。它是最早能够生成可运行全栈 Web 应用的 LLM 产品之一，因此为 Wasp 带来了大量关注。

第二个主要的增长催化剂出现在 2023 年 12 月，我们发布了 OpenSaaS。这是一套构建在 Wasp 之上的开源 SaaS starter，如今在 GitHub 上已经拥有接近 10,000 个 star。

我们意识到，大多数开发者真正想要的是尽快开始实现自己的想法，而不是挑选并拼凑每款 SaaS 都需要的各种功能——身份验证、支付、管理后台、邮件发送、博客……

而这正是我们所提供的：一个 100% 免费且开源、高质量的 SaaS starter，基于 React、Node.js、Prisma 和 Wasp 构建。OpenSaaS 基本上成为了 Wasp 的“杀手级应用”：它吸引开发者前来尝试，并让他们切实体会到这个框架有多么实用。

OpenSaaS 与 Cursor 的组合也非常出色。得益于 Wasp 稳健的结构和更高层的原语，许多开发者发现，这是一个理想搭档，能让他们在短短几天内，将 SaaS 从一个想法推进到可用于生产环境的应用。

语言/DSL 还是框架——它究竟是什么？

从上面的例子可以看出，我们过去常把 Wasp 称为一种语言，或者 DSL——Domain Specific Language（领域特定语言）。之所以如此，是因为我们最初的目标就是建立一个抽象层，让它未来能够与任何语言、库和架构配合使用。

为此，我们需要引入自己的编译器。它会先分析你通过 Wasp 定义的应用规格，例如路由、异步任务、数据库操作等；然后，将这些规格与你使用 React 和 Node.js 编写的“原生”代码结合起来；最后生成一个 React/Node.js 应用。实际上，这意味着我们发明了自己的语言，尽管它非常有限，也很简单。

最初，我们就是这样介绍 Wasp 的，但后来发现，这种理解方式并不正确。从功能上看，Wasp 就是一个 Web 框架，与 Laravel、Rails 或 Next.js 并无不同。至于它在底层使用了编译器，只是一个实现细节，却也正是这个细节赋予了它强大的能力。例如，得益于这种方式，我们可以轻松可视化整个应用的拓扑结构，从数据库、服务端一直延伸到客户端组件：

通往 1.0，以及构建下一代框架

以上就是 Wasp 如何一步步走到今天的故事。如果你想了解更早期的细节——从一个想法发展到最初的 1,000 个 star——可以阅读这篇文章。

接下来是什么？经过近五年的开发，以及持续收集大家的反馈，我们已经非常清楚 Wasp 1.0 应该是什么样子。简单来说，我们要构建一个能够提供最佳开发者体验的全栈框架。我们希望你专注于打造自己的产品，把与技术栈较劲的时间降到最低。

想想 Rails 和 Laravel 为 Ruby 与 PHP 做了什么——我们正在为现代、由 AI 驱动的 JS 生态系统做同样的事情。

如果你想关注我们的故事并支持我们，请在 GitHub 上为 Wasp 点亮 star，并加入我们的 Discord——我们迫不及待地想在那里见到你！

部分评论可能仅对已登录的访客可见。登录后即可查看全部评论。部分评论已被文章作者隐藏——了解更多。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。