再见啦，Ruby on Rails

也许我不会再在新项目中使用 Ruby on Rails 了。这是因为 Turbo 上的这个戏剧性的 Pull Request：https://github.com/hotwired/turbo/pull/971

为什么呢？

对于这个库的这个“重大变更”，我没有看到任何合理的过程。而这个库被成千上万的开发者使用，维护者对他人的意见没有给予任何尊重。

让我们细细看这个流程：

1. 他们在深夜发布了一篇博客。

2. 整个 PR 描述只是指向那个博客的链接。

3. 完全没有意愿倾听。

对于有坚定观点的维护者，我完全没有意见。然而，那些假装仁慈的独裁者，我并不喜欢。

如果你想继续阅读，让我再次仔细分析他们的内部矛盾之处。

最近，Rework Podcast发布了两集关于写作提案与想法的节目。虽然 Ruby on Rails 的维护与公司内务无关，但他们摒弃 TypeScript 的行为直接违背了他们提出创意的精神。

@dhh 提到了以下内容：

现在，我们在 37signals 所有的客户端代码都使用纯 JavaScript，内部库也是如此。这将使它们保持一致。

这句话毫无意义。

首先，Ruby on Rails 的维护者应该倾听。作为这个项目的创建者，并不意味着他们可以做出每个决策都是正确的。匆忙合并这个项目看起来很奇怪。

其次，在 37signals 内部这样做并不意味着每个 Rails 用户都应该跟随。Shopify 和 Stripe 为大规模 Ruby 项目创建了静态分析器（Sorbet: Stripe 的 Ruby 类型检查器和*Shopify 上的 Ruby 静态类型检查现状*）。这是强有力的证据，表明强类型将有助于团队的扩展。

37signals 常常会提出这样的论点： “为什么不保持小团队呢？这样你就不需要强类型了？”

简而言之，我们不希望类型成为团队规模的瓶颈。即使我们会保持团队的小型化，因为业务不需要那么多人，比如在一个很小美的市场。不能正确处理代码接口这件事情，永远不应该成为保持团队小型的理由。

我确实希望人们能够继续在 Ruby on Rails 上取得成功。 但对我来说，生命是短暂的，我不想浪费时间修复可以通过类型检查来预防的错误。我已经花费了数百个小时在这上面，却没有产生任何商业价值。

Ruby on Rails 曾经是快速项目扩展的首选，但今非昔比。 到了2023年，像FastAPI这样的选择提供了令人难以置信的灵活性，包括自动生成的前端代码，使得 Rails 不再是快速迭代的必需品。 让我们保持开放的心态，尤其是在开源项目的世界中。