> 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.
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++.
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.
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?
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.