［译］为什么是Napa.js

• 原文地址：github.com/Microsoft/n…
• 译者：沈毅
• 前言：微软最近发布的多线程JavaScript运行时，Napa.js非常受大家关注。译者也非常感兴趣，跟进的同时做一些翻译。

2007年7月17,根据 Tim Berners-Lee的最优效率原则（Rule of Least Power），Atwood提出了一个可以写入JavaScript历史的伍兹定律：任何可以用JavaScript编写的应用，最终都会用JavaScript来实现。

接下来的几年，Node.js，基于Node的巨大模块化生态系统NPM，还有像Angular.js ,React等等这样的项目，很好的应验了这个预言。只要JavaScript能做的，最终都会用JavaScript实现。

当我们开始研究Bing项目的时候，发现为了提高性能，后台服务都是由纯C++来实现的。但业务变革是非常快的，而且Bing的服务栈每周有增删改的逻辑。如果能找到兼顾性能和敏捷性的方法，那它将是一个能改变游戏规则，应对持续性变更的典范。我们研究了很多动态类型的语言，由V8引擎提供强力性能支持，和由npm建立起的巨大模块化生态的JavaScript就脱颖而出。

我们主要有四大需求要满足：

1. 解决方案需要能提供快速迭代算法的机制
2. 解决方案能够利用多核心优势
3. 结构上可以跨多个workers共享内存
4. 优秀的粒度并行性也是必要的，我们要用来减少线程间通信的花销。

当时，Node里已经有了2种处理CPU依赖性任务的方法：由C++拓展实现的异步JavaScript方案，或Node cluster。前一个不能满足要求1，而后一个不能满足要求3。

所以，我们受Node启发开始写Napa.js。我们相信JavaScript中多线程编程模式是必要的，使用Napa.js能够帮助开发者，无论是任何比例使用JavaScript还是C++，能达到动态的平衡。甚至性能要求很高的项目，开发者可以用JavaScript开始做所有的事情，迭代，聚合，然后逐渐把逻辑转成C++来最终实现。毫无疑问，这里用到了二八法则，少许20%的代码影响了了80%的性能，我们最终得到了一个美好的结果：一个JavaScript和C++混合的方案，具备了JavaScript快速发展变化的特性，也有C++高可复用，高性能的特性，最终能达到接近平台性能极限的能力。这个程序模块可以应用在任何一个由C++编写的服务上。

更多Napa.js信息，你可以参考：

• Napa.js简介
• Napa.js ReadMe