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
"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.
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.
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.
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 adventure in 2006 as the Editor of Builder AU after originally joining the company as a programmer.Leaving CBS Interactive in 2010 to follow his deep desire to study the snowdrifts and culinary delights of Canada, Chris based himself in Vancouver and paid for his new snowboarding and poutine cravings as a programmer for a lifestyle gaming startup.Chris returns to CBS in 2011 as the Editor of TechRepublic Australia determined to meld together his programming and journalistic tendencies once and for all.In his free time, Chris is often seen yelling at different operating systems for their own unique failures, avoiding the dreaded tech support calls from relatives, and conducting extensive studies of internets — he claims he once read an entire one.