不言而喻，Rails是最大赢家

接受现实

现实情况是：Rails是为编写Basecamp而量身定做的。

我 们都知道，也应该知道。像Basecamp一类的程序是很难编写的，至少就架构来说。你没有必要幻想着性能优异的语言具有极其出色的并行性和并行原语。还 有一个现实是百分之八十的网络程序是类似Basecamp的。（解密：这是我多年来从事咨询工作的体会）。这就是Rails如此持久的原因之一。

就 像内容管理系统（ＣＭＳ），绝大多数都是博客一类的系统。基于此，你应当继续安装Wordpress。针对Rails的争论对于Wordpress也同样 进行着。你绝不能把Wordpress调整成其它的任何东西，它就是一个博客一类的系统。试着将它用于电子商务来应对高流量访问，你会很痛苦。

我很清楚：Wordpress是我曾经见过的最糟糕的源代码之一。可恶的是还必须维护其代码库。如果Wordpress代码的某位贡献者读到的话，我感到很抱歉，我这样说并没有什么恶意。你知道吗？可能世界上半数的ＣＭＳ，超过百万的网站都在使用Wordpress。

接着再来看Magento2这个案例。它对Magento第一版进行了大量重写，使用了大家都不喜欢的所有的可怕的Zend的资料。但这是大量的。如果你需要一个快速的“一站式”解决方案用于电子商务的话，那就再看看吧。

Wordpress插件要和Magento一起使用吗？不是的。他们是两个各自独立的社区。但他们都取得了很多收益，其中涵盖了他们裁员所需的花费，甚至没有把Drupal和Joomla计算在内。PHP是一个巨大海洋中的与世隔绝的小岛。那些国家有着严格的移民法律。

在 javascript的世界里，分片并不奇怪。但它拥有不同的价值创造。在快速发展的２１世纪里，Facebook、Google和Microsoft都 想成为思想领导者。那是长期的战略。其中的一个元素就是浏览器。但这不仅在于Chrom、Firefox和IE之间的较量，而且还在于程序是如何实现的。
 

Facebook推出了React。Google提出了Polymer和Angular。Node和Joyent之间进行过一次权力斗争，几乎导致了他们之间的进一步分裂，但他们还是创建了Node基金会。
 

Apple一直反对 Adobe公司的Flash，Google在Chrome中也关闭了Flash的使用，他们失去了在网络开发社区中的被关注度。
 

Apple 想要native取得成功，想让Swift成为统领一切的语言。Google采取的战略却有些混乱，因为他们想要native 即时应用获得成功，但是如果失败，继续执行B计划，以便占领基于HTML5/CSS3的Angular网络应用市场。Facebook不愿让自己的命运由 Apple和Google之间的权力斗争所决定。
 

那是一场复杂的不断变化的权力斗争，很显然这场斗争并非围绕着技术权利，也不是有关价值创造，而是围绕着自负、影响力和权利。这是一个非常适合YouTuber的时代。你是否已经注意到，网络技术在这场围攻中已经被绑架了。
 

问 题是Ruby的未来和Rails是紧密联系在一起的。这是现实，如果你是一个不喜欢Rails的Ruby开发者，我感到在伤害你。但是，远不止这样。例 如，如果欣赏樱花很有趣，我相信至少有公司会进行投资。如果没有人使用，那就无所谓技术的优越性了。如果Rom.rb很棒，那有人就会使用它，否则又有什 么意义呢？为什么要创造一种没有人使用的技术奇迹呢？但是如果哪怕有一家公司使用Rails，那么无论它发生了什么或者DHH说过什么做过什 么，Rails依然有充分的理由继续前行。
 

“人们认为既然有些东西具有技术优越性，人们都应当盲从。但这不是市场运作的方式”。
 

像宇宙一样多的事件仍会继续进行着，我真的不想过多地担心Ruby是否和Rails紧密联系。没有了Rails，Ruby又能做什么呢？

所有的社区都面临着分裂。长时间保持凝聚力是非常困难和昂贵的。我认为实现了强有力监管的社区是Microsoft's .NET栈。这并非意味着没有外部的压力。Rails本身对老的ASP.NET到ASP.NET MVC都扮演了重要的有影响的角色。现在他们终于获得了Xamarin，并由.NET引导了对它们的控制，而在开源平台他们是不可能做到控制的。

Ruby on Rails 是我所见过的最有“凝聚力”的社区。Basecamp 的好处是不需要成千上万的开发者存在。一个有利可图的市场便已足够通过开源软件过程改 进框架。这就是为什么我总是问起工具或技术的历史和起源，以便让我决定在何处使用它们，这不仅仅是技术能力。

Rails 因为它没有在Apple，Facebook，Microsoft，Google 或其他任何委员会（顺便说一下，默认情况下，我从不相信委员会）之间玩弄政治。这些东西都依赖于Rails直接处理的内务。（那是因为社区中 有）Heroku，Github， New Relic，Shopify 和许多有才华的开发者（参与其中）。
 

 

3 市场需求定律

1. 在即成事实之后很容易进行过度的分析，十年以来，我可以很容易地回溯一条最佳路线，远离一切愚蠢的错误和阻碍，这不是说我很聪明，而是我现在能够像完“连点”游戏一样把那一些清晰可见的点给连起来（注：游戏中本来那些点是不可见的，现在都可见了，所以很轻松）。

2. 没有任何解决方案是完美的。如果说它是为了解决某个具体的问题，它就会受限于它的不完美。如果它是为了解决某个形式不断变化的情况下的问题，那它就更加不会完美了。

3. 你构建工具要么是因为你的核心业务需要它，要么是想拿它卖钱。前者相较于后者通常来说更合适一些，因为你是在迎合市场的需求。所以如果你不得不进行盲选，就选前者吧。

那 么，首先，我通常会更倾向于选择那些为解决具体问题而生的工具，这些工具，恰好也是那些需要用它们的人构建的。不然的话，鞋匠的儿子最后只有落得个光脚丫 子的下场。举个恰当的例子：如果我需要的话，绝对会用Angular，但是我绝对绝对不会把一个全新的业务单单的押注在它上面来靠它存活。为啥？因为谷歌 不需要它。谷歌连眼都没眨就放弃了 GWT，它也根本就没仔细考虑就决定用一种完全不兼容 Angular 1 的方式来构建 Angular 2，类似的例子不胜枚举。

其 次，我总是会对能够影响到技术命运的外部因素加以考虑。你可以想象一下，你花了不知到多少的时间用于为 Grunt 构建脚本，库，工具链，然后人们就说 了，Grunt 一点都不好，现在我们都用 Gulp 了，而且你会发现一堆技术上的原因，好，那你又开始花了不知道多少时间来构建那些曾经用于 Grunt 的东西 给 Gulp 用，突然，人们又找出一大堆理由来告诉你 Webpack 才是最佳选择，于是你又把一切重演了一遍。纯粹的 “造轮子失调症”。

这 明显就是泡沫而已，现在又是“郁金香开放时节”了，有太多有闲钱，有时间还有资源的玩家了(Facebook, Google, Apple, Microsoft, Mozilla, 等等)。这就是一个运行在公共场合的实验室。一批接一批的实验性作品被赶出来，而有些公司就盲目的在这里面进行选择，他们评判的标准就是一周卖的最好的那 个。

有 时候这种情况会使得人们觉得，垄断，如微软阵营的 ASP.NET 和 Ruby 阵营的 Rails 也不是件很坏的事。而且，的确，我在这里比较了 Rails 和 .NET，它们是最值得比较的两种技术栈。也可以和 Java 阵营的 Spring 派别进行比较，如果你记得历史的话，回到2002年，Spring 曾经一度像 Java 社区的 Rails，因为不满于官方 J2EE 技术栈极其的复杂度而崛起，然而随后 Spring 自己也变得和 J2EE 一样庞大无比了。

这是一个千年困境:

要么作为英雄而死，要么苟活到目睹自己被逼成恶棍。

Rails 为什么现在成了问题的所在呢？

就如我之前所说的，我同意 Solnic 指出的几乎每个技术问题。

Rails 的确是 David Hansson（DHH）的创作。DHH 是一个人，很自负，也有业务需要去运营。你不能期待任何人在任何时候都是合情合理的，尤其是当他把一个既是业务也是技术平台的东西从零开始搭建起来的时候。

当 最开始的时候，那些逃离 Java，.NET，PHP，甚至是 Python 的人进到 Rails 的家门，他们无不口称赞扬 Rails 相较于 J2EE，ASP.NET 或 Plone 是多么的有意思。她不仅提供了生产力，还带给人技术上的愉悦。我们那时讨论的都是关于令人无限向往的动态语言的世界，开放式的类，注入操作变得异常简单 （也即 monkey patching），我们那时都通通起立，为要丢弃所有那些无意义的抽象层而鼓掌。

我们那时对 Ruby 式修补真的是爱爱爱不够，拆分出所有 类Perl 的魔法小玩意我们就能够在一门语言里面做到即不像 PHP 代码那样丑陋，又不像 Java 或者 C# 那样充满了浓浓的官僚主义气息，那时所有人都满意的笑了。

2004 年到 2006 年是一个永不停歇的用各种 “超凡入圣的” 类Perl 技法来折腾和庆祝式的{敏感词}的黄金纪年。我们那时通过 Why, the Lucky Stiff 学到了最多的是晦涩难懂的黑魔法，还记得吗？那书里面囊括了除开整洁干净的模块化架构以外的一切东西。

2007 到2011年前后，我们进入了白银时代。实际上Rails走的很远也很快，突然间，我们看到了大公司如雨后春笋一样的出 现！Twitter，Github，Engine Yard，Heroku，Zendesk，Airbnb，谁都陶醉于Rails。这个机会给予了企业新的东西。Merb在时间上领先于Rails，但定位 错了方向。我确实认为，面对强大的Rails，它在这点上面并不明智，你应该希望它反应过度，等这个到来后迅速的给它一击。说实话，在2009、 2010的时候，我有点担心Rails 3的pseudo-rewrite，pseudo-Merb-merge是否能挺过来。

2011到2016是青铜时代，是一个苦乐参半的时期。这期间有很多新语言发布，并最终达到了“稳定“状态。从JS的V8引擎到Node.js， 到Rust，Clojure，Elixir，甚至有些优秀的语言在从发布前就获得关注，像Scala，Haskell。其中最为重要的是2010年期间封 闭花园之称的App Store(the Walled Garden App Store)的出现，商业化的商店，提供运行在智能手机和平板电脑上的应用程序，它让人忘记了WEB开发，因为APP正在征服一切！

同时这是所有大公司开始展示他们成果的时候，Apple发布了Swift；Google发布了Dart，Angular， Go。 Microsoft发布了Typescript，ASP.NET MVC，然后vNext，及其Windows 10上相关的产品。Facebook进入了游戏领域后发布了React，及React Native。

Rails现在也可以算是一个“问题”，因为关于它起初流行的所有解释都几近相同，这点也注定会在其他技术上发生。

但你不能改变Rails的架构太多，否则生产环境的代码将面临大部分被破坏的风险。同时当某人必须重写大块项目代码的时候，你同样要考虑其他所有地方是不是也要重写。
 

许 多人做得都很到位，尤其是那些专门为 web 应用程序做的 API 实现（涉及 SPA 的 API）。这些 API 可以被写成 Go，Elixir，Scala 用来完全避免 Ruby。这样你就可以与快速发展的 Rails 生态系统失之交臂，但是如果你可以负担得起（你是独角兽，你财大气粗），那又为什么不呢？

但 那又怎样，90%的小到中等项目还是在那，那样的你也可以得到最好的工具，因为使用 Rails 所有它的库就都是可用的。这就像说，如果你想要建立一个博客，去Wordpress，你会得到最好最有用的资源。不用太花哨，写一个 SPA 博客使用就到了 Go 的 API，还使用到了 React ，且从头开始。这确实是可行的，但不值得这么做。

如果你有一个中等大小的公司，在一样的时间已经使用了 Rails，首先就会确保你遵守基本的最佳实践。如果你还没有准备好添加测试和参数。那么不断重构代码，移除重复，用gem升级。之后，你还应该考虑添加一个抽象层，例如 Trailblazer，可能还会考虑组合部分零件，让你的应用作为 Rails 的引擎 ，如果有可能，你也可以在 Rails-API 中移除这些零件，把它们从你的应用中分离出去。但是，这些都需要一步一个脚印。

最不利的就是做一个大爆炸式的从头再来。

总结

是的，如Solnic这样的开发者认为Rails社区可能是一个令人沮丧的地方。但是这是让人沉浸的，很难下降的社区，因为Rails社区是如此大，超过其他竞争者的华丽新平台，在那些地方你会感觉是一个不被看好的失败者。

Rails 在不被看好中维持了5年。而现在，它可能是有史以来增长最快的web框架。web开发人员在1995年到2003年的生活是不那么有趣的。Rails为此 做了很多改进。如果有人认为他们可以做得更好，也可以这样做。Rails的重点是什么？不仅仅是代码的竞争，也是结果的对抗。

Active Record 架构在10%的情况下会伤害到硬件。Active Support 到目前为止都没有更好的选择，删除它不会为最终用户带来任何有价值的东西。更换一个大组件， Active Record 等一些“更好”地如 DataMapper 这样的一个改良版本或 Rom.rb 作为默认，不会带来太多价值，尤其是有成百的应用的时候。你告诉每个人，要重写这一切。如果我必须重写，我一定会做一个使用 Rails + Trailblazer 的新应用，或者直奔 Hanami 。不过还是会有许多人会决定完全放弃 Ruby 的。  

运 行记录会变得更好？是的！我们那些老的数据映射器（Data Mapper），Sequel和ROM.rb都可以证明。但真正的问题是：它在2004年第一次被创造出来的时候，它能不能做得更好？我不这样认为。现 在，DataMapper的创造者都在为No-ORM造势。在2004年的时候，“NoSQL”还不成形。回到当时，我们最好的选择是 Hibernate，之前是JPA！针对所有意图和目的，Active Record还只是平均水平。当时如果你的项目很大，你应该很小心。仅此而已。

Rails 社区面对的问题也是其他社区面临的问题，这是不可避免的。当有一个小社区，这会容易得多，即使打破它也不会太坏。（因为）很难维持的东西实际上大大超出了你所乐观（认为）的场景。

我 也理解那种保守的方法DHH，它可以避免大的中断。如果他所做的这些东西是因为他相信保守的动作或者是因为他不了解更好的架构选择，这些不都是由我来判断 的，而是这一有效的行为使得高级的开发者们疏远（它们），就像Solnic仍让初学者直接进入，也不用担心太多的抽象。

人 们忘记了对于高级开发者来说抽象是很美妙的。但是初学者总是在选择之前面临着太多架构的选择。理解GoF设计模式（GoF Design Patterns），数据驱动设计（Data-Driven Design），SOLID，企业架构（Enterprise Architectures）等等，这是一种淹没式的感受。有经验的人常常忘记当自己还是初学者时的学习曲线，当时Rails是那么地有吸引力，如此性 感。还记得那种感受吗？面对知识的成就感是不是就像一群漂亮的女巫留下了超级有用的黑色魔法那样？

Rails已经赢得了初学者，这就像有一个类似“rails”经验的人在指导一样，并且很多高级开发者更易于接受这种轻度的灵活性。你的项目还能再保持另外一个10年吗，面临许多小的替代方案的时候，是不是可以试图重建一切，从头开始呢？时间将会证明一切。

我认为用Bob Dylan的话作为结语是一个很好的主意：

大家聚集在一起 “如果你的时间对你来说还值得节约的话，不管你现在身在何处闲逛，你都要承认你周围漫起来的水，承认水来得是那么地凶猛，连骨头都要被浸透”。然后你最好开始游泳，要不然“在这个急剧变革的时代你就会像石头那样下沉。”......