Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

engineering.linkedin.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#11

Post by toonketels »

vybs wrote: post #9
reinhardt wrote: post #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.

Sure, we should be able to make it available on the blog site.

That would be great. I also would love to see the see the matrix.

Any change you are going to discuss in more detail how to use the js templates on client and server side?

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#12

Post by akavlie »

JSP is an archaic template language. I'm on a project with JSP on the front end; compared to Django, Jinja, or any of the other Python template languages it's really limited and verbose.

It's interesting that LinkedIn chose dust.js as it doesn't get much attention compared to some of the other JS template languages (e.g. Mustache & Handlebars.js).

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#13

Post by strlen »

akavlie wrote: post #12

JSP is an archaic template language. I'm on a project with JSP on the front end; compared to Django, Jinja, or any of the other Python template languages it's really limited and verbose. It's interesting that LinkedIn chose dust.js as it doesn't get much attention compared to some of the other JS template languages (e.g. Mustache & Handlebars.js).

Do keep in mind that LinkedIn was founded in 2003, before many of the web frameworks were released. LinkedIn also uses a custom JSP compiler, as at the time the official implementation lacked many feature.

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#14

Post by sonnym »

It should be noted that dustjs is not yet updated for node v0.6.x. I submitted a rather trivial pull request toward the end of October fixing the problem and another user has submitted one since then, but the author has not responded to either.

This makes me question how much the project will be supported in the future - but I suppose having a large company like LinkedIn invested in the technology is a good sign.

See: https://github.com/akdubya/dustjs/pull/36

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#15

Post by akavlie »

strlen wrote: post #13
akavlie wrote: post #12

JSP is an archaic template language. I'm on a project with JSP on the front end; compared to Django, Jinja, or any of the other Python template languages it's really limited and verbose. It's interesting that LinkedIn chose dust.js as it doesn't get much attention compared to some of the other JS template languages (e.g. Mustache & Handlebars.js).

Do keep in mind that LinkedIn was founded in 2003, before many of the web frameworks were released. LinkedIn also uses a custom JSP compiler, as at the time the official implementation lacked many feature.

That wasn't meant as a criticism of LinkedIn's adoption of it, more my own circumstances and the fact that frameworks are still using JSP by default in 2011.

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#17

Post by bigiain »

sandGorgon wrote: post #10

Doesnt 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 ho…

Not only caching, but right now I suspect this approach could have _serious_ SEO implications. It seems to run directly against the guidelines against cloaking here: http://support.google.com/webmasters/bin/answer.py?hl=en&#38...

(Not that I suppose LinkedIn are too worried about search engine discoverability of a lot of their "dynamic, login required" content, but I'll bet they're _not_ using this technique on all those highly optimised pages full of people's names - like the 4th Google hit for my name: http://au.linkedin.com/in/iaindchalmers )

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#18

Post by bigiain »

Curiously, we tried this and backed away to using AJAX calls returning pre-rendered html fragments in a recent project.

If you're building a mobile site, and want to target low-end Android devices (our "crappiest-phone-test-device" was a Huawei U8180), you really don't get a lot in the way of JSON parsing or DOM manipulation performance.

I wonder what (if anything) LinkedIn are doing for mobile?

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#19

Post by eneveu »

akavlie wrote: post #12

JSP is an archaic template language. I'm on a project with JSP on the front end; compared to Django, Jinja, or any of the other Python template languages it's really limited and verbose. It's interesting that LinkedIn chose dust.js as it doesn't get much attention compared to some of the other JS template languages (e.g. Mustache & Handlebars.js).

I wonder what's the best alternative for server-side template generation on the JVM.

I used FreeMarker on a previous project, it's pretty cool ( http://freemarker.sourceforge.net/ ). There is also mustache.java ( https://github.com/spullara/mustache.java ). I heard about Velocity and StringTemplate, but never tried them out... I guess Groovy Server Pages could also be considered if one's company is open to Grails...

Anything else I should be aware of?

Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

#20

Post by strlen »

akavlie wrote: post #15
strlen wrote: post #13

Earlier quoted context omitted.

Do keep in mind that LinkedIn was founded in 2003, before many of the web frameworks were released. LinkedIn also uses a custom JSP compiler, as at the time the official implementation lacked many feature.

That wasn't meant as a criticism of LinkedIn's adoption of it, more my own circumstances and the fact that frameworks are still using JSP by default in 2011.

Definitely wouldn't use it. Even for server-side Java, there are better templating engine. I am not a web developer, so I am not fully qualified to speak, but in cases where I've needed templating, I've found Apache Velocity and Freemarket to be good options for Java (but most of the time, I am templating, e.g., code to be auto generated or configuration files, rather than web pages).
Post reply on HN