Ruby on Rails：纪录片 [视频]

原文 ↗ Hacker News 讨论 ↗

一部关于 Ruby on Rails 的新纪录片重新点燃了人们对该框架的兴趣，并引发了对其影响力的反思：许多人赞赏 Rails 强约定、连贯的“一个大框架”方式，以及即使在诞生数十年后，仍能以惊人的生产力构建全栈 Web 应用。评论者将 Rails 与更碎片化的 JavaScript 生态，以及 Django、Laravel、Phoenix、Spring 和 ASP.NET 等框架进行对比，讨论了性能、长期可维护性和架构灵活性之间的取舍。虽然有人批评 Rails 的紧耦合、ActiveRecord 和 gem 膨胀会让大型系统难以演进，但也有人认为，它的一致性、工具链以及不断演进的特性（Hotwire、Turbo、Solid Queue/Cache 等）仍使其成为快速交付并扩展真实产品的首选之一。

关于这部纪录片的整体反应

  • 许多人觉得它有趣、怀旧且振奋人心；有人说它重新点燃了对 Rails 的兴趣，或者让他们第一次想尝试它。
  • 也有人觉得它太短、太表面化，更像是轻度的英雄崇拜，而不是深入的历史，并希望它能更详细地涵盖挣扎和长期演变。
  • 还有几位提到，早期一些对他们很有影响的社区人物和资源没有被提及。

Rails 的核心优势

  • 强约定和一致的应用结构广受赞赏：大多数 Rails 应用“看起来都一样”，这降低了上手门槛，减少了无谓争论，也帮助代理商/顾问快速进入不熟悉的代码库。
  • 高生产力是反复出现的主题：人们表示，在 Node、Go 或之前的 Python/JS 技术栈上相比，Rails 往往能快好几倍，尤其适合 CRUD 风格的 Web 应用和原型开发。
  • Hotwire/Turbo、Turbo Native、Strada，以及集成化工具链（如 Solid Cache/Queue、Kamal）被视为进一步强化了 Rails 作为一个少写 JavaScript 的、连贯的全栈解决方案。

与其他生态系统的比较

  • JS/Node 因缺乏一个具有强约定的“单一框架”而受到批评；一些人认为 Next.js 最接近，但仍然偏前端。其他 JS 全栈尝试（Adonis、Remix、SvelteKit 等）也被提到，但被视为更像需要自己拼装。
  • Laravel 和 Phoenix 最常被拿来与 Rails 相比，认为它们在生产力上更接近 Rails。Django 被看作 Python 里的“Rails”，但在某些 Web 应用需求上，内置配套略少。
  • Spring 和 ASP.NET Core 被提及为在生产力上可比、也更“企业友好”的方案，拥有长期支持和更平滑的升级体验。

批评：架构、维护与社区

  • 有人认为，统一的 Rails 布局把“管道层”（MVC、ActiveRecord）置于领域建模之上，导致模型臃肿、耦合紧密、长期演变变得凌乱，尤其是在复杂或非 CRUD 领域中。
  • 关于是将业务逻辑紧密耦合在 Rails 中，还是通过 engines、gems、六边形架构或 repositories 将其隔离，存在争论；不同人的观点和经历差异很大。
  • 对生态的批评包括对 gem 的高度依赖、“魔法”、历史上的升级痛点，以及一种据称会强化框架耦合并抵制替代模式的文化。

性能与可扩展性

  • 一方认为 Ruby/Rails“非常慢”，不适合高吞吐、IO 密集型任务（例如 JSON 转换型 API 网关），更偏好用 Go/Java/Elixir 来做这些事。
  • 另一方则反驳说，对于典型的数据库绑定型 Web 应用，Rails 的速度“已经足够快”，在大公司中也得到了验证，而且比起系统设计和数据库访问，性能往往并不是实际瓶颈。

Ruby、学习曲线与开发者体验

  • 一些来自 Python/JS 的新手觉得 Ruby 更难“领会”（symbols、元编程、同一件事有多种写法）；但也有人恰好相反，认为 Ruby/Rails 比 Django 或 JS 技术栈直观得多。
  • Ruby 经常被描述为令人愉悦且优雅；“万物皆对象”和 REPL/console 之类的特性被视为显著提升生产力和测试效率。
  • 也有人对治理决策和框架的“意识形态”方向表示担忧，在新项目中更偏好现代 TypeScript 全栈方案。