已经决定使用 JavaScript 开发 Web 应用程序，从浏览器一直到后端服务器，并放弃了使用 JSP/Java 编写的遗留代码。
PayPal 技术总监 Jeff Harrell 在两篇博文中（解放我的UI 第一部分：Dust JavaScript 模板、开源等、 PayPal 的 Node.js ）解释了他们做出这一决定的原因，并对 Web 应用程序开发从 Java/JSP 切换到完全的 JavaScript/Node.js 技术栈的过程中所产生的若干结论进行了说明。
据 Harrell 说，PayPal 的网站已经积累了大量的技术债务，他们想要一种“可以使他们摆脱债务而又能带来更大产品灵活性和创新的技术栈”。最初，在使用 Web 技术的前端工程师和使用 Java 编码的后端工程师之间存在着巨大的鸿沟。当用户体验设计人员想草绘一些页面时，为了使它们运行，他们不得不要求 Java 程序员做一些后端编码。这与他们的精益用户体验开发模型不相符：
当时，我们的 UI 应用程序基于 Java 和 JSP，使用了一个无弹性、紧耦合而又难以快速行动的专有解决方案。我们的团队发现它与精益用户体验开发模型不相符，而且无法快速行动，因此，他们用脚本语言构建原型，与用户一起测试，然后将代码移植到产品栈中。
他们想要一个“从底层服务器技术解耦并能使 UI 设计独立于应用程序语言的模板 [解决方案]”，而且它可以工作在多种环境中。他们决定选用 Dust.js ——一个由 LinkedIn 支持的模板框架——，再加上 Twitter 的 Bootstrap 和 Bower ，后者是一个面向 Web 的包管理器。之后又加入了 LESS 、 RequireJS 、 Backbone.js 、 Grunt 和 Mocha 等其它部分。
PayPal 的部分页面已经经过重新设计，但他们仍然还有部分页面使用遗留技术栈：
……我们有 C++/XSL 和 Java/JSP 两个遗留技术栈，随着继续推进，我们不打算留下这些 UI。JavaScript 模板是理想之选。在 C++ 技术栈上，我们构建了一个使用 V8 引擎执行 Dust 本地渲染的库——其速度惊人的快！在 Java 端，我们使用 Spring ViewResolver 和 Rhino 集成 Dust 来渲染页面。
当时，他们还开始用 Node.js 进行新页面的原型设计，并认为它“非常巧妙”，进而决定在生产环境对其进行试用。为了达到这一目的，他们还构建了 Kraken.js ，这是一个位于以 Node.js 为基础的 Web 框架 Express 之上的 “约定层”。（PayPal 最近开源了 Kraken.js。）第一个使用 Node.js 完成的应用程序是账户概览页，据 Harrell 说，该页面是 PayPal 的一个最经常访问页面。但是，由于担心 Node.js 应用程序可能扩展性不好，他们决定创建一个等效的 Java 应用程序，一旦 Node.js 应用程序不能正常运行，就可以回退到 Java 应用程序。下面是关于两种应用程序开发所需工作量的几个结论：
Java/Spring
JavaScript/Node.js
设置时间
2 个月
开发
大约 5 个月
大约 3 个月
工程师
5
2
代码行数
未说明
未说明，占 Java 应用程序的 66%
JavaScript 团队需要两个月的时间进行基础设施的初始设置，但他们创建具有相同功能的应用程序用人更少、耗时更短。他们在生产环境硬件上运行测试套件，得出的结论是 Node.js 应用程序的性能要优于 Java 应用程序：
Node.js 应用程序每秒服务的请求数是 Java 应用程序的两倍。更为有趣的是，在最初的性能结果的产生过程中，Node.js 应用程序使用了单核，而 Java 应用程序使用了五核。我们打算进一步增大这种差异。
而且：
对于同一页面，Node.js 应用程序的平均响应时间减少了 35%。这使得页面提供时间快了 200 毫秒——用户可以明显地感觉到这种变化。
结果，PayPal 开始在生产环境中使用了尚处于测试阶段的 Node.js 应用程序，并决定“今后所有面向客户的 Web 应用程序均基于 Node.js 构建，”，而现有的部分应用程序也将迁移到 Node.js。
据 Harrell 说，从浏览器到服务器都使用 JavaScript 的一个好处是，形成了一个“允许我们在技术栈的任何层次理解和响应用户需求”的团队，消除了前端开发与后端开发之间的鸿沟。
查看英文原文：**** PayPal Switches from Java to JavaScript
评论