On Client Side Templating | Hacker News Reader

On Client Side Templating

blog.rassemblr.com

6 pointsrgbrgb8 comments

Client-side templating has its place when used with proper progressive enhancement. That said, if your template rendering is what's bogging your server(s) down, you really need to reevaluate your choice of template engine.

The problem with relying on the client to handle templating is one of robustness. JavaScript is an extremely fragile runtime, and one JavaScript error in a piece of third-party ad or widget code can prevent any other JavaScript on the page from executing. If you're relying on JavaScript to render your website, that means a bit fat empty page for your users. It happens: http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashB...

You're effectively offloading a critical part of your application to a runtime environment that you do not control and that third party code can break at a whim. I don't know about you, but that would scare the bejesus out of me.

Me? I prefer server-side rendering, with progressively-enhanced client-side rendering where it makes sense (e.g. an AJAX-powered infinite carousel).

Also, you need to be really careful about memory leaks when replacing the DOM wholesale as you recommend in http://blog.rassemblr.com/2011/05/on-client-side-templating-...

Any references to old DOM nodes need to be cleared to avoid memory leaks, and any event handlers not attached to the document object will need to be reregistered.

If only one could rely on JavaScript actually running on a client machine.

If you're looking at things pragmatically (and not, say, dogmatically) then you can rely on JavaScript running on a client machine.

Does it run on every machine? No. Can you ignore the part of the market that doesn't have working JavaScript in the browser? Sure you can.

If someone doesn't have JavaScript, he's either extremely paranoid (and belongs to a really minor minority) or using hopelessly outdated browser (a minority that most likely wouldn't be a good customer anyway).

I don't think any of the major websites (like gmail, google maps, facebook, hotmail, twitter) would work if JavaScript didn't run on the client. If Google Maps can afford to not care about such clients, so can you.

Your point about pragmatism is valid, but in the way that spjwebster speaks about above. JavaScript is just too fragile to depend on for a truly robust application or website.

Lack of JavaScript isn't just about the minor percentage of users that disable, but also about those whose JS resources are blocked or fail to load. What's more, the fact that a single JS error in page can block all other JS from running introduces even more nightmares.

"If someone doesn't have JavaScript, he's either extremely paranoid (and belongs to a really minor minority) or using hopelessly outdated browser (a minority that most likely wouldn't be a good customer anyway)."

With the trend towards mobile devices (as in not chained to a desk) this introduces far more complexity to whether client-side rendering is viable than whether "javascript is turned on in the browser". (Here's some notes I made about that a few months ago: http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski... )

The mobile trend also blows a big hole in the article itself: The CPU power of mobile devices is quite well behind that of a laptop or desktop. Probably about 2 or three generations behind. So the perceived performance will still lags behind.

Google Maps works (in a reduced but usable mode) without Javascript.

Sure you're doing less on the server, but seriously, is it going to be significant enough to warrant it? Seriously, if the rendering component of your site is heavy, you're likely to be doing something wrong, or the data you are dealing with is trivially light.

Reply on news.ycombinator.com