PayPal has decided to use JavaScript from browser all the way to the back-end server for web applications, giving up legacy code written in JSP/Java.
Jeff Harrell, Director of Engineering at PayPal, has explained in a couple of blog posts (Set My UI Free Part 1: Dust JavaScript Templating, Open Source and More, Node.js at PayPal) why they decided and some conclusions resulting from switching their web application development from Java/JSP to a complete JavaScript/Node.js stack.
According to Harrell, PayPal’s websites had accumulated a good deal of technical debt, and they wanted a “technology stack free of this which would enable greater product agility and innovation.” Initially, there was a significant divide between front-end engineers working in web technologies and back-end ones coding in Java. When a UX person wanted to sketch up some pages, they had to ask Java programmers to do some back-end wiring to make it work. This did not fit with their Lean UX development model:
At the time, our UI applications were based on Java and JSP using a proprietary solution that was rigid, tightly coupled and hard to move fast in. Our teams didn’t find it complimentary to our Lean UX development model and couldn’t move fast in it so they would build their prototypes in a scripting language, test them with users, and then later port the code over to our production stack.
They wanted a “templating [solution that] must be decoupled from the underlying server technology and allow us to evolve our UIs independent of the application language” and that would work with multiple environments. They decided to go with Dust.js – a templating framework backed up by LinkedIn – , plus Twitter’s Bootstrap and Bower, a package manager for the web. Additional pieces added later were LESS, RequireJS, Backbone.js, Grunt, and Mocha.
Some of PayPal’s pages have been redesigned but they still had some of the legacy stack:
… we have legacy C++/XSL and Java/JSP stacks, and we didn’t want to leave these UIs behind as we continued to move forward. JavaScript templates are ideal for this. On the C++ stack, we built a library that used V8 to perform Dust renders natively – this was amazingly fast! On the Java side, we integrated Dust using a Spring ViewResolver coupled with Rhino to render the views.
At that time, they also started using Node.js for prototyping new pages, concluding that it was “extremely proficient” and decided to try it in production. For that they also built Kraken.js, a “convention layer” placed on top of Express which is a Node.js-based web framework. (PayPal has recently open sourced Kraken.js.) The first application to be done in Node.js was the account overview page, which is one of the most accessed PayPal pages, according to Harrell. But because they were afraid the app might not scale well, they decided to create an equivalent Java application to fall back to in case the Node.js one won’t work. Following are some conclusions regarding the development effort required for both apps:
| Java/Spring | JavaScript/Node.js | |
| Set-up time | 0 | 2 months |
| Development | ~5 months | ~3 months |
| Engineers | 5 | 2 |
| Lines of code | unspecified | 66% of unspecified |
The JavaScript team needed 2 months for the initial setup of the infrastructure, but they created with fewer people an application with the same functionality in less time. Running the test suite on production hardware, they concluded that the Node.js app was performing better than the Java one, serving:
Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
and having
35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.
As a result, PayPal began using the Node.js application in beta in production, and have decided that “all of our consumer facing web applications going forward will be built on Node.js,” while some of the existing ones are being ported to Node.js.
One of the benefits of using JavaScript from browser to server is, according to Harrell, the elimination of a divide between front and back-end development by having one team “which allows us to understand and react to our users’ needs at any level in the technology stack.”
