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