Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
engineering.linkedin.com
Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
1–10 of 43 posts
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#2I am surprised that many of the big sites are just now getting around to moving away from the server side frameworks for UI. The benefits of doing so are just so great that I am surprised that they ignored it for so long. Flattening the web stack makes development rapid again, UI engineers can stub out JSON files to emulate the REST back end and iterate through bugs so much faster. At many of the companies that I have implemented new style web front ends out TCO dropped significantly. I guess it's telling of the times when you are more shocked to find out that people are just now doing as opposed to the fact that they are doing it.
As well I enjoyed the article, I have not used dust.js yet so it was interesting to see how it works. Dojo has a good templating model and I tend to prefer it over some of the other offerings, it is good to see that others are getting into the space. Though I do prefer Dojo's widget based templating over standard tiles type templateing, I find that it makes the code more compartmentalized and reusable. More of a black box, where code and template can just be added to a page and it works.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#3JSP, I never knew. That certainly explains a lot, particularly how it meshes with my sense of anything-JSP being a couple of years behind, featurewise. I don't know why this is, if it's a language non-feature, or a benefit of open-source libs, Java coding culture, or what, but I've thought that LinkedIn was making some silly site decisions and being inexplicably behind the times for some time now.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#4I did something similar for a recent project. My backend basically only provides an HTTP API. All rendering is client-side.
It felt natural as a programmer to develop the backend as a "library" that was "called" by the client side.
Immmmmense productivity. All pages require auth and shouldn't be indexed, so I don't worry about excluding search engines etc.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#5"All told, we evaluated 26 different templating technologies, scoring them on a variety of factors: DRY, JS library agnostic, mature, open source, easy to learn, documentation, flexibility, performance, and so on."
If anyone from Linkedin is reading - any chance of getting this evaluation posted somewhere? Would be useful even if it's just a "tech x factor" matrix without commentary.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#6I did something similar for a recent project. My backend basically only provides an HTTP API. All rendering is client-side. It felt natural as a programmer to develop the backend as a "library" that was "called" by the client side. Immmmmense productivity. All pages require auth and shouldn't be indexed, so I don't worry about excluding search engines etc.
Not sure why you're being downvoted, but I like this too. Your application should just be an API and pages should be tiny programs that call into this API. That way you can easily test your application and easily test your pages. And when you want to release "an API", well, you already designed, implemented, and tested it.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#7I did something similar for a recent project. My backend basically only provides an HTTP API. All rendering is client-side. It felt natural as a programmer to develop the backend as a "library" that was "called" by the client side. Immmmmense productivity. All pages require auth and shouldn't be indexed, so I don't worry about excluding search engines etc.
Not sure why you're being downvoted, but I like this too. Your application should just be an API and pages should be tiny programs that call into this API. That way you can easily test your application and easily test your pages. And when you want to release "an API", well, you already designed, implemented, and tested it.
Here here. Long live the one page web app.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#8> Once written, the same dust.js template can be rendered not only in the browser, but also on the server using node.js or Rhino.
I'm relieved to see their staff know what they're doing, and even curl http://www.linkedin.com/in/example still yields content. An alarming fraction of devs and toolsets out there would have screwed this up so badly that their resources would be cut off from reuse by the rest of the web, trapped behind an unstable single-site API.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#9"All told, we evaluated 26 different templating technologies, scoring them on a variety of factors: DRY, JS library agnostic, mature, open source, easy to learn, documentation, flexibility, performance, and so on." If anyone from Linkedin is reading - any chance of getting this evaluation posted somewhere? Would be useful even if it's just a "tech x factor" matrix without commentary.
Sure, we should be able to make it available on the blog site.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#10Doesnt this play havoc with caching - I mean if you had a single UI webapp (that in turn queries all other webservices to render a page), then you could simply heavily cache your UI webapp. But when your client side JS is directly querying individual web services, in that case you would have to cache each individual web service (not sure if this introduces inconsistencies vis-a-vis different web services).
Is this how Amazon - who reputedly has everything as services - renders its webpages as well ?