Rails在2024年还能重现辉煌?


自 2004 年夏天首次公开发布以来,Ruby on Rails 已经改变了游戏规则。
但是,嘿,这不是一个历史课。
这就是为什么 Rails 仍然是 2024 年首选 Web 框架的原因。

成熟又现代
Rails 是软件框架中的 Radiohead。想想看:Radiohead 自上世纪 90 年代中期[就已成为一支知名乐队,但他们并不只是在摇滚乐上一鸣惊人。他们的音乐风格从另类摇滚到电子乐再到其他,一直在音效上不断突破。

同样,Rails 拥有它一直倚重的 MVC 核心结构,但在每一个版本中,它都能找到融入新技术趋势而又不失其灵魂的方法。

播放 Radiohead 唱片中的任何一首歌,听起来可能会有些不同,但感觉就是 Radiohead 的风格。

打开过去二十年中的任何 Rails 应用程序,都会看到一些不同的方法和工具,但看起来和感觉上仍然是 Rails 应用程序。

具有讽刺意味的是,二十年前,我必须让潜在客户相信,Ruby on Rails 不只是一时的流行,它还能与业界巨头抗衡。我必须解释为什么它比当今层出不穷的 JavaScript 框架更好。

社区驱动
Ruby on Rails 是一个有主见的框架。这常常被误解为 "意见 "不是社区驱动的意见,而是 Rails 创建者 DHH 的意见。

这并不完全准确。我们有数据表明并非如此。

二十年来,Basecamp 一直与社区分享其工具选择和方法。
他们的数据库首选 MySQL。他们选择 Test::Unit 作为测试框架。

在我们 2022 年一年两次的 Ruby on Rails 社区调查中,来自 102 个国家/地区的 2,660 名开发人员参与了调查。
在这调查结果中,RSpec 是 Rails 开发人员广泛采用的首选测试框架。

当常见功能和集成需求存在明显的痛点时,Rails 开发人员会快速贡献新的 Ruby gem 来帮助自己和他人解决问题。

吸引优质人才
高质量的软件工程师不会从天上掉下来,除非像 Rails 这样强大的框架吸引他们。对于欣赏美丽、可读代码的开发人员来说,它就像一块磁铁。Ruby 首先是人类语言,其次是计算机语言。

根据我的经验,优秀的开发人员有兴趣快速交付精心设计的解决方案。从那里,他们寻求现实世界使用的反馈,并希望快速迭代改进。

从第一个版本开始,这种心态就已经融入到 Ruby on Rails 的精神之中。作为 Rails 开发人员,我们的目标是获得极高的生产力。我们想要运送东西。快速地。

根据Hired 的 2023 年软件工程状况报告,Ruby on Rails 是最受欢迎的编码技能

小团队,大胜利
因此,就像乐队可能拥有核心成员但会引入更多音乐家进行巡演一样,Rails 使小型团队能够灵活地扩展其资源。你可以从小事做起,在车库里进行三人即兴表演,但仍然可以创作出极其丰富和复杂的作品。可以这么说,当“继续巡演”的时候,您可以轻松引入额外的人才,而无需改变整个设置。

DHH 将 Rails 描述为“一人框架”

对大重写说不
Rails 提供了一种结构化的升级和维护方式。告别重写,迎接迭代改进。

如果你有一个工程师团队试图让你相信“Rails 已经过时了”,而唯一明智的解决方案是在一个热门的新框架中重写所有内容。然后说:哥儿们,让我们谈谈?

创新而不破坏东西
Rails 让您可以玩最新的玩具,而不会损坏旧的玩具。它的架构允许创新,而无需引爆现有代码。

通常,我们在升级时面临的挑战是我们捆绑的外部依赖项,以帮助我们更快地交付东西。有时,我们需要重新审视这些决策和/或升级和/或迁移这些构建块。

然而,除了一些小的语法更改之外,大多数核心 Ruby 和 Rails 代码很少需要更改。

依赖服务器端渲染
将所有内容都塞进客户端框架的趋势很可爱,但 Rails 通过服务器端渲染保持了优雅。有时候,旧的方式不仅旧,而且旧。他们是金子。

JavaScript 社区中的许多人现在正在“发明”一种常见模式,Web已经提供了近 30 年。

我对他们说:“欢迎(回到)参加聚会!”

强大的API能力
不要被愚弄了——Rails 不仅仅是漂亮的网页。它也是 API 的有力竞争者。内置 RESTful 设计,因此您的后端几乎是一把瑞士军刀。

我们很少遇到这样的争论:Ruby on Rails 至少不是构建和公开 API 的最佳平台之一。

活动记录魔法
Rails 中的 Active Record 就像一根编码魔杖 — 非常神奇,但也有一些怪癖。它简化了数据库交互,让您几乎不记得 SQL 是什么。

Martin Fowler在他的《企业应用程序架构模式》一书中介绍了软件设计模式。DHH 将其用作 Ruby on Rails 的基础构建块之一。

当我第一次接触 Ruby on Rails 时,我立即爱上了 Active Record。它破坏了我们,Rails 开发者。就像,“嘿,让我们假装 SQL 不是一个东西,只需使用 Ruby 对象来完成所有事情。” 它弥补了 SQL 数据库和 Ruby 面向对象编程之间的差距。

因此,您身处 OOP 天堂,但在幕后,它仍然使用良好的 ol' SQL。这可以保持稳定和高性能。相信我,SQL 就像一位可靠的朋友,您虽然不常见到,但知道它始终在您身边。

这是一个杀手级组合,因为您可以用 Ruby 进行思考,但可以从 SQL 的悠久历史中受益,您知道,它实际上擅长管理数据。

测试能力
Rails 不相信危险的生活,至少在代码方面不相信。

在 Rails 中,我们使用 MiniTest、RSpec 以及最近的 Cypress 来实现端到端的魅力。明白这一点:Rails 基本上是你过于热心的朋友,他为会议带来了额外的笔。当您使用其内置生成器时,它会为您生成模板化测试文件。现在逃避测试的借口为零!

对于那些在家评分的人来说,不成文的法则(好吧,也许它写在某处)是目标是应用程序中的测试覆盖率达到 80% 左右。

可扩展性
哦,古老的争论:“Rails 可以扩展吗?” 让我向您介绍我们的老朋友 GitHub 和 Shopify。您可能听说过它们;他们是一件大事。两者都是庞然大物,证明了 Rails 不仅可以步行,还可以在马拉松比赛中跑步和冲刺。

但让我们面对现实吧。并不是每个人都需要成为下一个 GitHub。对于许多 B2B 和 B2C 平台,您不必担心数百万用户。您正在查看数百个,甚至可能是数十个。你知道吗?Rails 为您提供支持。

我们曾与使用自定义 Rails 应用程序来管理其业务运营的“更复杂”方面的客户合作。最酷的是 Rails 可以让您像疯狂科学家一样进行实验。新的工作流程?简单的。一个支点?来吧!

因此,无论您是想征服宇宙,还是想改善 Larry 的生活,Rails 都可以根据您的戏剧性进行扩展——或者缺乏戏剧性。


Ruby 的乐趣
Ruby 之于编程就像诗歌之于文学。该语言可让您像写十四行诗一样清晰地表达复杂的业务逻辑。它富有表现力和直观性,是一个梦想的组合。

我们不仅仅是编码猴子;我们是工匠。起名好不好?这是我们的面包和黄油。我们也赞成金发姑娘的文档方法——不要太多,也不要太少,但恰到好处。

毕竟,我们是为人类而不是编译器编写的,而且我们知道这段代码将来会引起一些关注。那么,为什么不让它可读呢?

伙计们,让我们言出必行,言出必行。

如果没有 Ruby,Rails 永远不会被编写出来。

结束语
那么,Rails 的鼎盛时期已经过去了吗?再想一想。2024 年的 Rails 是一个成熟、现代且充满魔力的生态系统。

网友评论:
1、在日本Rails随处可见,它是日语文档、教程等最多的编程语言。

2、我想在当地的一些公司/工作中使用 RoR,因此我计划专门针对它们进行研究。
它仍然存在,只是不像 10 年前那样流行或广泛,当时很多训练营都在教授它,很多初创公司都在使用它……

  • Node已经接管了。
  • Python 现在在训练营和大学中更受欢迎,因此 Flask/Django 很有意义。
  • Java 总是很强大,
  • 而 .NET 正试图通过其最新版本进行更广泛的卷土重来。可能至少比 php 更好用,即使不是那么广泛。

3、根据我的经验,基本上存在三个主要的生态系统:JVM、微软、“开放”。
对于 JVM 和 Microsoft,每个人都使用相同的 1-2 种框架和 2-3 种语言的某种组合。MS 堆栈也意味着相同的网络服务器、数据库等。
“开放”可以是其他一切的任意组合。

我会将 Go 添加到这个列表中,尤其是在 Java 通常很强大的环境中和/或在 K8s 世界中。
Go 的好处是,仅使用 stdlib 就可以实现 90% 的目标。并不真正需要 Rails 的等价物。

4、phoenix、laravel、django 都可以比 Rails 更快地开发应用程序

5、使用 Ruby on Rails 是蓬勃发展的惊人数量的初创公司。他们执行速度极快、根据客户反馈进行迭代,有时甚至是进行调整。

6、我拥有与 Rails 团队合作的经验,复杂且糟糕。
早期构建的大型 Rails 代码库非常混乱。大量的补丁、自动加载和魔法以及类型的缺乏使得在大型代码库上工作真的非常痛苦。
我已经从 python 2 -> 3 迭代迁移了大量 django 代码库,甚至还致力于添加类型提示和严格的类型检查。
这并不像从 Rails 5.0 升级到 7 那么困难

我确信 Rails 对于小型团队和原型设计来说是非​​常高效的,因为它包含的能力甚至比 django 还要多,但我发现在大型项目中使用它是一个巨大的痛苦。

根据我的经验,搞砸 Rails 项目比搞砸 Python 项目要容易得多。

但我确信 Rails 有一席之地。ruby/rails 有很多空缺,但它肯定在下降。

大公司继续使用 Java 和 C# 等久经考验的东西,而大多数初创公司则选择 python 或 JS 或 go 后端