2016年度 JavaScript 展望

在过去的几年间，JavaScript 这种原本用于 Web 浏览器端的脚本语言，越来越多地出现在更广泛的软件应用中。现在，JavaScript 可用作服务器端代码，运行 iOS 与 Android 应用，甚至控制机器人。很难想象还有什么软件生态系统是 JavaScript 没有影响到的。

JavaScript 之所以能在这些新领域长驱直入，很重要的一个原因就是性能。然而，几年以前，在服务器端运行 JavaScript 还是完全不可想像的。在2008年，谷歌开始开发浏览器，并进军 JavaScript 引擎世界，继而触发了一场性能大战，最终极大地提升了该语言的速度。最近的一些努力，诸如 asm.js 只是锦上添花罢了。

本文将会介绍，除了用 JavaScript 框架运行服务器端 JavaScript、创建移动 apps 以及桌面应用之外，未来将何去何从？文中将直接引述许多 JavaScript 解决方案的开发者之观点。让我们首先了解 Node.js的发展，这或许是 JavaScript 的首个新领域。

Node.js

Node.js 是一款基于谷歌 V8 JavaScript 引擎的开源式运行时环境。尽管许多公司与框架都试图在服务器端运行 JavaScript，Node.js 却是首个大规模成功做到这一点的运行时环境。

从2009年首次推出开始，Node.js 的流行度可谓突飞猛进。使用 Ndoe.js 的公司数不胜数，而此前新近建立的 Node.js 基金会则包括 IBM，Intel，PayPal 以及 Microsoft 等巨头。Node.js 包管理器——npm，更是成为2014年软件世界中规模最大的包管理器，现在其包含的模块数是 Java 与 Ruby 等相似包管理器的两倍左右。

npm 包管理器的增长情况。图片来源：modulecounts.com

然而，Node.js 的成功并非没有经历波折。2014年底，一群开发者为此流行框架创建了一个分支，他们认为此前缺少活跃积极的新贡献者，导致 Node.js 版本更新太慢。这一新的框架，io.js很快虏获了众多追随者与社群的支持，这也让许多人担心 Nodo.js 世界将会长期处于分裂状态。幸好，2015年6月，Node.js 与 io.js 实现合并，这些担忧也不复存在。

此次合并在一定程度上促进了 LTS 计划（ Node.js 版本长期支持计划）的诞生。根据该计划，Node.js 每年都会指定一个版本为 LTS 版本，并为其提供长达18个月的支持。

这一开发周期的目的，是为了同时满足那些想走在前沿的开发者与需要稳定版本的大公司的需求。不可避免地，这样的开发周期也对 Node.js 的未来产生了重要影响。笔者就“2016年 Node.js 的最大变化”采访了 Node 基金会的 Mikeal Rogers，他的回答如下：

“全新的开发周期将成为最大的变化。每年，我们都会发布两个主要版本，而只有其一将得到长期的支持。这确实是前所未有的变化。此前，我们并未真正意义上实现 LTS 计划。因此，对广大开发者而言，这是全新的变化；对企业而言，这是提高产品采纳率的新机遇。” ——Node 基金会，Mikeal Rogers。

Node.js 2016年展望

在2016年，Node.js 与其包管理器 npm 的采纳率有望进一步提升。诸如 Microsoft、IBM、Intel、Progress Software 等大公司对 Node 的持续采用，以及诸如长期支持计划等企业友好型功能的推出，可能预示着 Node.js 在企业间的采纳率持续增长，甚至取代一些 .NET及 Java 提供的典型企业级解决方案。

此外，npm 模块的指数级增长也有望继续保持，因为 npm 最近推出的版本专注于为客户端 JavaScript 提供更好的支持，从而削减 Bower 等客户端 JavaScript 包管理器的需求。随着越来越多的开发者开始在 npm 注册客户端脚本与 jQuery 插件，npm 的触角只可能进一步延伸。实际上，根据 Mikeal Rogers 的观点，npm 增长的主因其实是 Node.js 生态系统的进一步完善。

”几年前，我对 npm 的增长率进行量化，进而创建了一副 npm 增长预测图。当时，许多人认为这图简直是天方夜谭，因为图中预测在一年多的时间里，模块数量将超过10万，而且增长率不会趋于平衡状态。但实际情况却是，仅仅数日，模块数量就超过了10万，这让我也颇感惊讶。

如果你仔细了解 npm 的增长模式，你会发现推进 npm 持续增长的动力来自 node.js 生态系统。这里是为众多使用案例创建子平台的最佳环境。即便生态系统的一些部分会趋于平衡状态，但是新的快速成长的生态系统很快就会取而代之。” ————Node 基金会，Mikeal Rogers。

作为以上观点的佐证，几乎本文涉及的所有 JavaScript 解决方案，包括 Cordova，React Native 与 NativeScript 都使用 npm 作为包管理器。如果你在 npm 搜索一下 “jquery”、“polymer”、“meteor”或“react”，就能了解 npm 现在的规模是多么庞大。当然，随着 npm 的普及率持续增长，Node.js 的采纳率也是一路高歌猛进。作为软件世界首个主流的服务器端 JavaScript 框架，其未来可谓一片光明。

下面，让我们来一些不在服务器端运行 JavaScript，而是使用 JavaScript 运行移动 apps 的技术。

PhoneGap and Cordova

与 Node.js 是首个将 JavaScript 运行在服务器端的主流解决方案相类似，PhoneGap 是首个使用 JavaScript 运行本地移动 apps 的主流解决方案。最初，PhoneGap 于2009年由 Nitobi 创立，在 2011年10月由 Adobe 公司收购。作为收购的一部分，PhoneGap 的源代码被捐赠给 Apache 软件基金会，此项目也更名为 Cordova。如今，Cordova 已经成为一个免费的开源框架，得到许多公司的支持。而 PhoneGap 则是 Adobe 所有的一个 Cordova 分支。

多年来，Cordova 都在与性能不佳的名声做斗争。其中，最广为人知的抱怨出现在2012年，出自科技界最有影响力的人之口：

“当我反省过去几年的经历时，发现我们公司犯下的最大错误，是在 HTML5 中投入了太多努力……” Facebook 创始人，Mark Zuckerberg。

从2012年开始，一些公司开始介入解决 Cordova 的性能问题。这催生了 Ionic、Onsen 等以性能为中心的 UI 框架，以及 Kendo UI Mobile，由 PhoneGap 团队与 Telerik 公司联合开发的工具改进，还有Crosswalk 提供的全新 Web 视图，以及 Telerik 插件市场中的多款高质量插件。

Telerik 插件市场

除了这些公司提供的性能援助，由移动 OS 创造者提供的新功能，诸如 Android 的自动更新 Web 视图与 iOS 的新 WKWebView API，有效地帮助了 Cordova 的性能提升。基于此，笔者采访了前 Adobe PhoneGap 团队成员 Brian LeRoux，咨询他对 Cordova 的未来作何设想。

“现而今，Cordova 已经变得相当稳定。我们努力保持简洁，用插件接口实现各种功能，并尽可能在 Android M 与 iOS 9 等平台更新中保持主动。虽然经历了几年的颠簸，但是现在’小模块化’的思想终于开始落地生根，这让我颇感欣慰。如果不是要在自己的项目中延展使用 Cordova，终端设备开发者恐怕无法了解这一思想的好处。” Brian LeRoux

Cordova 2016年展望

与 Node.js 相似，Cordova 的稳定性对于刚开始在移动开发领域试水的大公司而言尤为诱人。而使用 Cordova 结合 HTML，CSS 以及 JavaScript 打造移动 apps 的方法对众多 web 开发者来说也极具吸引力，尤其是与使用 Xcode 与 Android Studio 进行本地开发的方式相比。

尽管 Cordova 的普及率持续走高，其开发方式却遭到了两个方面的挑战。挑战一来自努力推广渐进式应用（progressive apps）的谷歌，此类应用包含启动时屏幕、主屏幕布局以及离线访问等功能。目前，渐进式应用仍处于早期阶段，其功能仅限于 Android 版 Chrome 浏览器。然而，在2016年，谷歌肯定会继续推广渐近式应用的概念。

Cordova 开发的第二个更为迫切的挑战来自 JavaScript 世界的一项新近发展：使用 JavaScript 构建真正的本地移动应用。

本地移动 apps

在2015年，出现了一种新的基于 JavaScript 的移动应用开发类别：JavaScript Native。与基于 Cordova 或 PhoneGap 的应用不同，JavaScript 本地应用使用平台的本地控制与范型建立用户界面，无需涉及浏览器或 web 视图。

JavaScript Native 框架试图提供一种两全其美的方式建立 iOS 与 Android 应用：使用 JavaScript 编写程序逻辑（而不是 Java，Swift等），使用平台的本地用户界面 API 建立适应原生 OS 的应用，从而实现可能的最佳性能。

使用 JavaScript 打造的移动 apps 举例，点此获得源代码。

React Native 与 NativeScript是2015年最早公开发布的两个 JavaScript Native 框架，后来者还包括Fuse 与 tabris.js。自然，不同的框架提供了不同的功能。比如说，React Native 允许重用 React JavaScript 框架，而 NativeScript 允许直接调用 iOS 与 Android APIs。但是，他们都具备使用 JavaScript 搭建真正本地 apps 的高级方法。

尽管使用 JavaScript 建立本地 apps 的想法对 web 开发者而已相当诱人，但与 Cordova 之类的框架相比，JavaScript Native 框架也存在如下的一些缺陷：

• 由于 JavaScript Native 框架不使用浏览器，你必须学习用于搭建界面的框架相关的 APIs，而不是像打造 Cordova 应用那样简单地使用 HTML 语言。
• 由于 JavaScript Native 应用是本地应用，在建立较为大型的应用时，内存管理是需要额外考虑的问题，这与建立本地 iOS 与 Android 应用时如出一辙。
• 最后，由于 JavaScript Native 框架非常新兴，可参考的案例与教程都很有限。与那些经历多年发展的框架相比，这些框架还很不成熟。

就这些框架在2016年的发展，笔者采访了来自 React Native 团队的 Christopher Chedeau (aka Vjeux)以及 NativeScript 的产品经理Valio Stoychev。两者都不谋而合地关注于稳定性。

“就 React Native 而言，我们已经度过了早期的新鲜阶段，现在正进入的这个阶段要求我们变得更加牢靠。你可以发现，在性能工具优化、核心 APIs 提升，错误消息优化以及边缘案例修复方面，我们投入了大量的努力。这样，Facebook 内外的工程师才能随心所欲地打造更加高质量的移动 apps。“ ——Facebook，Christopher Chedeau (Vjeux)。

”随着用户基础的不断扩张，我们要为用户确保一个鲁棒的框架，才能在此基础上打造切实可行的应用。因此，我们打算继续在性能及调试工具方面努力，从而提高 NativeScript 开发者的体验。此外，另一重心是与 Angular 2 团队的合作，预计将贯穿2016年。” ——Telerik，Valio Stoychev。

JavaScript Native 2016年展望

对 JavaScript Native 平台而言，2016年的重点是提升稳定性与采纳率。随着 React Native 与 NativeScript 等框架不断巩固其功能集，预计围绕这些框架的工具也会越来越多，比如 Telerik 用于搭建 NativeScript 应用的 Telerik Platform。

当然，时间会告诉我们，2015年 JavaScript Native 应用的大热能否在2016年转化为大规模的使用。但是，使用这些框架成功打造的大量高质量应用（查看 React Native 案例展示及 NativeScript 案例展示）似乎在暗示，用 JavaScript Native 方法打造应用的模式将会流行很长一段时间。

对需要结合本地 UIs 与本地应用的公司而言，JavaScript Native 框架相比于使用 Xcode 与 Objective-C/Swift 打造 iOS 应用以及使用 Android Studio 与 Java 打造 Android 应用，提供了更加强有力的选项，尤其是考虑到多数公司的开发者都具备一定 JavaScript 开发能力。

总而言之，JavaScript Native 应用对 JavaScript 开发者而言是令人激动的全新战场。JavaScript 开发者不再需要学习本地编程语言就可以编写本地移动应用。然而，本地移动应用并不是 JavaScript 渗入的唯一领域——在传统的桌面应用领域，JavaScript 也有涉足。

Desktop 应用

习惯上，如果想搭建一个 Windows 或 Mac 应用，你会使用 WPF 与 Windows Forms 之类的平台特定工具或 Java、Adobe Air 之类的跨平台接口。但是，与本文中讨论的其他软件生态系统一样，基于 JavaScript 的解决方案正慢慢地侵入这一版图。

该领域内首个基于 JavaScript 的解决方案是 Node-WebKit，由 Intel 创建并于2011年底实现开源。Node-WebKit 现在又称为 NW.js，因为它已经从 WebKit 切换为 Chromium。NW.js 的实现方式与 Cordova 有些类似，只不过它针对的是桌面应用。

NW.js 最早由 Intel 开发，于2011年公开发布。

NW.js 会将 web 应用打包至本地 shell，同时提供访问本地桌面 APIs，诸如文件选择器、窗口菜单等功能。这种组合允许你使用基于统一标准的 web 技术打造 Windows，OS X 以及 Linux 桌面应用。

如果快进一两年，你会发现 NW.js 并非使用这种基础架构的唯一框架。2015年4月，GitHub 宣布推出 Electron，一款相似的用于创建跨平台应用的框架。

GitHub 于 2015年4月宣布推出 Electron

Electron 最早作为 Atom（GitHub 的 web 端文本编辑器）的 shell 开发出来，之后经过拆分更易于在其他项目中使用。因为 GitHub 的支持，Electron 的流行度突飞猛进，现在在 GitHub 上有超过2万颗星（很快赶上 NW.js 的2.5万颗星）。

2015年，作为 Microsoft 全新跨平台 Visual Studio Code IDE 背后的引擎，Electron 再次登上头条。此外，浏览一下社群创造的 Electron 资源列表，就会了解 Electron 在开发社群是多么受欢迎。

桌面应用 2016年展望

与本文讨论过的许多技术相似，用于搭建桌面应用的这些跨平台 JavaScript 工具的未来似乎前途无量。有了 GitHub、Microsoft 甚至 Slack 这些先例——Slack 其实并非基于 NW.js 或 Electron 搭建，但是也使用了 web 技术创建本地应用——其他公司可以信心满满地使用 web 技术搭建桌面应用。预计，在2016年，NW.js、Electron 之类的项目将会创建出更多的桌面应用。

2016年 JavaScript 的新领域

尽管本文讨论的话题似乎有些分散——服务器端代码、移动 apps 以及桌面应用，叙述的主体却是基本一致的：短短几年时间里，在这些环境中运行 JavaScript 从不可想象演进为大势所趋。在不到十年时间里，JavaScript 从用于处理图片翻转的小儿科语言，进化为可能是世界上最流行的编程语言。JavaScript 的未来，似乎无可限量。

2007年，Jeff Atwood 发出豪言：”任何能用 JavaScript 编写的应用，最终都会由 JavaScript 写就。“这句话简直如先知一般准确。事实上，JavaScript 已经延伸到许多本文未曾涉及的领域，例如通过Johnny-Five 这类项目运行在硬件，甚至在苹果最近宣布的用于 Apple TVs 的 tvOS 中成为创建本地应用的一等公民。

促使 JavaScript 不断成长的一大原因，是人们对使用单一开发模型打造多种范型软件的渴望。大多数公司，尤其是小公司，都无法雇佣足够数量的开发者，以满足人们当前使用的不计其数的操作系统与设备类型的需求。甚至在 Facebook 这种规模的公司，这也是一大问题，正如 Christopher Chedeau 所说：

”在我眼中，开发者世界的一大悲哀是社群依据语言（甚至是生态系统）进行划分。 JavaScript、Java、Objective-C、Python 以及 C++ 等。实际上，这导致了资源的巨大浪费，因为针对每个生态系统，都要开发类似的一套工具，诸如包管理器，IDE，核心函数库，知识库等。

举个具体的例子吧，在 Facebook，每个功能我们都必须实现三次：Web 版，iOS 版以及 Android 版。更糟的是，由于一个工程师往往难于同时掌握这些生态系统，我们通常需要三个人来实现一个功能。这真是悲哀。

为了解决该问题，我首先想到的是，我们需要一种单一的语言或生态系统。有了 React Native，我们更趋向于 JavaScript 语言，但从宏观的角度看，哪一种语言并不重要。重要的是，只保留一种语言。“ —— Facebook，Christopher Chedeau。

随着 JavaScript 迅速地在移动、桌面、服务器、硬件领域获得青睐，它已经成为唯一可能让此美好愿景成为现实的语言。时间会告诉我们，JavaScript 的极速增长能否在2016年持续下去。不过，JavaScript 工具在软件生态系统的快速普及似乎预示着 JavaScript 无可限量的未来。

原文链接：http://www.css88.com/archives/6047