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?
Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
21–30 of 43 posts
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#22Earlier quoted context omitted.
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.
hear hear
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#23Earlier quoted context omitted.
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?
Sure, we'd like to soon write more about this. Node.js and jvm based rhino are the two solutions we are trying out internally. We are building some of our seo use cases with dust templates and server-side rendering. It is quite easy and efficient to reuse the same template for both non seo and seo cases
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#24> 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…
Can you please elaborate on this?
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#25JSP 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...…
If you need pure Speed + compile-time checked Typesafe, then Japid is the nr.1. Very popular under Play! Framework community. The performance is superior, 2x - 3x better than FreeMarker.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#26Does any know how is dust.js compared to Beebole PURE, an JS template engine too. They claim, PURE should be fastest JS template. ^^
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#27Curiously, 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?
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':'John'} example) we could make the JSON approach work, but updating a ~25row 4column list? Not on the cheap Android devices...
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#28> 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…
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...
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#29JSP 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 technically more verbose than string|lower, but marginally so.
Re: Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
#30What about SEO and accessibility. If the content is sent via JSON it's relying on javascript, no?