Hacker News Reader

Comment by castis | Hacker News Reader

I still, for the life of me, cannot understand why this is used. Why would you leave the users environment responsible for templating?

View on HN

Say you have a site that uses a lot of AJAX to make similar calls. Say for instance send message, recieve message. Instead of sending the entire message formatting and all back and forth you send json objects and bind them to jquery templates.

don't forget to herp before you derp!

Seriously, the whole concept he was trying to convey just whooshed over your head so loudly that I could hear it from my home in Maine.

I don't think that it is useful for a standard site, one that needs to be indexed by search engines and needs all of it's content to be available on page load. I have made use of it in single page web applications before, though.

It completely blows hand generation of HTML out of the water for maintainability. You can keep your templates inside of the HTML page using a <script> element with a special type, and keeps a lot of that view logic out of your JavaScript. It also provides a nice alternative to using a hidden element and cloning it, then switching attributes, text, and values.

I don't know for the life of me why you would use either for static templating, use a CMS that publishes flat HTML files to your server farm. It reduces a lot of run-time dependencies and requirements and makes them compile-time concerns. Which as a general rule of thumb is better. For the dynamic stuff well that is where you draw your line server or client. I have become a convinced fan of the client.

I don't really get it either, but one reason I can think of is that it saves some bandwidth because sending the data that gets inserted into the template will probably be smaller than the HTML after templating.

That seems counter intuitive to me. With JS templating, you are sending all the page structure, data, and markers as to how to insert the data into the structure. Without, you are just sending the structure and data. Assuming you are gzipping the output in both cases, which would eliminate the bandwidth of the duplicated structure items, wouldn't the JS templating naturally be longer?

Here is a contrived example, that shows the pros and cons of each, as I see them. Pretend you have an 'link' object in JavaScript and you want to generate the view for that link using templating:

  var link = { url: 'http://news.ycombinator.com, title: 'Hacker News' , extraStuff: someBigObject };

With JS templating:

  <div id='template'><a href='${url}'>${title}</a></div>

  $('#template').tmpl(link);

* Pros: if you have to generate 100 links, you only passed down the template div once. Also, if the extraStuff property is really large, there is no bandwidth spent on sending it up, since it runs on the page

* Cons: if you generate 0 links, you still passed down the template div once. If you have this view defined also in a server side template, you have duplicated view logic (really annoying).

With server side templating:

  $.load('url/to/template', link);

* Pros: If you generate 0 links, no extra data is sent or received. Also, your view logic is all in one place (on the server).

* Cons: If you generate 100 links, there are 100 extra HTTP requests, and you have to deal with timeouts, loading indicators, etc.

The difference is that with server rendered templates you're sending the structure multiple times. For example if you're displaying a list of things, you have a list of n times structure + n times data. If you do it at the client side you have 1 times structure + n times data.

Reply on news.ycombinator.com