在 2026 年重回 Rails 的懷抱
我分享了在開發側邊專案時重新發現 Ruby on Rails 8 樂趣的心路歷程,特別強調了其現代化的免構建前端開發方式,以及為何儘管面臨當前產業趨勢,它依然是一個強大的開發工具。
背景
本文作者分享了他在 2026 年重回 Ruby on Rails(以下簡稱 Rails)開發側邊專案的體驗。作者因樂團管理需求開發了 setlist.rocks 應用程式,在遠離 Rails 十多年後,他發現這套框架依然保有極高的開發樂趣與生產力,並感嘆在現代前端框架與微服務盛行的當下,Rails 這種「老派」的單體架構反而能提供更直覺、更像人類語言的開發體驗。
社群觀點
針對 Rails 的現狀,Hacker News 社群展開了激烈的討論,其中最受爭議的是 Rails 官網近期將標語改為「加速你的 AI 代理人(Agents)」以及強調「Token 效率」的行銷策略。許多資深開發者對此表示強烈反感,認為這是在盲目追逐 AI 熱潮,抹殺了 Rails 原本以人為本、追求代碼優雅的核心價值。批評者指出,如果開發工作都交給 AI 代理人處理,那麼底層使用哪種框架似乎已不再重要,且過度依賴 AI 生成代碼可能會在 Ruby 這種高度動態且具備「魔法」特性的語言中埋下難以維護的隱患。
然而,也有另一派觀點為此辯護。支持者認為 Rails 強調的「慣例優於配置」(Convention over Configuration)確實能讓 LLM 模型更精準地預測代碼結構,因為框架本身有著極強的規範性,這使得 AI 生成的代碼更易於人類審核與審計。此外,關於 Ruby 缺乏類型系統的疑慮,社群成員提到 RBS 和 Steep 等工具已為 Ruby 帶來了類似 TypeScript 的類型檢查體驗,這在一定程度上緩解了大型專案維護的痛點。
在技術選擇的廣度上,討論也延伸到了 Rails 與其他框架的對比。部分開發者認為 Rails 雖然在調查報告中的受歡迎程度不如 JavaScript 體系,但其內建的安全性(如 CSRF 防護、SQL 注入防治)以及完整的 MVC 模式,依然遠勝於許多只專注於渲染性能卻忽視基礎設施的現代 JS 框架。儘管有人抱怨 Rails 的長期維護與版本升級成本較高,甚至轉向 Go 語言以追求更簡單的部署與二進制分發,但對於追求開發樂趣與快速原型開發的工程師來說,Rails 提供的「全棧電池」體驗在 2026 年依然具有不可替代的魅力。
延伸閱讀
- setlist.rocks:作者開發的樂團曲目管理應用程式。
- 2025 Stack Overflow Developer Survey:文中提到的開發者趨勢調查報告。
- RBS 與 Steep:Ruby 的類型標註與檢查工具。
- Phoenix Framework:留言中推薦作為 Rails 替代方案的 Elixir 框架。