Reading the first example I'm not really seeing what gains I get from this. It's just as much work to create a table row using the template as doing it from scratch.

▲

anaisbetts 2 days ago | parent | next [-]

Of course, the goal of the example is to teach using an example that makes sense logically. Templates can be arbitrarily large and obviously as the template gets bigger, the difference between it and manual `document.createElement` calls gets much larger.

▲

rendaw 2 days ago | parent [-]

The difference in what? TBH I don't get the purpose either. You have to use javascript either way, and it's trivial to do make a shorthand for `document.createElement` that sets properties and adds children... maybe 10 lines per project.

I thought it was an optimization, but benchmarking `document.createElement` was significantly faster (firefox).

And then having `template` in your html means that changes to the template/use are less local.

I feel like this is an improvement that only makes sense if you're neck deep in the react world.

	▲	WorldMaker 2 days ago \| parent [-]
		The React world is still deep in `document.createElement` and doesn't seem to be investing in the template tag any time soon. I don't know what your benchmarks were exactly, but my benchmarking (also primarily in firefox) shows cloning templates is much faster than `document.createElement` for many tree shapes I was encountering. (Not micro-benchmarks of one element or so at a time, but the tree contents of entire components and "pages" at a time.) That's before learning of a performance tweak I'd missed from reading this thread today (`document.importNode` for template contents cloning to avoid multiple tree walking passes to attach the clone to the document).

▲

tehbeard 2 days ago | parent | prev | next [-]

The example is a contrived *simple* example to get the point of it being easily cloneable into DOM nodes you then manipulate.

Maybe a more understandable example for you would be it's use in conjunction with <slot>, shown here: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

▲

Spivak 2 days ago | parent | prev | next [-]

I agree, this seems more complicated than just defining your template in JS. You have to use JS to interact with them anyway and it's basically a mapping between some well-known strings and a factory to create a DOM node except less flexible. The advantage seems to be only if you don't interact with your templates in JS and use them inline in your HTML.

▲

epolanski 2 days ago | parent | prev | next [-]

Can't understand the point of a react/Vue hello world either, they are more verbose than just writing the html.

▲

phartenfeller 2 days ago | parent | prev | next [-]

Think of a large template with many attributes like classes and structure. When you want to render this multiple times you just have to update a few things for the unique instance instead of recreating the structure and classes over and over.

	▲	palmfacehn 2 days ago \| parent [-]
		This, and separation of concerns. HTML stays in HTML or your preferred SSR template where it belongs. Another reason I like <template> is the ease of prototyping. A very straightforward approach is to mock up your HTML+CSS with placeholders of what your populated elements might look like. Instead of translating that into JS element generation code, you can simply remove the populated data and enclose the barebones element in a <template> tag. Back in JS, you might have a simple initializer to add these elements as needed and a function to (re)populate them. Simple, to the point and no libraries or frameworks required.

▲

dexwiz 3 days ago | parent | prev [-]

I think it's designed more for web components.