4 ms·

I'm confused by their description of templates as "messy" and their decision to use laconic. Not an opinion that I think is widely held and definitely doesn't

I'm confused by their description of templates as "messy" and their decision to use laconic. Not an opinion that I think is widely held and definitely doesn't make sense to me. (by html templates do they specifically mean ejs/erb type templates versus jade/haml??) Using html templates is good separation of concerns and js just isn't very good at expressing html structure. Jade would have been a much better choice IMO. Laconic does a good job of minimizing the problems with using js to programatically build dom in js but still doesn't come close to a proper templating language.

joestelmach 14y ago
Thanks for sharing your viewpoint. I realize that templates are a popular choice for many, but I view them as an unneccesary layer of indirection. Sort of like printing out an email, hand writing a response, and scanning it back in as a reply. Once your markup has been converted to a document object model, why not embrace it?
- crazygringo 14y ago
  I think it's kind of like the difference between writing in assembly and C. Using a bunch of calls to appendChild() and setAttribute() results in code that is difficult to read, because it's so low-level. You can't "see" the generated HTML, just like in assembly you can't really "see" the code structure. Whereas using templates lets you "see" your HTML, with an easy-to-understand structure. So it's the natural, default choice for ease-of-use and maintenance.
  - TazeTSchnitzel 14y ago
    Well, one style is imperative, one is declarative. Some prefer the former, some the latter. Myself, I much prefer imperative.
- sunkencity 14y ago
  I really like this style of templating, it's pretty close to how Seaside generates it's HTML, but more direct since it manipulates the dom directly. Also using the DOM directly is very fast.
MatthewPhillips 14y ago
Client side templates are a hack, presently speaking. They are inserted into a script tag in the head (usually), so if you are working a single page app you need to include every template for your entire site in the head of the document. It works, but man is it ugly. Then you have to include some bulky library that parses these scripts and compiles them to a function that you'll use later. All this happens pretty fast, but not any faster than just using the DOM apis. I can't find the link, but I believe there is a proposal to standardize client side templating, so hopefully that will make the process a bit cleaner.
- Kilimanjaro 14y ago
  Something like this may unclutter the situation, just use xmlhttprequest to get the templates on demand: //synchronous body.innerHTML = render('blog.html',data) //asynchronous render('blog.html',data,body) render=function(url,data,obj){ if url in cache: use cache var http = xmlhttprequest() http.get(url,obj?async:sync) http.onready: parse data in html if obj: obj.innerHTML = html else: return html }
  - MatthewPhillips 14y ago
    There are work arounds. What we really need is an HTML standard for including templates on a page. Can't we reuse the <link> tag for that? <link href="mytemplate.mustache" rel="template" type="text/mustache" onload="showSnippet()" />
    - Kilimanjaro 14y ago
      I like that, except that templates are used on demand, so onload would be useless. A better way would be to put an id on them and defer their load for when really needed. <link hef='blog.html' rel='template' id='myblog' defer> But still, we don't want to load 50 templates at the same time if the app is big then use one or two in that session, that's why loading them on demand with httprequest might be a better solution. *Besides, being static in nature they would be cached on the server and client for instant access.

joestelmach 14y ago

Thanks for sharing your viewpoint. I realize that templates are a popular choice for many, but I view them as an unneccesary layer of indirection. Sort of like printing out an email, hand writing a response, and scanning it back in as a reply. Once your markup has been converted to a document object model, why not embrace it?

crazygringo 14y ago
I think it's kind of like the difference between writing in assembly and C. Using a bunch of calls to appendChild() and setAttribute() results in code that is difficult to read, because it's so low-level. You can't "see" the generated HTML, just like in assembly you can't really "see" the code structure. Whereas using templates lets you "see" your HTML, with an easy-to-understand structure. So it's the natural, default choice for ease-of-use and maintenance.
- TazeTSchnitzel 14y ago
  Well, one style is imperative, one is declarative. Some prefer the former, some the latter. Myself, I much prefer imperative.
sunkencity 14y ago
I really like this style of templating, it's pretty close to how Seaside generates it's HTML, but more direct since it manipulates the dom directly. Also using the DOM directly is very fast.

MatthewPhillips 14y ago

Client side templates are a hack, presently speaking. They are inserted into a script tag in the head (usually), so if you are working a single page app you need to include every template for your entire site in the head of the document. It works, but man is it ugly. Then you have to include some bulky library that parses these scripts and compiles them to a function that you'll use later. All this happens pretty fast, but not any faster than just using the DOM apis. I can't find the link, but I believe there is a proposal to standardize client side templating, so hopefully that will make the process a bit cleaner.

Kilimanjaro 14y ago
Something like this may unclutter the situation, just use xmlhttprequest to get the templates on demand: //synchronous body.innerHTML = render('blog.html',data) //asynchronous render('blog.html',data,body) render=function(url,data,obj){ if url in cache: use cache var http = xmlhttprequest() http.get(url,obj?async:sync) http.onready: parse data in html if obj: obj.innerHTML = html else: return html }
- MatthewPhillips 14y ago
  There are work arounds. What we really need is an HTML standard for including templates on a page. Can't we reuse the <link> tag for that? <link href="mytemplate.mustache" rel="template" type="text/mustache" onload="showSnippet()" />
  - Kilimanjaro 14y ago
    I like that, except that templates are used on demand, so onload would be useless. A better way would be to put an id on them and defer their load for when really needed. <link hef='blog.html' rel='template' id='myblog' defer> But still, we don't want to load 50 templates at the same time if the app is big then use one or two in that session, that's why loading them on demand with httprequest might be a better solution. *Besides, being static in nature they would be cached on the server and client for instant access.