Dust JavaScript templating, open source and more


A year ago we set out on an effort to revitalize PayPal’s user interface. As you may know, there are quite a few pages on our site with designs that date back years and it’s about time we got rid of them! To accomplish this, a large part of what we had to overcome was technical debt, and we needed a technology stack free of this which would enable greater product agility and innovation. With this in mind we set out to “free our UI bits”.

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.

There are obvious issues with this approach, so we decided it was time to change things and came up with a few requirements:

  1. The templating must be decoupled from the underlying server technology and allow us to evolve our UIs independent of the application language
  2. It must be open source
  3. It must support multiple environments

Decoupling our templates

Templating was the cornerstone piece, but we didn’t need to dwell on it too much. Everyone is familiar with JavaScript templating nowadays and it has huge benefits with empowering both client and server side rendering, so it seemed like a given. Dust, Mustache, Handlebars: they all have similar approaches to JavaScript templating, each with their own pros and cons. In the end, we opted to partner with LinkedIn and go with Dust templates and have been happy to contribute back to the project where we can.

As it turned out, Dust was so successful and well received in the company that before we finished integrating into our framework we found ourselves with half a dozen teams using it. We found JavaScript templating to be a great compliment to a Lean UX iteration cycle and have been impressed with the speed that our teams can turn design ideas into code. Along the way we opted for a few other enhancements to our templating, including leveraging Bootstrap for initial concepts and using Bower to manage our components.

By the time Dust was officially released, all of our products were using it in place of JSP.

Open source all the things

We made a conscious decision to fully embrace open source in our UI. It sounds common sense, but enterprise-scale companies often have a habit of creating proprietary solutions — at least we’ve made this mistake in the past — and keeping them propriatary. There are three major downsides with this approach:

  1. Proprietary solutions create an artificial ramp up time for new employees to become productive
  2. It forces a portion of your team to focus their energy on building your solution rather than your product
  3. These solutions are rarely better than the ones available in the open source community

Through a bit of exploration the rest of our UI stack started to fall into place:

  • LESS was the CSS pre-processor we chose since it aligned well with our JavaScript stack and worked with Bootstrap
  • RequireJS was chosen as our JavaScript module loader due to it’s clear and descriptive nature
  • Backbone.js worked out as our client-side MV* framework
  • Grunt was being used for our UI build tasks, because, well, Grunt is just awesome
  • Mocha was starting to be explored for enabling CI driven workflows for our UIs

Multiple environments

One requirement we had was that the templating solution must support multiple environments. An interesting fact of being an internet company for more than a few years is that you tend to end up with multiple technology stacks. In our case, 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.

Node.js was also introduced into the company around this time. Since our teams already knew JavaScript the pure development speed we could achieve with node was highly desirable to our product agility. Plus, integrating Dust was trivial since they are both JavaScript.

Finally, let’s not forget the browser as a rendering environment. Dust allows us to easily perform client side rendering. This brings up an interesting point though: Rather than saying we’re going to render all pages in the browser because we can, we’re opting to do what makes sense for both your browser and our engineers. Client side rendering is great, but not always needed. You’ll notice on the new PayPal pages that the first page is always rendered on the server to bootstrap the app, but from there it’s up to the UI engineers to decide it they need client side rendering or not. We like this flexibility.

Live Dust apps

So, all of this is good, but where are we using Dust and the new technologies today? Well, it’s is actually live on a good portion of our website that’s been redesigned. This includes our:

  • Home pages
  • Checkout (currently being A/B tested)
  • New user signup
  • A lot more on the way!

What’s next

Our UI engineers are now happy. They can iterate quickly on production-style apps with their design counterparts and get those ideas out of their heads and in front of customers. We’re now starting to see a build, test, learn culture form, which is a long way from the waterfall model we traditionally had with our design partners, and hopefully our users start to notice as more of the website gets updated.

Changing the front end technologies at PayPal was a huge success, but we’re now looking to make another step. Node.js started to organically spread through the company as a part of these efforts and we will take a look at that in Part 2.

Finally, we’re hiring, so if any of this sounds interesting come work for us!


Jeff Harrell

A designer turned engineer, I’ve been making applications for the web for years and enjoy all aspects from conceptualization and design to the engineering bits which drive them. Simply put, I love building great products.

During the day, you can find me at PayPal HQ where I lead UI Engineering Architecture. My focus is disruptive change for both products and our technology stack, and I’m excited that we’re making strides in this direction.