Social Enterprise investigate

LinkedIn turns presentation to dust.js

The social network for professionals has moved its presentation layer from off the server to the client via the dust.js library.

LinkedIn had a problem --- a UI code sharing problem.

After starting out with a nice Java Servlet and JSP stack, they needed to become rapid and so added Grails (Groovy on Rails) and JRuby on Sinatra into the mix. It was working out well, and for a while it seemed as though they had the perfect mix of dynamic languages and a statically typed foundation.

The LinkedIn Java based stack

The LinkedIn Java-based stack

(Credit: LinkedIn)

"It seemed like we had the best of both worlds for a while, but we gradually realised how difficult it had become to write reusable front-end features," wrote Veena Basavaraj, senior software engineer at LinkedIn in a blog post.

"Each tech stack used a different technology to render pages: the Servlets used JSPs, Grails used GSPs, and JRuby used ERBs. This made it very difficult to share UI code."

Basavaraj points to the example of the site's skills widget, which was an ERB being rendered in its profile page which itself was a JSP template.

The solution to the dilemma was to move the rendering client-side. LinkedIn looked at 26 different frameworks before settling on using dust.js in combination with a CDN to speed up delivery of the templates. Now the Grails, Java and JRuby servers send back JSON for the client to insert into the templates.

The new LinkedIn stack with dust.js and a content delivery network for templates.

(Credit: LinkedIn)

I like this little examination of LinkedIn problems because it properly separates computation vs. presentation issues that many developers face on a daily basis. In this scenario there is no choice left but to treat the presentation layer as something entirely different; no cheap hacks to be quickly inserted to deal with edge cases or inserted out of sheer laziness.

Certain languages whose names are self-recursive acronyms and their associated template frameworks often have a great deal of template code laying around all over the place, and it is a royal pain to maintain and develop for. Earlier in the week I pointed out how to remove some of the form handling code using sessionStorage.

And the best part about this LinkedIn post is that it points to some source code examples of their new templates.

Using dust.js looks like an attractive alternative to old-school server-side templates; provided that developers and their superiors can get over the possibility of other developers using Firebug and other tools to look at their raw templates over the air. Maybe that risk will force developers and designers to up their game and create templates that they are proud to show off, rather than be tempted by the baser emotions and want to obfuscate as much as possible.

About

Some would say that it is a long way from software engineering to journalism, others would correctly argue that it is a mere 10 metres according to the floor plan.During his first five years with CBS Interactive, Chris started his journalistic advent...

3 comments
seanferd
seanferd

I just refrained from bringing this up in another conversation, but here we are, with everyone pushing the cloud and were back to shoving the processing back on the client. My comment is nothing specific against LinkedIn on this move. Good on them for fixing the problem.

Gont
Gont

Dust seems to be really sexy and I always try to export presentation as much as possible the presentation client side. But as all of us know, Javascript isn't search engine friendly and it the same thing about readers for people with disabilities. What do you think about ? I think that linked'in as a solution... Do you know what it is ? Regards, Guillaume.

Chris Duckett
Chris Duckett

As the LinkedIn post said, they use node.js and Rhino on the backend to serve up JavaScript server-side when they must. Presumably this works just as well for accessibility as it does for the GoogleBot.