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

31–40 of 43 posts

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

#31

Post by johnx123-up »

simonw wrote: post #28
johnx123-up wrote: post #24

Earlier quoted context omitted.

Can you please elaborate on this?

I imagine the parent means that building single-page apps that require a full DOM+JS implementation is bad for the Web, because it cuts content off from being accessed by anything other than a full modern browser running several million lines of C++. See also my answer to this question about single-page apps on Quora: http://www.quora.com/What-exactly-is-a-single-page-applicati...

IIRC, you're Node.js evangelist? What's your take on Node.js (server) + Backbone.js (or dust.js as mentioned here)? Not for all, but for Trello like client apps?

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

#32

Post by Tautologistics »

Unless I am missing something, the bullet point near the end, "Progressive rendering", is not correct when it states that template rendering is asynchronous and parallel. Fetching of data, sure, but unless they are using web workers to execute the templates client side, and I do not see workers mentioned anywhere, this is not accurate. When a template is rendering, all other JS and UI will stop.

Having applied the same approach as LinkedIn on past projects and jobs (e.g. BN.com), there is definitely a lot to be gained if done right, and web workers, when available, ease some of the issues with rendering large templates and/or large datasets.

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

#33

Post by nevinera »

bigiain wrote: post #27
vybs wrote: post #21

Earlier quoted context omitted.

http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-1...

Nice link, thanks. It doesn't address the problem we bumped into though. When a page needs a significant amount of content updated, sending that as structured JSON to a low powered Android device (or sometimes even an iPhone2 or a non S 3G) and then parsing that JSON and updatng the DOM was _way_ slower than sending back HTML and just replacing an elements innerHtml. For small tasks (like the personalisation {'name':…

What do you mean by 'significant amount of content'? Inserting html is of course faster than rendering in the client, but the javascript involved here is not slow - I haven't seen anything over 15 ms yet for rendering a fairly complicated page (I'm using a resig-style microtemplate, which is probably faster).

Are you perhaps constructing the nodes on the document, instead of doing them off the tree and then inserting/replacing them all at once?

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

#34

Post by bvincent »

mikehal wrote: post #30

What about SEO and accessibility. If the content is sent via JSON it's relying on javascript, no?

Correct, the template can only be rendered on the "client" in cases where JavaScript is available. In other cases (including for the small percentage of users who have turned off JavaScript and mobile devices without JS support) the solution is to render the templates (turn them into HTML) on the server.

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

#35

Post by bvincent »

tunggad wrote: post #26

Does any know how is dust.js compared to Beebole PURE, an JS template engine too. They claim, PURE should be fastest JS template. ^^

As vybs mentioned we'll publish more detail on our evaluation process, for which performance was one of many features we looked at. It may be useful to start by asking what's most important for you/your organization (performance, productivity, ramp-up time, server-side rendering support, etc) since these priorities will likely be different from ours.

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

#36

Post by keltex »

bigiain wrote: post #17
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 t…

It wouldn't have SEO implications because using javascript to load content isn't considered cloaking. (Cloaking is where you present something different to googlebot vs. a live user). It's well known that googlebot does run javascript now:

https://twitter.com/#!/mattcutts/status/131425949597179904

There's also some speculation that googlebot actually runs Chrome and can render anything that Chrome does:

http://ipullrank.com/googlebot-is-chrome/

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

#37

Post by ctek »

prodigal_erik wrote: post #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, t…

http://www.linkedin.com/in/example doesn't use dust.js if it did you would see it imported when viewing source. Am I missing something?

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

#38

Post by prodigal_erik »

simonw wrote: post #28
johnx123-up wrote: post #24

Earlier quoted context omitted.

Can you please elaborate on this?

I imagine the parent means that building single-page apps that require a full DOM+JS implementation is bad for the Web, because it cuts content off from being accessed by anything other than a full modern browser running several million lines of C++. See also my answer to this question about single-page apps on Quora: http://www.quora.com/What-exactly-is-a-single-page-applicati...

An enormous pig of a browser would be bad enough, but you also have to run the client js served by site X, because nobody else has code that's always going to be compatible with today's revision of the site X API. And if you want any behavior that isn't baked into the site X client js, you're just boned. That's why I liken this trend to the client/server days, when you were stuck with one terrible client you couldn't fix—which is what I thought the web had saved us from.

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

#39

Post by akavlie »

efsavage wrote: post #29
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).

Are you using some old version of JSP? Not unlike many other mature technologies, many times people are just victims of some arbitrary corporate standard and not the tech itself. As far as limited, I looked at Django strictly for it's vaunted templating prowess and didn't see anything that isn't easily reproducible in JSP. There could be some magic there but I missed it. For verbosity, sure, fn:toLowerCase(string) is…

Version 2.0 (current version is 2.1). Apparently upgrading is not trivial (due to Spring framework or whatever... I don't know, I'm not familiar with the Java stack).

You mention an example where JSP fares best; there are a lot of examples that don't come out looking too great though, such as time/date/decimal conversion, the obnoxious syntax for if/else, etc. A lot of Django's other filters just don't exist in JSP.

But that aside, there are larger scale issues -- composition of templates via blocks in Django/Jinja, which is a lot easier and more flexible than Apache tiles; the lack of auto-escaping in JSP; and the forced XML syntax, even at the expense of valid HTML (see what it does to script includes or empty divs, without a in between).

Post reply on HN