3 ms·

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

by castis 16y ago

jules 16y ago
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.
- turtle4 16y ago
  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?
  - bgrins 16y ago
    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.
  - jules 16y ago
    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.
peregrine 16y ago
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.
- lolyaright 16y ago
  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.
bgrins 16y ago
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.
kls 16y ago
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 still, for the life of me, cannot understand why this is used. Why would you leave the users environment responsible for templating?

by castis 16y ago

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

jules 16y ago

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.

turtle4 16y ago
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?
- bgrins 16y ago
  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.
- jules 16y ago
  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.

peregrine 16y ago

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.

lolyaright 16y ago
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.

bgrins 16y ago

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.

kls 16y ago

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.