4 ms·
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 structu
by 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 agoHere 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 agoThe 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.