击关注 InfoQ，置顶公众号

接收程序员的技术早餐

嘉宾｜桑世龙

编辑｜覃云

2009 年，Node.js 横空出世，在几年时间里，Node.js 凭借其高性能、易部署等特点迅速在前端领域脱颖而出，成为大火的明星。但一个技术再好，也是有生命周期的，许多开发者开始质疑，Node.js 是不是在走下坡路了？Node.js 是不是越来越不吃香了？

为此，InfoQ 采访了阿里巴巴前端技术专家、Node 技术传道者桑世龙（狼叔），为大家解答关于 Node 的问题，以及开发者在日新月异的技术迭代环境中应该如何建立起自己的“大局观”。以下是采访的全部内容。

友情提示：在即将到来的 2018 年 GMTC 大会上，狼叔将担任 Node 专场的出品人，喜欢狼叔和对 Node 有兴趣的读者千万别错过。

Node 为解决后端并发而生，但却无心插柳，成为大前端的基石。伴随大前端的发展，Node 也发展得越来越好，越来越重要，其应用场景从脚手架、辅助前端开发（比如 SSR、PWA 等）的快速开发实践，到 API 中间层、代理层，到专业的后端开发都有非常成熟的经验。另外，前端越来越复杂，后端服务化，今日的前端要面临更多的挑战，Node 全栈给大家更多可能，狼叔对此坚定不移。

1 2017 年，Node 的日子好过吗？

狼叔主要从以下四个方面介绍了 2017 年 Node 发生的变化：

• a）Node 8 进入 LTS 时代

• b）企业级 Web 开发

• c）不可不见的 Api 中间层

• d）新领域（深度学习、区块链等）

a）Node 8 进入 LTS 时代

2017 年，Node.js 最大的变化是进入 Node 8 时代，它是一个稳定的长期支持版本（LTS），除了性能提升外，还有以下几个要点。

• Async/Await 支持。其实在 Node.js v7.6 就可以通过 flag 支持了，在 node8 里直接落地。通过 Async 函数可以更好的进行异步流程控制，远离 Callback Hell。在 Async 函数里，你可以通过 await 调用 Promise，以及通过 co 包裹的 generator，可以说，向前是完美的 Async 函数，向后也完美兼容各种遗留代码，称为异步终极解决方案不为过。

• ES6 模块支持。通过 vue/react、webpack、babel 和 typescript 等火爆发展，es6 模块得到了广泛普及和应用，在 Node.js v8.5 可以通过 --experimental-modules 来开启这个体验版特性。当然，你想在 Node.js 更早版本里使用 ES6 模块，可以采用 @std/esm 模块。

• HTTP2 支持。在 Node.js v8.8 就开始默认启用了，http2 对服务器端推送，多通道复用等特性，能够更好地为浏览器便利，是性能优化的利器。

Node v9.9 对 ES2018 支持是 75%，在 Node v10 里支持是 100%，还是非常值得期待的，更多信息参见 http://node.green/#ES2018。

b）企业级 Web 开发

基础框架除了应用最广泛的主流 Web 框架 Koa 外，Fastify 也是一直劲敌，作者 Matteo Collina 是 Node.js 核心开发，Stream 掌门，性能优化专家。Fastify 基于 Schema 优化，对性能提升极其明显。狼叔认为这是企业级 Web 开发，他在这里给我们介绍了 3 个知名框架。

b1）Egg.js

阿里开源的企业级 Node.js 框架 Egg 发布 2.0，基于 Koa 2.x，异步解决方案直接基于 Async Function。框架层优化不含 Node 8 带来的提升外，带来 30% 左右的性能提升。

Egg 采用的是 『微内核 + 插件 + 上层框架』 模式，对于定制，生态，快速开发有明显提升，另外值得关注的是稳定性和安全上，也是极为出色的。

b2）Nest

Nest 是基于 TypeScript 和 Express 的企业级 Web 框架。

很多人开玩笑说，Nest 是最像 Java 开发方式的，确实，Nest 采用 TypeScript 作为底层语言，TypeScript 是 ES6 超集，对类型支持，面向对象，Decorator（类似于 Java 里注解 Annotation）等支持。在写法上，保持 Java 开发者的习惯，能够吸引更多人快速上手。

TypeScript 支持几乎是目前所有 Node Web 框架都要做的头等大事，在 2017 年 Nest 算首个知名项目，值得一提。

b3）ThinkJS

ThinkJS 是一款拥抱未来的 Node.js Web 框架，致力于集成项目最佳实践，规范项目让企业级团队开发变得更加简单，更加高效。秉承简洁易用的设计原则，在保持出色的性能和至简的代码同时，注重开发体验和易用性，为 WEB 应用开发提供强有力的支持。

ThinkJS 是国产老牌 Web 框架，在 2017 年 10 月发布 v3 版本，基于 Koa 内核，在性能和开发体验上有更好的提升。

整体来看，Node.js 在企业 Web 开发领域日渐成熟，无论微服务，还是 Api 中间层都得到了非常好的落地。2017 年，唯一遗憾的是 Node.js 在 servless 上表现的不太好，相关框架实践偏少。

c）不可不见的 Api 中间层

前端越来越复杂，后端服务化，今日的前端要面临更多的挑战。一个典型的场景就是在服务化架构里，前端面临的最头痛的问题是异构 API，前后端联调的时候，多个后端互相推诿，要么拖慢上线进度，要么让前端性能变得极其慢。进度慢找前端，性能差也找前端，但这个锅真的该前端来背么？

Node.js 的 Api 中间层应用很好地解决了这个问题。后端不想改的时候，实在不行就前端自己做，更灵活，更能应变。

• 透传接口，对于内网或者非安全接口，可以采用中间层透传。

• 聚合接口，对异构 API 处理非常方便，如果能够梳理 model，应变更容易。

• Mock 接口，通过 Mock 接口，提供前端开发效率，对流程优化效果极其明显，比如去哪儿开发的 yapi 就是专门解决这个问题的。

除此之外，前端如果想做一些技术驱动的事儿，SSR（服务器端渲染）和 PWA（渐进式 Web 应用）也是非常不错的选择。

d）新领域（深度学习、区块链等）

• 深度学习，https://github.com/PAIR-code/deeplearnjs

• 神经网络，https://github.com/BrainJS/brain.js

• 区块链，http://truffleframework.com/

狼叔说他这部分接触得不多，不过从这些开源项目可以看到有很多开发者热衷于使用 Node.js 做开发创新，这是非常值得高兴的。

2 如何将 Node 的价值发挥到极致？

狼叔说过，“不是 Node 不行，而是你不会用”，他认为很多人对 Node.js 有很多误解，从 2009 年诞生到现在，Node.js 的改变进化是非常明显的，甚至说是有了质的变化。

• 比如 Callback hell，现在可以通过 Async 函数解决。

• 比如作为过渡技术栈的 thunk 函数和 generator，慢慢的消失在历史舞台。

• 比如 node 是单进程非常脆弱，但是你真的部署对了么？

• 比如数据库事务问题，这是 node 的锅么？你用 mongodb 玩不好，也要赖到 node 身上么？

一般，后端开发指的是 Web应用开发中和视图渲染无关的部分，但现在架构升级，Node承担了前后端分离重任之后，有了更多玩法。从带视图的传统Web 应用和面向 Api 接口应用，到通过RPC调用封装对数据库的操作，到提供前端Api代理和网关，服务组装等，统称为后端开发，不再是以往只有和数据库打交道的部分才算后端，这样，就可以让前端工程师对开发过程可控，更好的进行调优和性能优化。

对 Node.js 来说，一直没有在后端取得其合理的占有率。原因很简单：

• 1）利益分配，已有实现大多是 Java 或者其他语言，基本是没法撼动的，重写的成本是巨大的，另外，如果用 Node 写了，那么那些写 Java 的人怎么办？抢人饭碗，这是要拼命的。

• 2）Node 相对年轻，大家对 Node 的理解不够，回调和异步流程控制略麻烦，很多架构师都不愿意花时间去学习。尽管在 Web 应用部分处理起来非常简单高效，但在遇到问题时并不容易排查定位，对开发者水平要求略高。

• 3）开发者技能单一，很多是从前端转过来的，对数据库，架构方面知识欠缺，对系统设计也知之不多，这是很危险的，有种麻杆打狼两头害怕的感觉。

• 4）Node 在科普、培训、布道等方面做的并不好，国外使用的非常多，国内却很少人知道，不如某些语言做得好。

纵览 2017 年 Node.js 的发展路程，作为一个亲历者，他觉得 Node 在 4 个方面表现得极为突出：

• 前端实践，脚手架，工程化，快速开发；

• API Proxy 中间层实践，页面即服务概念；

• 面向企业开发的 Web 框架；

• Node 最新技术与性能调优。

狼叔希望更多的 Node.js 开发者能够参与其中，本次 GMTC 大会也会围绕这写主题进行 topic 筛选，希望能够为国内 Node.js 的繁荣做出一点贡献。

3 如何选择适合自己的 Node 框架？

开发者在面对如此多的 Node 框架时，总会眼花缭乱，不知道是该从众还是应当选择自己擅长的框架，对此，狼叔是这么说的。

Web 应用大致分 2 种，带视图的 传统 Web 应用和面向 Api 接口应用，而 Node.js Web 应用开发框架的演进时间线大致如下：

• 2010 年 TJ Holowaychuk 写的 Express。

• 2011 年 Derby.js 开始开发，8 月 5 日，WalmartLabs 的一位成员 Eran Hammer 提交了 Hapi 的第一次 git 记录。Hapi 原本是 Postmile 的一部分，并且最开始是基于 Express 构建的。后来它发展成自己自己的框架。

• 2012 年 1 月 21 日，专注于 Rest api 的 Restify 发布 1.0 版本，同构的 Meteor 开始投入开发，最像 Rails 的 Sails 也开始了开发。

• 2013 年 TJ Holowaychuk 开始玩 es6 generator，编写 co这个 Generator 执行器，并开始了 Koa 项目。2013 年下半年李成银开始 ThinkJS，参考 ThinkPHP。

• 2014 年 4 月 9 日，Express 发布 4.0，进入 4.x 时代持续到今天，MEAN.js 开始随着 MEAN 架构的提出开始开发，意图大一统，另外 Total.js 开始起步，最像 PHP 里 Laravel 或 Python 里的 Django 或 ASP.NET MVC 的框架，代表着 Node.js 的成熟，开始从其他语言里的成熟框架借鉴。

• 2015 年 8 月 22 日，下一代 Web 框架 Koa 发布 1.0，可以在 Node.js v0.12 下面，通过co和 generator 实现同步逻辑，那时候co还是基于thunkfy的，在 2015 年 10 月 30 日，ThinkJS 发布了首个基于 Es2015+ 特性开发的 v2.0 版本。

• 2016 年 09 月，蚂蚁金服的 Eggjs，在 JSConf China 2016 上亮相并宣布开源。

• 2017 年 2 月，下一代 Web 框架 Koa 发布 v2.0 正式版。

• 2017 年 10 月，ThinkJS v3 发布，基于 Koa 内核。

• 2017 年 12 月，阿里巴巴开源 Egg.js v1，采用的是 『微内核 + 插件 + 上层框架』 模式。

• 2018 年 3 月，阿里巴巴开源 Egg.js v2，全面支持 async 函数，性能提升 30% 以上。

我们根据框架的特性进行分类：

对于框架选型

• 业务场景、特点，不必为了什么而什么，避免本末倒置；

• 自身团队能力、喜好，有时候技术选型决定团队氛围的，需要平衡激进与稳定；

• 出现问题的时候，有人能够做到源码级定制。Node.js 已经有 8 年历史，但模块完善程度良莠不齐，如果不慎踩到一个坑里，需要团队在无外力的情况能够搞定，否则会影响进度。

个人学习求新，企业架构求稳，无非喜好与场景而已。

Node.js 本来就为了做后端而设计的，这里我们再看看利益问题。Node.js 向后端延伸，必然会触动后端开发的利益。那么 Proxy 层的事儿，前后端矛盾的交界处，后端不想变，前端又求变，那么长此以往，Api 接口会变得越来越恶心。后端是愿意把 Api 的事儿叫前端的，对后端来说，只要你不动我的数据库和服务就可以。

但是 Node.js 能不能做这部分呢？答案是能的，这个是和 Java、PHP 类似的，一般是和数据库连接到一起，处理带有业务逻辑的。目前国内大部分都是以 Java、PHP 等为主，所以要想吃到这部分并不容易。

• 小公司，创业公司，新孵化的项目更倾向于 Node.js ，简单，快速，高效；

• 微服务架构下的某些服务，使用 Node.js 开发，是比较合理的。

国内这部分一直没有做的很好，所以 Node.js 在大公司还没有很好的被应用，安全问题、生态问题、历史遗留问题等，还有很多人对 Node.js 的误解。

• 单线程很脆弱，这是事实，但单线程不等于不能多核并发，而且你还有集群呢！

• 运维，其实很简单，比其他语言之简单，日志采集、监控也非常简单。

• 模块稳定性，对于 MongoDB、MySQL、Redis等还是相当不错，但其他的数据库支持可能没那么好。

• 安全问题是个伪命题，所有框架面临的都是一样的。

这些对于提供 Api 服务来说已经足够了。

对于企业 Web 开发来说，更重视稳定性和安全性，通过约定开发方式，提供高效开发效率。目前 Egg、Thinkjs、Nest 这方面是先行者，想必开发者对它们都已经非常熟悉了，可以放心使用。

4 “向前看” or “向钱看”？

生活无非是迷茫的和目标清晰的。迷茫的人想找到目标是非常曲折的一个过程，所以最简单的办法就是“向钱看”，市场作为检验技术流行程度的一个标准。没有目标，那就多学点能赚钱的技能。

很多人度过了迷茫期，这时候就需要“向前看”，知道自己想要什么，只能自己该做什么，有自驱能力，这时候更多的是看清趋势，在变化中总能做对事情，除了做好的分内之事外，无论业务还是技术发展都需要对发展走势做出正确的判断。

对于 Node.js 开发者来说，

1）“向钱看”：学会，能用，如果学会 Node.js 不能在收入或者潜在收入有提升，那也没啥意思。

Node.js 编写的包管理器 npm 已成为开源包管理了领域最好的生态，直接到 2017 年 10 月份，有模块超过 47 万，每周下载量超过 32 亿次，每个月有超过 700 万开发者使用 npm。现在早已经超过 60 万个模块了。在此，狼叔举了一个例子，他说曾有开发者向他讨教调整状态的办法，而狼叔的建议是，让他每天看 10 个 npm 模块。

狼叔认为，对于学习 Node.js 迷茫的人来说，这是最好的方式，当你不知道如何做的时候，就要向前（钱）看，你要知道积累哪些技能对以后有好处。对于学习 Node.js 必经之路，一定是要掌握很多模块用法，并从中汲取技巧、思路、设计思想的。与其不知道学什么，为什么不每天积累几个技巧呢？

2）“向前看”：用好，创造更多价值。各家公司都有 KPI，怎么能够通过 Node 快速达成自己的 KPI 是非常重要的。

• a）遇到各种问题，解决不了，能不能用 node？

• b）技术驱动，能不能在 node 层做一些创新？

• c）提高开发效率，能否让团队用好 node，梳理出工程化最佳时间。

• d) 在遇到性能瓶颈的时候，node 能否解决这些问题。

对此，狼叔给出了他的招人标准：

• 基本的 Node.js 几个特性，比如事件驱动、非阻塞 I/O、Stream 等；

• 异步流程控制相关，Promise 是必问的；

• 掌握 1 种以上 Web 框架，比如 Express、Koa、Thinkjs、Restfy、Hapi 等，会问遇到过哪些问题、以及前端优化等常识；

• 数据库相关，尤其是 SQL、缓存、Mongodb 等；

• 对于常见 Node.js 模块、工具的使用，观察一个人是否爱学习、折腾；

• 是否熟悉 linux，是否独立部署过服务器，加分项；

• js 语法和 es6、es7，延伸 CoffeeScript、TypeScript 等，看看你是否关注新技术，加分项；

• 对前端是否了解，加分项；

• 是否参与过或写过开源项目、技术博客，加分项。

“向前看”不是简单在一个领域内钻研，而是能够在精通一门之后，扩展广度，提高自身的解决问题能力。当然，如果能够在架构层面去思考问题，那就更完美了，对未来职业发展有无限好处。

5 “专注” or “技多不压身”？

狼叔对自己的定位是专注于 Node.js 技术，如果没法做更多 Node.js 相关的内容，不如就离开，但这是不是意味着与“技多不压身”的观点相悖呢？对此，狼叔是这么解释的。

《Node.js in action》一书里说，Node.js 所针对的应用程序有一个专门的简称：DIRT。它表示数据密集型实时（data-intensive real-time）程序。因为 Node.js 自身在 I/O 上非常轻量，它善于将数据从一个管道混排或代理到另一个管道上，这能在处理大量请求时持有很多开放的连接，并且只占用一小部分内存。它的设计目标是保证响应能力，跟浏览器一样。

这话不假，但在今天来看，DIRT 还是范围小了。其实 DIRT 本质上说的 I/O 处理的都算，但随着大前端的发展，Node.js 已经不再只是 I/O 处理相关，而是更加的“Node”！

Node.js 使用场景主要分为 4 大类：

• 1）跨平台：覆盖你能想到的面向用户的所有平台，传统的 PC Web 端，以及 PC 客户端 nw.js/electron、移动端cordova、HTML5、react-native、weex，硬件http://ruff.io等。

• 2）Web 应用开发：网站、Api、RPC 服务等。

• 3）前端：三大框架 React \ Vue\Angular辅助开发，以及工程化演进过程（使用Gulp/Webpack 构建 Web 开发工具）。

• 4）工具：npm上各种工具模块，包括各种前端预编译、构建工具Grunt/Gulp、脚手架，命令行工具，各种奇技淫巧。

可以说目前大家能够看到的、用到的软件都有 Node.js 身影，当下最流行的软件写法也大都是基于 Node.js 的，比如 PC 客户端 luin/medis 采用 electron打包，写法采用 React + Redux。他一直实践的【Node 全栈】，也正是基于这种趋势而形成的。在未来，Node.js 的应用场景会更加的广泛，更多参见 sindresorhus/awesome-nodejs。

狼叔亲历了从 node 0.10 到 iojs，从 node4 到目前的 node9，也写了很多文章，参加很多技术大会，做过很多次演讲，有机会和业内更多高手交流的机会。当然他也从 qunar 到阿里经历了各种 node 应用场景，对于 node 的前景他是非常笃定的。正如上文所说，善于使用 node 有无数好处，如快速出成绩、性能调优、优化团队结构、人员招聘等诸多利好，让他坚定地守护 Node.js。

Node.js 目前的应用场景和招聘市场都是极大的，很多公司都使用 Node.js，阿里、腾讯、百度和去哪儿等，还有青岛的海尔集团这样的传统名企，video++、石墨文档这样的创业互联网公司，Node 产生的商业价值是无法估量的。

狼叔的定位是 Node 全栈，以大前端为主，Node 辅助，把所有和用户直接相关的开发囊括。他认为这是趋势，他也在自身的经历中体验到了好处。而大前端目前没有形成固定模式，还在混乱发展，所以前景是非常看好的。

但他认为“笃定 Node”和“技多不压身”的观点不冲突，一个前端领域已经足够复杂，如果是大前端涵盖得更广，可谓进可攻退可守。在这种背景下，Node 其实是增加自身附加值的。个人经历优先，无法覆盖更多，这样的定位也算是另外一种专注吧。

6 大局观：多思考、多折腾、多更新

“年轻时死磕，年长点让小弟死磕，现在抓个专家一起吃饭，没有什么是一顿饭解决不了的，不行就二顿”，这句话虽然是调侃，但也是实话，每个阶段做好每个阶段该做的事儿就好。有一句名言说的特别好，“高筑墙，广积粮，缓称王”。

• 年轻死磕是为了长本事，少抱怨，多思考，未来更美好。30 岁以前都可以这样做。

• 带团队后，要懂得任务下放，让更多人帮你，别带人越多越累。

• 30 岁之后是打牌阶段，技能积累足够用，这时要注重社交，打组合拳才能玩的更好。

大部分人都会认为 30 岁后事情，压力会明显大得多，比如家庭，孩子，房子，车子，票子，甚至是管理，权利，欲望等。对此，狼叔印象最深的是身体不如从前和记忆力明显下降。

拥有一个好的大局观，没有捷径，就是多折腾。以前看事情是点，现在看的是趋势，能够做到心中有数，自然胸有成竹的感觉。技术发展这么快，作为一个一把年纪的人，每天也需要适当的投入一点精力关注开源，需要不断的更新自己，才不会让自己的大局观过时。

PWA 技术在阿里体系内是如何实践及应用、腾讯基于 Cocos 改造 Hybrid 形式产品、腾讯顶级人工智能实验室的 AI 终端产品实践、微服务平台下基于 GraphQL 构建 BFF 的实践与思考、Vue 服务端渲染在快手直播中的应用...... 更多最新最热的大前端技术议题即将来袭。

GMTC2018 上，来自 Google、Facebook、BAT 等 60+ 国内外一线前端大牛，将与你面对面探讨大前端领域最新技术趋势和实践。扫描下方二维码或点击“阅读原文”解锁更多大会详情！

uby on Rails 的衰落是毋庸置疑的，而且今年以来的衰落速度比以往更快。

先看 Google Trends，虽然不太科学、但至少能说明一点问题。无论是 Ruby 还是 Ruby on Rails，多年来在 Google Trends 都处于一路走低的状态。

如上图所示，二者先是急剧上涨、然后是一路横盘。但从 2016 年开始明显下跌后，它们的命运就基本已经注定了。不知道为什么 2020 年这里又有一次断崖式下降，这可能只是 Google 数据出了问题。但不管怎么说，状态不好是肯定的。

十年前，极受追捧

Ruby 是一种用于面向对象编程的解释性脚本语言，核心优势就是允许开发者快速构建并启动应用程序。Ruby 语言本身采用大量英语单词，所以上手难度更低。但由于可扩展性不佳，Ruby 应用程序的运行速度往往不及其他语言。

这门编程语言由 Yukihiro Matsumoto 于 1993 年开始创建，于 1995 年正式发布。虽然和 Java 基本上可以算是同时期（Java 诞生于 1993 年，正式发布于 1995 年），但在 2004 年 David Heinemeier Hansson 发布 Ruby on Rails 之前，Ruby 一直非常小众。

Ruby on Rails （也简称为 Rails）是一个使用 Ruby 编程语言的开源 Web 应用程序框架，曾一度大受欢迎，Rails 的出现极大的推动了 Ruby 语言的发展。在 2004 年之后，Rails 社区贡献出了广泛的插件（Gems）、书籍（光 2006 年就有 10 本关于 Rails 的书籍问世）、培训、一个主要会议（RubyConf）等等。随着 Rails 风头正劲，甚至连最保守的公司都开始考虑采用 Ruby。

《From Java to Ruby》一书的作者 Bruce Tate，曾是一位 Java 程序员，在当时也变成了一名 Ruby 狂热分子，他曾在 2007 年提出一个“木马计（Trojan Horse）”的方法，让一些领路人在保守的公司里为 Ruby 树立威望：

• 先找到一个不那么令人兴奋的技术问题。
• 私底下使用 Ruby 解决此问题，尽可能在管理层发现不了的情况下工作。
• 创建一个草根阶级联盟，通过培养文化的方式培养 Ruby 布道者。

“实现一个试点项目，用这个策略来暗度陈仓，在眼皮底下把 Ruby 整合进系统。剩下的工作让 Ruby 完成就可以了。不过，为了建立你的试点项目，你首先需要创建一个案例，让 Ruby 看起来足够吸引眼球，从而让大家甘心冒这个风险。接着，你得在你的试点策略里面添筋加骨。鉴于人们对采用一门新语言与生俱来的抵抗力，你要选择一个不给疑虑留任何余地的方法。最终，你得愿意为成功建立制度根基。”

从 2000 年开始，到该时代中期，Ruby 受欢迎程度在 TIOBE 指数评级中逐渐达到顶峰，人们认为 Ruby 还有它的旗舰级 Rails 框架，可以大大提高生产力。不少现在的大型网站，比如 Twitter 和 Groupon 在当时都是这门框架的使用者之一。

只不过，人们也逐渐发现它存在一些致命缺陷。Groupon 工程师 Sean McCullough 在 2013 年的一个技术会议上讲道，“要在 Groupon.com 整个网页上更改一种颜色，估计需要三个月的时间。这导致我们无法以需要的速度进行迭代。”

Groupon 工程师不得不研究 Ruby on Rails 的一系列替代方案，最终选择了流行的 Node.js，并花了一年时间进行迁移。Groupon 还表示，更换之后页面加载速度得到了显著提升，高达 50%。从 2008 年引进，到 2013 年替换掉，Groupon 在这个坑里挣扎了 5 年。而在同一时期，备受扩展性问题困扰后，Twitter 也放弃了 Ruby on Rails。

现在，Ruby 确实不咋行了

接下来，让我们一起从课程、实践、社区情况来看看当年盛极一时的网红编程语言发展现状。

现在，很多朋友可能注意到，专门的 Ruby 播客或者新闻网站已经越来越少。除了一个每周通讯网站（?https://rubyweekly.com/?）还能保持高质量，其他的真就没什么了。

这就突出了 Ruby 语言正陷入恶性循环：因为缺乏好的信息和教程，新手开发者就不愿选择它；而因为没有足够的新人，市场对信息和教程的需求也随之减少。

因为在劳动力市场上不被看好，编码训练机构 Coding Dojo 决定从 2017 年开始将 Ruby 课程从全美六大学区内尽数撤下，同时增加 Java 的全栈开发课程。Coding Dojo 课程负责人 Speros Misirlakis 曾表示，“我们一直在关注各地市场、把握技术需求，并发现 Java 的人气位居榜首。相比之下，Ruby on Rails 在招聘热度、市场需求和开发者关注度等方面都远远落后。”

到现在，以 Udemy 为例，截至 2022 年 3 月，上面只有 109 种关于 Ruby（on Rails）的课程。但 Python、Java 和 JavaScript 等语言的课程量都超过 10000 种。目前质量最高的 Rails 课程之一最后公开更新是在 2020 年。当然，go-rails 等其他服务也在提供相关课程，但 Ruby 衰落的趋势已经非常明显。

十年前，Ruby 背后还有高度活跃的社区，比如 GitHub、热门 repo。现在情况也发生了变化，支持并使用 Ruby 的开发者越来越少，曾被经常提起的 gems 服务，现在基本属于无人问津。再举个典型的例子，Rails 的 Azure 支持。

对微软 Azure 的支持状态可谓一团糟。相关一部分成果无人维护，过去几年来也毫无动静。大量问题被提出之后就长期搁置。例如，Azure 官方库中有 22 个问题仍在开放，其中的依赖性问题大多源自 Nokogiri 库版本过老。我知道这例子有点极端，但它确实能反映出生存状态的一个侧面。

最近十年来，现代 SaaS 方案中的 API 几乎都不提供官方 Ruby 客户端或 SDK。

形成鲜明对比的是，Java、JavaScript、Python 甚至是 Rust 可都在支持之列。

Slack 没有官方的 Ruby 客户端或者 SDK（其他语言都有），Dropbox 也一样。之前提到过，Azure 倒是有，但基本没有维护。在所有 HubSpot API 实施意见中，Ruby 版本的人气（根据 stars 和 forks 判断）和更新频率都是最低的。像 Monday、Teamleader 或者 Notion 这样的现代项目管理方案都没提到过 Ruby。这里要澄清一下，我举的都是不支持 Ruby 的 SaaS 项目。支持 Ruby 的也不少，从 AWS 到 Square，都提供一流且维护良好的 gems 供用户选择。

虽然没对 Ruby gems、repo、待解决问题等量化指标做过数据分析，但单是浏览一下基本情况就已经看得出相当负面的趋势。而且从部分 SaaS 服务上看，Ruby 确实不太受待见。

2010 年时 Ruby 的 SDK 和 API 客户端都是最亮眼的，之所以出色，是因为当时的 API 与 SaaS 开发团队往往会自己动手编写 Ruby 版本，所以客户端质量自然不在一个层面上。但近年来情况大变，而相应的社区版本要么维护不善、要么压根没有。

关注大型 SaaS 或者软件公司，我们会发现运行在 Ruby（on Rails）上的成果基本都有点年头了。

特别是在 2020 年之后，已经很难找到任何立足 Rails 构建的成功 SaaS 产品。GitHub 诞生在 2008 年，Shopify 是 2006 年，Twitter 是 2006 年，Groupon 是 2008 年，Zendesk 是 2007 年，Airbnb 是 2008 年，Fiverr 则是 2010 年。我能想到的诞生于 2010 年之后、而且运行在 Ruby 或 Rails 上的成功厂商就只有 Stripe（2011 年）和 Gitlab（2014 年）。在比较流行的 Ruby 开源项目方面，我能想到的也只有 Discourse 和 Mastodon。但这里确实也有幸存者偏差的因素：成功的企业需要经历漫长的磨练才会显露，所以不管用不用 Rails，成功的 SaaS 都得用时间证明自己。

2010 年那会 Rails 的成功催生出使用模型视图控制器（MVC）架构建立快速应用开发（RAD）框架的市场需求。可以肯定地说，Rails 这类框架确实拥有比较明确的市场定位，但还不至于火到那个程度。这些架构的解决能力和适用范围都比较差，所以无论使用哪种语言，Rails 本身的流行度下降甚至在根源上来自 MVC 和 RAD 方法的逐渐衰落。

2021 年 StackOverflow 的调查结果也支持了这样的判断：Ruby 与 Rails 在各项评比中基本都处于象限底端。Ruby 得到的“赞”和“踩”基本相当。很遗憾，StackOverflow 并不提供可供访问的趋势指标，倒是有一款基于标签活动的独立工具。经过查阅，发现 Ruby 这几十年来持续下滑、而且身处底部象限。TIOBE 指数也给出了类似的结论，Ruby 稳定保持着每况愈下的生存状态，逐渐落后于其他语言。

请谨慎选择学习

虽然彻底消亡并不容易，就像 Pascal、COBOL 乃至 Perl 当下也仍然存在一样。Ruby 的情况要好一些，这艘船还远远没沉、只是速度越来越慢。

不过人气并不能直接决定语言的质量。毕竟如果用人气来衡量，那 IE 6 将是人类历史上最好的网络浏览器。Ruby 仍然保持着 2005 年时的出色开发体验，而且体验只会越来越好。Rails 也仍是实现原型设计演示的好方法，能帮助大家在几天之内更稳妥地构建起最小可行性产品。

那我们是不是不该在职业规划中学习 Ruby 或者 Rails？话可不能这么说。市场对于 Rails 和 Ruby 开发者的需求仍然相当旺盛，或者说市场对任何语言的开发者都需求旺盛。自 2008 年以来出现的一切 SaaS，在未来几十年中都需要新的开发者加入进来。

但我们也要考虑到，在 Ruby 陷入萎缩的同时，Node.js 开始快速流行。在过去的十年里，开发领域的创新成果可谓百花齐放。HTML5、Node.js、Angular 和 React 已经在前端和后端遍地开花。JavaScript 与 Python 在市场需求稳定性上也越来越具有优势。Python 是过去十年中增长速度最快的主流编程语言，目前已经扩展到 Web 开发、数据科学、科学编程等多个领域。Stack Overflow 的调查也显示出，JavaScript 已经成为全球应用最广泛的语言。

另一方面，很多技术都会有自然的生命周期。开发者们的关注和精力就那么多，流向了其他地方、自然也就不再流向这里。

所以这里还是想提醒大家，如果 Ruby 继续保持过去十年来的衰落趋势，那各位一定要认真考虑学习这门语言的风险——也许 Ruby 终有一天也会像 COBOL 或者 Perl 那样成为时代的眼泪。

参考链接：

https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/

https://www.infoq.cn/article/From-Java-to-Ruby--Strategies

https://www.datacenterknowledge.com/archives/2013/12/06/need-speed-groupon-migrated-node-js

https://siliconangle.com/2013/11/11/how-groupon-web-traffic-moves-from-legacy-ruby-on-rails-to-node-js/