Before I started developing Rails I always used JSON + client side templates which were constructed in pure jQuery and really tedious.
Then, with Rails, I asked myself, why would I want to have the template somewhere in the middle of a JS file where it isn't even recognizable as an HTML template at first sight? Why not have it, like all the other views, in one convenient place? Furthermore, often you have a partial you render on the server side and with some AJAX you send more entities of this partial to the client. Having this partial twice is really tedious if you wan't to tweak the HTML.
I'd also be interested in some up-to-date guides on this. I've always used the .js.erb method Fowler talks about because it's what I see Ryan Bates do in his Railscasts (the last screencast Bates used this method is in [#240][1]).
Is anyone using pure.js? That's been one on my radar since they use pure HTML templates with JSON models. I don't think it does data binding to update the template automatically after the first render if the model changes, but apart from that, it seems preferable to using custom templates like jQuery or Mustache etc.
I wrote it. What makes jQuery and Mustache preferable? I know pure.js is different, but having the HTML clean of any tags or logic is something new and very flexible.
That's what I was saying. From what I've seen, pure.js does seem preferable to using Mustache or jQuery templates. I was curious if anyone else had other feedback after using it.
The reason I am considering it is to be able to use Ruby erb templates on the server to initially populate data on a page, then use pure.js and its directives to treat that same HTML as a javascript template.
With mustache or jquery templates and everything else I've seen, you're tied to rendering at least some basic empty HTML first, then populating it with javascript templates once javascript is ready.
I've messed around with it some and it seems to work fine. I guess my question is why isn't everyone doing it this way? :)
I guess people feel at home with a double-brackets template engine. It mimics what exist server side for ages.
A pity as HTML in the browser is a DOM, not a sliced string.
I like to use a combination of these. There is no wrong way or right way, just the way that gets you done fast, and maintainable. You may begin using one way and find it may be easier trying another way, depending on what you're trying to do. The great thing is the flexibility.
Sounds to me like there would be a trade-off between network latency (delivering HTML ⇒ possibly more network traffic) and a number of string operations & DOM manipulations. Given how fast browsers are at the latter lately, I would imagine client side rendering could be the faster option — but let’s look at the real numbers before deciding, I suppose.
Agreed. Client side rendering for most things is instant. Client side rendering scales better than server side, in my opinion. 1 user or 1,000 users using your website, will not affect the rendering time on the client's machine (just the data transfer times), but will affect the rendering time on the server.
actually i believe the right question would be "in which scenarios does it make sense to deliver them rendered, and in which scenarios does it make sense to render on the client"; which was the intention of my original question.
based on the responses it's clear that my question sounded like a leading one. it was not and i employ both methods actively.
I see this one come up time and time again, Accessibility is not implicit to server side rendering and is easily managed via client side rendering. It is one of my companies specilizations we do client side web app accessibility and to be honest building an accessibility layer with client side logic is far easier than dealing with it via the degree of separation that the server creates. There are many tricks that we use to fool JAWS into doing what we want that are just not available via server side rendering. Accessibility is not hindered by client side rendering if anything it can be enhanced.
surely. the first reason is clear to me. i use client side transformations for this purpose.
performance was admittedly awfully misdirected in a general context. i suppose my situation is unique; several templates on my app require complex logic or additional requests based on properties of the initial request. this is where you start to see it get hairy.
again though, admittedly not the normal scenario. i appreciate you taking my question literally, as it was meant.
[1] https://gist.github.com/719080