BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

PayPal Switches from Java to JavaScript

by Abel Avram on Nov 29, 2013 |

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.”

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Sigh by Mark N

I can't verify their tests ...

But they are ignoring that "backend" and "frontend" developers are still different. And due to the nature of JavaScript and the lack of tooling, they are looking at a bigger TCO. Their code base will increase because of the tests they will have to write.

As for "speed" when they use Node.js and plain Java, they are comparing apples and oranges. There are at least 3 Java async APIs.

There are multiple ways to code in Java for the client and still have it run as JS in the browser

That they were still using JSP is very telling.

Java or JEE problem? by Jakob Jenkov

It sounds to me as if Paypal are attributing to "Java" what is really a problem of JEE. The JEE stack is way past its due date, invented for a time when web apps were the only type of apps Java developers did, and where they looked much simpler than they do now (with AJAX calls, WebSockets etc).

Re: Sigh by Philipp Schneider

I absolutely agree on your opinion.
Node.js is async and they probably used Spring in a sync way.

Simply combing UI engineer and JEE developer may not be a good idea by Zheng Bright

I think you may be coming from UI team and are lack of full view of the "architecture".

After having the prototype on hands, some guys like you may be thinking that "great, the work is almost done" and then hand over to the development team for the detail implementation. To your surprise, the JEE developers plan a longer timing than what you expected, so you hate these guys and are thinking to combine them with all UI/javascript guys.

It's dangerous.
Again, you may not have a full view of the whole system's architecture.

Replacing JSP is good idea as it's not a good templating technology. But doing so doesn't mean that you're replacing Java, especially backend components.

The backend roles are definitely necessary as they're thinking different ways.
Improving the roll-out efficiency doesn't mean just to simplify the team as one or two roles that you like.

Hope you understand.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT