5年500万美元之后：为Web开发发明新编程语言是个错误 | Wasp

# 5年、500万美元之后：为Web开发创造一门新编程语言是个错误 来源：https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake 在Wasp（https://github.com/wasp-lang/wasp），我们正在构建一个全栈Web框架——可以看作是JavaScript版的Rails/Laravel，但还“延伸”到了前端。我和我的双胞胎兄弟在2021年通过Y Combinator时启动了它，总共筹集了超过500万美元。 Wasp在2021年2月于Hacker News上的Launch HN帖子 我们最初的想法是构建一门新编程语言，既要抽象常见的Web应用模式，又要在需要深入时能与任何技术栈（我们从React、Node.js和Prisma开始）配合。可以想象成Terraform，但针对的是你的Web应用栈而非云基础设施。 五年过去了，我们意识到这是个错误。创造一门新语言对某些问题和领域是有意义的，但在这个案例中，它并不合适，带来的麻烦超过了其价值。 这篇文章讲述了我们为什么认为这是个好主意，我们学到了什么，以及为什么我们要用TypeScript替换我们的自定义语言，而Wasp本身在底层保持不变。 ## TL;DR（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#tldr） 这是一篇长文。以下是涵盖的关键点，你可以跳转到感兴趣的部分，无需阅读全部内容： - 多年来一直在切换Web开发栈，我们觉得如果能创建一个适用于任何技术栈的“通用框架”会很酷。我们得出结论：需要创造一门新语言（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#why-create-a-new-language-from-scratch-why-not-use-the-existing-ones）来实现这一点。 - 开发者对Wasp解决的问题产生了共鸣，但语言本身却很难推销（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#reception-you-loved-the-idea-and-tolerated-the-language）。名称中的“Lang”让他们以为我们的目标是取代JavaScript（其实不是），并对它如何与现有工具配合持怀疑态度。 - 许多开发者一旦尝试了Wasp就爱上了它。但让他们尝试却是最难的部分。 - 采用率仍在增长，但随着我们不断推进1.0版本，我们意识到“语言”这个顾虑不会消失。此外，为自定义语言维护良好的IDE体验比预期困难得多（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#the-final-nail---trying-to-make-ide-support-work）。 - 结果发现，拥有自定义语言并不是Wasp的核心价值。核心价值在于维护整个全栈应用的高层规范（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#language-was-never-the-moat-its-having-a-high-level-understanding-of-your-entire-app-at-compile-time），使其对人类和AI都更容易推理。 - 我们决定用TypeScript替换Wasp的配置语言（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#goodbye-wasp-language-welcome-typescript）。这“仅仅”是一个接口变更，其他一切保持不变。 ## 为什么我们认为创造一门新语言是个好主意（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#why-we-thought-creating-a-new-language-was-a-good-idea） 我哥哥和我都来自传统的计算机科学背景，主要专注于算法及其在生物信息学和机器学习等领域的应用。我们从未将自己视为Web开发者，甚至有些抵触（“看看这些人整天只是画按钮，而我却在编写所有酷炫的算法”）。显然，我们了解得不够。 尽管如此，我们小组中有一位创业的朋友，他总是在做一些副业项目，每当接到大项目时就会拉上我们。每个项目都有一些让我们觉得“有趣”的地方（例如，构建一个需要推荐引擎的新闻门户，或一个期权交易分析平台），但归根结底，大部分都是经典的Web开发工作。 这样，我们接触到了诸如PHP（我们用PHP从头构建了一个完整的CMS，后来才发现有框架甚至可以直接使用的现成解决方案）、Java/JBoss，以及随着它们兴起的Backbone.js、Angular.js和React，还有构建工具（还记得Bower、Grunt和Gulp吗？）。 2013年及以后，是响应式前端框架的时代，每个新框架都必须在你的最新项目中使用，因为这也是让你的项目/初创公司变得酷的一部分。结果是，每当我们启动一个新项目，几乎都要使用与上一个完全不同的技术栈，必须重新学习刚刚弄明白的所有模式——身份认证、路由、状态管理…… ### 我们厌倦了切换和拼接技术栈（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#we-got-tired-of-switching-and-stitching-stacks） 以前，你只需在Spring Boot、Django或Rails中选择一个，所有事情都会被处理和管理。而现在，我得先挑选每个库，然后让React、Redux、Webpack、Express、Passport和Sequelize协同工作。 没有一个系统在负责，能够全面理解Web应用，这种责任感让Martin和我感到不太舒服。 在经历了数次技术栈切换（最终落定于React、Node.js和当时的Mongoose）之后，我们想——难道没有更好的方法吗？感觉我们在不断重复发明同样的东西，大部分时间都花在管理技术栈上，而不是编写我们独特的业务逻辑。 这有一个名称：*偶然复杂度*。那些与你的实际问题无关，但由于使用的工具而无法避免的工作。这正是我们的感受。 ### 如果我能只表达一次我想要什么，会怎样？（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#what-if-i-could-just-say-what-i-want-once） 我们问自己：如果你能简单地写下你想要什么，就这样，会怎样？例如： - *“我希望我的应用有Google和GitHub的身份认证”* - *“我希望有一个/profile路由，仅对已认证用户开放”* - *“我想要一个cron任务，每天下午5点运行这个函数”* 显然，这太口语化了，所以我们设想将其简化为更结构化的形式，比如： - `auth: Google, GitHub` - `page Profile -> /profile, authRequired: true` - `job updateStats: run function doSomeCalc from stats.js every day at 5pm` 这基本上是一种在更高级别、无实现细节（即规范）上定义应用需求的方式。我们觉得这类事情应该是可能且应该存在的，但使用我们现有的工具，我们必须将这些需求分散在整个技术栈中，在感觉上抽象层级太低的地方逐一实现。 我们的目标从来不是取代现有的技术栈。你仍然会在特定的运行时（例如React或Node.js）中实现大部分逻辑。但会有一个中心骨干将一切连接在一起。 Wasp架构图我们如何构想（并实现）Wasp。配置.wasp文件中包含高层声明 + 你在React和Node.js中的自定义逻辑，输出为完整可运行的全栈应用作为构建产物。 如果你好奇，这是DSL最终形态的代码片段： `` app todoApp { title: "ToDo App", // 在浏览器标签页中可见 auth: { // 开箱即用的全栈身份认证 userEntity: User, methods: { google: {}, gitHub: {}, email: {...} } }}route RootRoute { path: "/", to: MainPage }page MainPage { authRequired: true, // 仅限登录用户访问 component: import Main from "@client/Main" // <-- 你的React代码。}query getTasks { fn: import { getTasks } from "@server/tasks", // <-- 你的Node.js代码。 entities: [Task] // 自动缓存失效。} `` 我们的关键洞察是：**Web应用领域变化非常缓慢，而Web开发实现技术的演进速度却很快**。无论是十年前还是今天，我们都在讨论页面、路由、API端点和数据模型。与此同时，UI实现从服务器模板到富客户端再回到服务器操作，走了一个完整的循环。 我们使用Wasp的目标是让开发者尽可能在领域层面表达需求，让系统处理（最新的）实现细节。这样，他们构建的东西将更持久且更易于理解。 ### 为什么从头创造一门新语言？为什么不使用现有语言？（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#why-create-a-new-language-from-scratch-why-not-use-the-existing-ones） 虽然我们对问题的理解大部分被证明是正确的（因为我们亲身经历过），但这里是我们走错的一步。 我们选择从头设计一门新语言，带有自己的自定义编译器，而不是使用例如TypeScript或Python作为“宿主”语言，主要有两个原因： - **我们希望完全控制语法**，使其尽可能简洁且无样板代码。 - **我们设想Wasp最终是与运行时无关的工具**。例如，也许你在Node.js中编写典型的CRUD逻辑，但某些数据密集型的部分你更愿意在Python中进行，因为后者有更好的库。 虽然我们考虑过使用TypeScript（这也是我们早期得到的一些反馈，建议使用嵌入DSL，即本质上只是一个库，而不是显式DSL），但当时这感觉像是“错误的”，仿佛我们会背叛Wasp的核心原则和宏大愿景。 在某种程度上，我们非常兴奋地将Wasp作为一门独立语言发布，因为我们相信这会发出更强的信号，表明它不是另一种典型的受语言限制的框架（例如Rails或Django），而是更通用的东西。 Wasp首个着陆页我们的第一个着陆页，早在2021年。我们自豪地将“语言”放在最中心的位置。 说实话，我们也为自己能从事如此“酷”且基础性的事情（比如语言和编译器）而兴奋。Martin和我都是Haskell爱好者，这正好是我们功能锤子下的完美钉子。 ## 反馈：你喜欢这个想法，但忍受了这门语言（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#reception-you-loved-the-idea-and-tolerated-the-language） 大约在Wasp工作了一年、发布了Alpha版本并推向开发者（https://wasp.sh/blog/2022/09/29/journey-to-1000-gh-stars）之后，我们找到了一个小众的早期采用者群体，并被Y Combinator录取。不久后，我们筹集了种子轮前资金（https://techcrunch.com/2021/10/04/yc-grads-wasp-land-1-5m-seed-to-help-developers-build-web-apps-faster/），这使得我们能够组建团队并构建第一个“真正”的版本。 起初事情进展缓慢，但开发者对样板代码的痛点感受强烈，且厌倦了技术栈拼接，因此Wasp逐渐获得动力，尤其是在我们进入Beta版本之后。 你可能还记得，大约在同一时间，2021年，另外几个“Rails for JS”框架也出现了，比如RedwoodJS（由GitHub的创建者打造）和BlitzJS。它们迅速获得了社区关注，我们清楚地意识到自己正在解决一个重要问题。 ### 有时另类会有回报 在某种程度上，Wasp的“另类”使其避免了Redwood和Blitz的命运。通过避免与特定技术（Redwood依赖GraphQL，Blitz依赖Next.js）紧密耦合，它保持了足够的通用性，能够快速适应并避免过时。 GitHub星标增长 然而，在与开发者交流时，“但你们为什么要创造一门新语言？”这个问题不断以不同形式出现。我们听到了几个主要反对意见。 ### 我看到了“wasp-lang”——这要取代JavaScript吗？（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#i-see-wasp-lang---does-this-replace-javascript） 虽然我们从未打算取代现有的Web开发技术栈，而是补充它（使用Wasp，你仍然用React和Node.js编写90%的代码），但“lang”后缀的概念过于强烈，无法传达这一点。 每当开发者读到“wasp-lang.dev”时，他们的大脑会自动想到“哦，这有点像Rust/Java”，一旦这种印象形成，就很难消除。它立即将Wasp归入“看起来酷，但为时过早”的类别。 我们非常兴奋地构建一门语言并突出它，但我们低估了这个词在人们心中已有的含义。 ### 这会与我的IDE和现有工具配合吗？（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#is-this-going-to-work-with-my-ide-and-existing-tooling） 即使你暂且相信语言这件事没问题，下一个问题就是，“它有自己的一套生态系统吗？”开发者知道创建一个新标准需要多少工作，以及围绕它发展生态系统需要多长时间。 ### 这不适合我，我不想学Haskell（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#this-isnt-for-me-i-dont-want-to-learn-haskell） Haskell喜爱表情包 我们在编译器内部使用了Haskell，但最终用户永远不会看到它，只会使用TypeScript。这类似于Prisma的核心最初用Rust开发，Terraform的HCL用Go开发。 尽管如此，我们早期围绕使用Haskell的营销对我们自己来说有点过于成功了。Haskell社区虽小，但参与度高、热情，并且非常渴望现实世界的项目，尤其是围绕开发者工具的项目。 与社区分享我们的进展通常很受欢迎，但也强化了Wasp作为“基于Haskell的语言”的印象，尤其是如果你只是扫一眼标题。 Haskell定位问题 再加上在GitHub仓库页面的“语言”栏中显示“Haskell: 90%”（后来我们找到了规避方法），你就得到了一个完美执行的错误定位。 ### 这是包装问题（https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake#its-the-packaging-issue） 许多真正尝试过Wasp的开发者都喜欢它，并不太在意语言本身。他们能够比以往更快地交付，无需花费数周学习技术栈，并继续使用React和Node.js。但让开发者从“这是什么？”跳到“我要试一试”真的很难。 开发者关于Wasp的推荐语一旦尝试，许多开发者真的很喜欢Wasp。困难在于让他们尝试。 我们一直在努力。随着Beta版本的推出，采用率飙升，我们开始看到用Wasp构建的初创公司被收购，企业也在构建内部工具并部署到他们的本地基础设施中（毕竟，Wasp应用只是静态前端文件 + 一个用于后端单个Docker镜像）。 为了打破“这是一个奇怪的新框架，我为什么要尝试？”的障碍，我们在Wasp之上构建了产品（一个开源SaaS样板启动器（https://opensaas.sh/）和我们自己的“早期”Lovable（https://wasp.sh/blog/2023/07/10/gpt-web-app-generator）），将决策提升到一个更高的层面。这效果很好，吸引了许多人来到Wasp。 尽管如此，核心问题依然存在。来到Wasp的开发者无法理解我们在构建什么，所以他们无法为此兴奋。 ### 最后的钉子