Tungsten.js was developed by engineers at e-commerce site Wayfair to provide a modular framework for building Web UIs that have high-performance rendering on both the client and server. Found on GitHub, the open source technology offers high-performance DOM updates, uses Mustache templates, and serves as an alternative to front-end JavaScript libraries. Development began around September 2014.

InfoWorld Editor at Large Paul Krill recently spoke with Wayfair’s Matt DeGennaro, the primary developer of Tungsten.js, about the framework and what separates it from other JavaScript options.

[ Find out how to handle the real-world problems faced by developers, with InfoWorld's professional programmer's business survival guide. | Keep up with hot topics in programming with InfoWorld's Application Development newsletter. ]

InfoWorld: Basically, the main purpose in developing Tungsten.js was you couldn’t find something that suited your needs at Wayfair, correct?

DeGennaro: That’s correct. We really wanted something that was going to give us first-class server-side rendering. As an e-commerce company, SEO is our bread and butter. We really can’t do client side-only page rendering, and all of the newer libraries that offered great in-browser speed had kind of accidental server-side rendering or it worked if you had a Node back-end setup. Since we’re primarily a PHP shop, we couldn’t switch all of our servers over and retrain all of our developers in writing JavaScript for the back end, so we decided to look around. We spent some time evaluating what was out there.

InfoWorld: What differentiates Tungsten.js from other JavaScript technologies ranging from Angular to Meteor to Backbone to Ember?

DeGennaro: The main thing we’re trying to do with Tungsten is to keep everything split into three main components, which we call the developer interface, the template library, and the DOM interaction. By keeping those separated, right now we’re using Backbone for the developer interface, Mustache for the template, and Matt-Esch’s virtual DOM library for the DOM interaction.

What we think this is going to give us is a lot of freedom moving forward to swap out these components without having to worry too much about going back and fixing everything. With other libraries, a lot of times like you’d see with the Angular 1 to Angular 2 switchover, the developers decided to change a lot of things under the hood and you change a lot about the library, and early on there were a lot of fears that the upgrade path was going to be a little ugly. Since we’re a large company and code tends to come out fairly rapidly, one of our big concerns was how we can make sure our library is fresh for code that comes out next year as well as five, 10 years into the future.

InfoWorld: At what state of development is Tungsten.js?

DeGennaro: Right now it’s in production use here at Wayfair. I would say it’s definitely past alpha, probably still in beta. We’re shooting for a 1.0 release some time over the next couple of months.

InfoWorld: Why should developers either inside or outside of Wayfair be excited about the release of Tungsten.js?

DeGennaro: The reason we think it’s really cool is a lot of shops have not really invested in a JavaScript-on-the-server architecture, so Tungsten allows for you to use portable templates. We use Mustache, and Mustache is one of the languages compiled for every language I’ve ever seen in Web development. This allows you to render everything on the server using the languages you’re comfortable with, but also getting the speed that comes from a virtual DOM implementation on the client side.

InfoWorld: How does Tungsten fit in with Node.js?

DeGennaro: It could certainly be used with Node, but with Tungsten, we don’t really focus on any server-side aspects. We just wanted to focus on making something that could be server-side-compiled for any server environment that people happen to be using.

InfoWorld: What is the role of the virtual DOM in Tungsten.js?

DeGennaro: For virtual DOM, we use that for computing the changes that need to happen when our data changes. Rather than relying on the developer to figure out the easiest way to get from page A to page B would be, we use the templates to get a before and after state, then we use the virtual DOM engine to compute a diff (difference) and apply that to the DOM. Since DOM operations are usually one of the bottlenecks -- it’s not slow, but it’s usually the bottleneck -- by doing computations off the DOM, in JavaScript memory, we’re able to do fairly complicated diffings without having to worry about affecting the page.

InfoWorld: What have been the results of the performance of Wayfair.com with Tungsten in it?

DeGennaro: It’s been rolled out piecemeal as developers make changes to parts of the Web page. We’ve encouraged them to implement Tungsten where it makes sense. Obviously, [with] small changes on the large existing deployment, it doesn’t make sense to refactor, but for places where we have implemented Tungsten, we’ve seen up to a threefold improvement in terms of page performance.

InfoWorld: What specific aspect of Tungsten has enabled that?

DeGennaro: A lot of it is that since we’re using shared templates, we can guarantee the initial page render is the page we want it to be. We don’t need to worry about making small changes with JavaScript once the page is loaded. That allows us to avoid page reflows early on in the process. Additionally, we found that the developers wind up writing less Tungsten code for their components, so there are fewer bytes over the wire for us to load per page.