7 ms·

<template>: The Content Template element

217 points by palmfacehn 1y ago

alserio 1y ago
I was wondering, are template elements a good place to store json data in the page to be consumed by js?
- yuchi 1y ago
  As good as a script element with type application/json.
  - alserio 1y ago
    well one difference is that application/json scripts are still subject to CSP policies
    - unilynx 1y ago
      How so? I don't remember ever having seen issues with this. If anything CSP steers you towards this (instead of inline scripts directly assigning to JS variables)
      - alserio 1y ago
        I thought I knew but it seems that the CSP story is unclear. I couldn't find an authoritative source for either position
        SahAssar 1y ago
        CSP blocks execution/inclusion, but since json does not execute and any json mimetype will not do execution there is no problem. Any CSP-allowed other script can read that application/json script tag and decode it, but it is no different than reading any other data it has access to like any other html element or attribute.
        alserio 1y ago
        That makes sense, thank you
  - joeframbach 1y ago
    I wonder if the browser would attempt to validate the contents of a script tag with type json, versus treating it as a blob that would only be validated when parsed/used. And any performance overhead at load time for doing so. Not at a machine at the moment so I can't verify.
- bsmth 1y ago
  You might be interested in data attributes for this use case https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use_data_attributes https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use... although it depends on the shape of the JSON data you had in mind.
  - alserio 1y ago
    What do you mean with shape? Are you concerned about escaping and such?
    - bsmth 1y ago
      I can imagine if it's deeply nested data, your markup might get complex, but the structure of the HTML doesn't have to mirror the JSON. There's other examples here which might illustrate more how this can look: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/data-*#usage_notes https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
      - alserio 1y ago
        Thank you. I was looking at a generic way to pass configuration data to custom elements where I cannot know the shape in advance, since another dev can have different requirements. I support data attributes for simple types but i was wondering if allowing arbitraty json objects via other means could be feasible.
        hunter2_ 1y ago
        Since JSON is a subset of JavaScript, you can just use a script element, and including the json mime type certainly doesn't hurt: <script type="application/json" id="myJSONData"> { "name": "John Doe", "age": 30 } </script> <script> const data = JSON.parse(document.getElementById('myJSONData').textContent); console.log(data.name + " is " + data.age); // John Doe is 30 </script> Note: The JSON data must exist literally within the script element. If you try using a src attribute to request it from elsewhere, the response will not be available via textContent or any other mechanism [0], and at that point you just need to fetch/ajax/xhr it. [0] https://stackoverflow.com/questions/17124713/read-response-of-a-file-called-with-script-src-tag-from-external-sever https://stackoverflow.com/questions/17124713/read-response-o...
- Gualdrapo 1y ago
  For my portfolio (miler.codeberg.page) and the refactor&redesign I'm doing of it (that I hope to finish soon!), I feed some <template>s with data coming from a json that acts like kind of a database. I feel the process of querying nodes and setting their data is still a bit rudimentary in plain JS and it should be a pain in the ass for huge datasets or lots of nodes, but at least with modern JS it is not necessary to fetch the json with a XMLHTTPRequest or something - it can work importing it like a regular JS module, so at least there's that.
- jfagnani 1y ago
  No. I would use <script type="-json"> <script> parses its contents as text, whereas <template> parses as DOM. This means you don't have to escape `<`, just `</script>`. Myself and some browser engineers been working on proposals to allow for inline modules, including JSON, that are importable into other modules via regular import statements. This is why I recommend the "-json" type - so it doesn't collide with a future native "json" type.
  - SahAssar 1y ago
    Why not use a somewhat proper mime type like `<script type="application/mytype+json">` or similar? Seems like your suggestion is not what the spec recommends: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type https://html.spec.whatwg.org/multipage/scripting.html#attr-s...
    - jfagnani 1y ago
      My understanding is that in implementations any unknown type creates a "data block", which is just unprocessed text.' I wouldn't use application/json just in case browsers start supporting that and it has different semantics than whatever custom thing you might do, causing a webcompat issue when the native feature rolls out. Although with JSON, it's pretty unlikely that there would be any differing semantics. JSON modules in JS are just JSON blocks with no special additions and no named exports. That's what inline versions would be as well.
      - SahAssar 1y ago
        But wouldn't a subtype like `mytype` in my example (`application/mytype+json`) still be be a valid mime-type and still avoid your concerns? I've used these before.
  - alserio 1y ago
    Thank you. And that proposal seems really interesting. Can I ask for a link if you happen to have one publicly accessible?
mvdtnz 1y ago
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.
- dexwiz 1y ago
  I think it's designed more for web components.
- tehbeard 1y ago
  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/Elements/slot https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- anaisbetts 1y ago
  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 1y ago
    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 1y ago
      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).
mholt 1y ago
I'm using the <template> tag heavily in Timelinize[0], which has a fairly sophisticated UI that I'm writing in vanilla JS -- not even jQuery. I use a few libraries (for mapping, datetime, and Bootstrap+Tabler for some nice styles), but that's it. I wrote some boilerplate JS, yes, but I have complete control over my frontend, and I understand how it works, and I don't need to compile it. Anyway, it works well so far! The <template> tag is a great way to lay out components and then fill them in with simple JS functions. One nuance is documented in my code comments: // Ohhhhhh wow, we need to use firstElementChild when cloning the content of a template tag (!!!!): // https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template#avoiding_documentfragment_pitfalls // I spent way too long on this. const elem = $(tplSelector); if (!elem) return; return elem.content.firstElementChild.cloneNode(true); Once I figured that out, it's been smooth sailing and very powerful. Oh, but I haven't cleaned up my code at all yet because I was just experimenting/hustling, so it's a bit spaghetti :) If you go looking, don't mind the mess. --- [0]: https://github.com/timelinize/timelinize https://github.com/timelinize/timelinize - a self-hosted application for bringing together all your data on your own computer and organizing it onto a single timeline: social media accounts, photo libraries, text messages, GPS tracks, browsing history, and more. Almost ready for its debut...
- mariusor 1y ago
  I considered vanilla template initially for building my ActivityPub frontend[1], but in the end the sugar that lit-js adds on top of web components seemed worth the file size overhead. [1] https://github.com/mariusor/oni https://github.com/mariusor/oni
  - jfagnani 1y ago
    Author of lit-html here. Yeah, Lit's tagged template literals and render() method are basically a shorthand for making a <template> element, marking the spots where expressions go, cloning the template, then filling in those sports.
- jfagnani 1y ago
  You should use document.importNode() to clone templates. Template contents are in a separate document from the main document, which is what makes them inert. importNode() adopts the nodes into the document so they have the correct prototype immediately (which includes custom elements). Otherwise the adopt steps are run when the elements are first attached to the document, which adds another tree walk to the insert/append operation that costs some time. So: document.importNode(elem.content, true); Then you'll have a DocumentFragment you can pull nodes out of. Or just append the whole fragment.
nozzlegear 1y ago
I've been using template elements a lot recently to render products on my wife's photography blog. The product data gets loaded from a headless MedusaJS instance, plugged into a template that matches her blog's theme, and then dropped into the page. I specifically wanted to avoid reaching for something like React since the page load is already pretty heavy with the size of her images. Template's been pretty easy to use in that respect.
- nine_k 1y ago
  Frankly, preact is 4 kB, should be peanuts comparing to any image.
  - nozzlegear 1y ago
    I hadn't considered Preact, I always forget about it honestly. That could be a good compromise. Cheers!
EGreg 1y ago
What exactly is the point of <template> tag? Just to create document fragments? I mean that’s all you can really do with it in HTML. If you are using JS you can attach shadow dom to any element. I guess maybe slots for web components is the other point?
- acdha 1y ago
  I’ve used it to have the server generate fragments not processed in the normal page load which are then used as templates by JavaScript which populates them. That supported fast initial page loads compared to an SPA while being just as dynamic after being loaded. This worked pretty well but definitely had some rough edges which I really wish the standards process could’ve focused on. Things like JSX are so much slower / memory intensive but people use them for convenience and it’d be nice to improve the ease-of-use story.
  - mikojan 1y ago
    Could you not achieve the same with a <div hidden>?
    - Doxin 1y ago
      <template> tags don't do anything to their contents. You can for instance have an <img> tag in there without the image getting loaded, or a <script> tag which doesn't get executed.
- Theodores 1y ago
  Good question. Yes there was all that web components stuff that didn't go the HTML5 way, and the template element is definitely a child of that. Since elements that get into the spec can't be removed easily, they do get repurposed instead over time.
- dspillett 1y ago
  > Just to create document fragments? Largely, I think. Though I've not got around to actually using them yet myself, so take my understanding with a pinch of salt. Compared to doing that with non-displayed HTML tags outside a template there are performance benefits (the parser deals with it differently knowing it isn't intended to be an active bit of DOM yet) and convenience benefits (IIRC the contents are not going to be picked up by querySelector/querySelectorAll). Compared to building document fragments in JS they can be a lot more convenient to create and edit, and keep your design and code less tightly coupled (so a designer on your team who doesn't want to touch JS (or who you don't want messing with your JS!) can easily play with them to a certain extent). Other methods to achieve the same separation may involve an extra build step in deploying your work.
imiric 1y ago
There is untapped potential for building modern web sites by leveraging standard web technologies, such as the template element, and sidestepping a whole bunch of bloated abstractions that plague most modern web frameworks. Essentially, we need the simplicity of old school web development married with modern web features. There are a few modern libraries and frameworks that trend in this direction: Nue, Datastar, Lit. The DX and UX with these is a breath of fresh air. I've experimented with this approach myself with Miu[1]. It doesn't quite integrate with Web Components nicely yet, but it's almost there. I have some bones to pick with the WC standard, but that's a separate matter. My wish is that modern web development can eventually not require any 3rd party libraries or frameworks, just like in the early days. Web developers got used to these because of limitations of native web APIs, but the web has grown leaps and bounds since then. Before the modern workflow became standard, it was magical to open a text editor, and have a functioning web page within a few minutes. No dependencies, no build step, no nonsense. Let's bring that back, please. [1]: https://github.com/hackfixme/miu https://github.com/hackfixme/miu
- jfagnani 1y ago
  I wrote a couple of blog posts on why we should add native templating to the DOM so we'd need fewer libraries. The time is right for a DOM templating API: https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a... What should a native DOM templating API look like?: https://justinfagnani.com/2025/06/30/what-should-a-dom-templating-api-look-like/ https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...
  - quectophoton 1y ago
    I would be very interested in an API similar to the plates[1] library, but with support for event bindings (instead of being just a one-off rendering of plain HTML). My first thought is that it might not be very maintainable, and at best might only be useful for small templates or templates that are heavy on microdata[2]. But there's just something about this type of binding that makes me want to give it a serious chance, at least once, before completely giving up on it. [1]: https://github.com/flatiron/plates https://github.com/flatiron/plates [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Microdata https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic...
jjcm 1y ago
Templates are solid and are slightly more performant than including your html-in-js for webcomponents, but that said I really wish there was some sort of web component file format that incorporated: - The HTML - The JS - The CSS In some sort of a structured way that's easy to load and distribute as a library. I don't like that to use webcomponents the right way, you have to load the logic from an import and then inline the html aspects of it.
- jfagnani 1y ago
  There is a spec issue open for HTML Modules [1] along with a few proposals. The concept needs some motivated champions to see it through. Microsoft has shown some interested in this lately. There are userland single-file component projects, like my Heximal[2] project. Though Hexiaml specifically doesn't tackle the module format - it requires some kind of HTML Module polyfill. I don't think the current situation is so bad though. The container format should mostly be irrelevant to consumers of a component. You need to import the component defintion whether that definition is in a .js file or .html file. Once you import it you use it the same. There should be very few cases where the file format matters. Maybe for use when JS is turned off if HTML-based web components are considered safe to evaluate (their templates might expressive enough to potentially allow attacks). [1]: https://github.com/WICG/webcomponents/issues/645 https://github.com/WICG/webcomponents/issues/645 [2]: https://heximal.dev/ https://heximal.dev/ (Sorry the site is messed up on mobile. I need to fix it!)
  - epolanski 1y ago
    Not gonna lie, I like the design of heximal, but by the end of reading the docs I start missing simple php-like templating.
- marcosdumay 1y ago
  Well, turns out you can just add style tags to the template, and they will be scoped there. It's the only way to get local CSS rules. You can also add script tags wherever you want. They will execute when added to the DOM, but they won't be scoped.
blittle 1y ago
Shopify heavily uses <template> elements with their Storefront Web Components project, except the templates themselves are passed as a child to the web component, that dynamically queries the data necessary to render the template, before mounting the element to the DOM: https://shopify.dev/docs/api/storefront-web-components https://shopify.dev/docs/api/storefront-web-components
BobbyTables2 1y ago
What’s the point of special tags? Isn’t everything just JSON, CSS, JavaScript, and a whole lot of DIV and SPAN elements?
tmalsburg2 1y ago
What problem is this trying to solve and does it actually succeed at solving it? I‘m struggling to see the appeal given that the JS still needs to model the internal structure of the template in order to fill the slots.
- WorldMaker 1y ago
  The Shadow DOM can auto-fill the slots in the case where a web component has slot fillers in the main DOM. You still need JS to invoke/create the shadow DOM, but in that case your JS might be minimal and not need to model the interior structure. But the big problem that template tries to solve is building DOM fragments that are parsed but not "live" in the open documment. Before the template tag there was no good way to do that other than JS and createElement/createElementNS, and that has always been slower than the Browser's well optimized HTML parser. Also, the slot tag does solve a minor problem of being the first tag whose out-of-the-box (browser CSS) behavior is `display: contents;`. It's obviously not a huge lift from the CSS one-liner, but there are still some uses for it even outside of templates.

217 points by palmfacehn 1y ago

alserio 1y ago

I was wondering, are template elements a good place to store json data in the page to be consumed by js?

yuchi 1y ago
As good as a script element with type application/json.
- alserio 1y ago
  well one difference is that application/json scripts are still subject to CSP policies
  - unilynx 1y ago
    How so? I don't remember ever having seen issues with this. If anything CSP steers you towards this (instead of inline scripts directly assigning to JS variables)
    - alserio 1y ago
      I thought I knew but it seems that the CSP story is unclear. I couldn't find an authoritative source for either position
      - SahAssar 1y ago
        CSP blocks execution/inclusion, but since json does not execute and any json mimetype will not do execution there is no problem. Any CSP-allowed other script can read that application/json script tag and decode it, but it is no different than reading any other data it has access to like any other html element or attribute.
        alserio 1y ago
        That makes sense, thank you
- joeframbach 1y ago
  I wonder if the browser would attempt to validate the contents of a script tag with type json, versus treating it as a blob that would only be validated when parsed/used. And any performance overhead at load time for doing so. Not at a machine at the moment so I can't verify.
bsmth 1y ago
You might be interested in data attributes for this use case https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use_data_attributes https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use... although it depends on the shape of the JSON data you had in mind.
- alserio 1y ago
  What do you mean with shape? Are you concerned about escaping and such?
  - bsmth 1y ago
    I can imagine if it's deeply nested data, your markup might get complex, but the structure of the HTML doesn't have to mirror the JSON. There's other examples here which might illustrate more how this can look: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/data-*#usage_notes https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    - alserio 1y ago
      Thank you. I was looking at a generic way to pass configuration data to custom elements where I cannot know the shape in advance, since another dev can have different requirements. I support data attributes for simple types but i was wondering if allowing arbitraty json objects via other means could be feasible.
      - hunter2_ 1y ago
        Since JSON is a subset of JavaScript, you can just use a script element, and including the json mime type certainly doesn't hurt: <script type="application/json" id="myJSONData"> { "name": "John Doe", "age": 30 } </script> <script> const data = JSON.parse(document.getElementById('myJSONData').textContent); console.log(data.name + " is " + data.age); // John Doe is 30 </script> Note: The JSON data must exist literally within the script element. If you try using a src attribute to request it from elsewhere, the response will not be available via textContent or any other mechanism [0], and at that point you just need to fetch/ajax/xhr it. [0] https://stackoverflow.com/questions/17124713/read-response-of-a-file-called-with-script-src-tag-from-external-sever https://stackoverflow.com/questions/17124713/read-response-o...
Gualdrapo 1y ago
For my portfolio (miler.codeberg.page) and the refactor&redesign I'm doing of it (that I hope to finish soon!), I feed some <template>s with data coming from a json that acts like kind of a database. I feel the process of querying nodes and setting their data is still a bit rudimentary in plain JS and it should be a pain in the ass for huge datasets or lots of nodes, but at least with modern JS it is not necessary to fetch the json with a XMLHTTPRequest or something - it can work importing it like a regular JS module, so at least there's that.
jfagnani 1y ago
No. I would use <script type="-json"> <script> parses its contents as text, whereas <template> parses as DOM. This means you don't have to escape `<`, just `</script>`. Myself and some browser engineers been working on proposals to allow for inline modules, including JSON, that are importable into other modules via regular import statements. This is why I recommend the "-json" type - so it doesn't collide with a future native "json" type.
- SahAssar 1y ago
  Why not use a somewhat proper mime type like `<script type="application/mytype+json">` or similar? Seems like your suggestion is not what the spec recommends: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type https://html.spec.whatwg.org/multipage/scripting.html#attr-s...
  - jfagnani 1y ago
    My understanding is that in implementations any unknown type creates a "data block", which is just unprocessed text.' I wouldn't use application/json just in case browsers start supporting that and it has different semantics than whatever custom thing you might do, causing a webcompat issue when the native feature rolls out. Although with JSON, it's pretty unlikely that there would be any differing semantics. JSON modules in JS are just JSON blocks with no special additions and no named exports. That's what inline versions would be as well.
    - SahAssar 1y ago
      But wouldn't a subtype like `mytype` in my example (`application/mytype+json`) still be be a valid mime-type and still avoid your concerns? I've used these before.
- alserio 1y ago
  Thank you. And that proposal seems really interesting. Can I ask for a link if you happen to have one publicly accessible?

mvdtnz 1y ago

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.

dexwiz 1y ago
I think it's designed more for web components.
tehbeard 1y ago
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/Elements/slot https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
anaisbetts 1y ago
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 1y ago
  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 1y ago
    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).

mholt 1y ago

I'm using the <template> tag heavily in Timelinize[0], which has a fairly sophisticated UI that I'm writing in vanilla JS -- not even jQuery. I use a few libraries (for mapping, datetime, and Bootstrap+Tabler for some nice styles), but that's it. I wrote some boilerplate JS, yes, but I have complete control over my frontend, and I understand how it works, and I don't need to compile it. Anyway, it works well so far! The <template> tag is a great way to lay out components and then fill them in with simple JS functions. One nuance is documented in my code comments: // Ohhhhhh wow, we need to use firstElementChild when cloning the content of a template tag (!!!!): // https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template#avoiding_documentfragment_pitfalls // I spent way too long on this. const elem = $(tplSelector); if (!elem) return; return elem.content.firstElementChild.cloneNode(true); Once I figured that out, it's been smooth sailing and very powerful. Oh, but I haven't cleaned up my code at all yet because I was just experimenting/hustling, so it's a bit spaghetti :) If you go looking, don't mind the mess. --- [0]: https://github.com/timelinize/timelinize https://github.com/timelinize/timelinize - a self-hosted application for bringing together all your data on your own computer and organizing it onto a single timeline: social media accounts, photo libraries, text messages, GPS tracks, browsing history, and more. Almost ready for its debut...

mariusor 1y ago
I considered vanilla template initially for building my ActivityPub frontend[1], but in the end the sugar that lit-js adds on top of web components seemed worth the file size overhead. [1] https://github.com/mariusor/oni https://github.com/mariusor/oni
- jfagnani 1y ago
  Author of lit-html here. Yeah, Lit's tagged template literals and render() method are basically a shorthand for making a <template> element, marking the spots where expressions go, cloning the template, then filling in those sports.
jfagnani 1y ago
You should use document.importNode() to clone templates. Template contents are in a separate document from the main document, which is what makes them inert. importNode() adopts the nodes into the document so they have the correct prototype immediately (which includes custom elements). Otherwise the adopt steps are run when the elements are first attached to the document, which adds another tree walk to the insert/append operation that costs some time. So: document.importNode(elem.content, true); Then you'll have a DocumentFragment you can pull nodes out of. Or just append the whole fragment.

nozzlegear 1y ago

I've been using template elements a lot recently to render products on my wife's photography blog. The product data gets loaded from a headless MedusaJS instance, plugged into a template that matches her blog's theme, and then dropped into the page. I specifically wanted to avoid reaching for something like React since the page load is already pretty heavy with the size of her images. Template's been pretty easy to use in that respect.

nine_k 1y ago
Frankly, preact is 4 kB, should be peanuts comparing to any image.
- nozzlegear 1y ago
  I hadn't considered Preact, I always forget about it honestly. That could be a good compromise. Cheers!

EGreg 1y ago

What exactly is the point of <template> tag? Just to create document fragments? I mean that’s all you can really do with it in HTML. If you are using JS you can attach shadow dom to any element. I guess maybe slots for web components is the other point?

acdha 1y ago
I’ve used it to have the server generate fragments not processed in the normal page load which are then used as templates by JavaScript which populates them. That supported fast initial page loads compared to an SPA while being just as dynamic after being loaded. This worked pretty well but definitely had some rough edges which I really wish the standards process could’ve focused on. Things like JSX are so much slower / memory intensive but people use them for convenience and it’d be nice to improve the ease-of-use story.
- mikojan 1y ago
  Could you not achieve the same with a <div hidden>?
  - Doxin 1y ago
    <template> tags don't do anything to their contents. You can for instance have an <img> tag in there without the image getting loaded, or a <script> tag which doesn't get executed.
Theodores 1y ago
Good question. Yes there was all that web components stuff that didn't go the HTML5 way, and the template element is definitely a child of that. Since elements that get into the spec can't be removed easily, they do get repurposed instead over time.
dspillett 1y ago
> Just to create document fragments? Largely, I think. Though I've not got around to actually using them yet myself, so take my understanding with a pinch of salt. Compared to doing that with non-displayed HTML tags outside a template there are performance benefits (the parser deals with it differently knowing it isn't intended to be an active bit of DOM yet) and convenience benefits (IIRC the contents are not going to be picked up by querySelector/querySelectorAll). Compared to building document fragments in JS they can be a lot more convenient to create and edit, and keep your design and code less tightly coupled (so a designer on your team who doesn't want to touch JS (or who you don't want messing with your JS!) can easily play with them to a certain extent). Other methods to achieve the same separation may involve an extra build step in deploying your work.

imiric 1y ago

There is untapped potential for building modern web sites by leveraging standard web technologies, such as the template element, and sidestepping a whole bunch of bloated abstractions that plague most modern web frameworks. Essentially, we need the simplicity of old school web development married with modern web features. There are a few modern libraries and frameworks that trend in this direction: Nue, Datastar, Lit. The DX and UX with these is a breath of fresh air. I've experimented with this approach myself with Miu[1]. It doesn't quite integrate with Web Components nicely yet, but it's almost there. I have some bones to pick with the WC standard, but that's a separate matter. My wish is that modern web development can eventually not require any 3rd party libraries or frameworks, just like in the early days. Web developers got used to these because of limitations of native web APIs, but the web has grown leaps and bounds since then. Before the modern workflow became standard, it was magical to open a text editor, and have a functioning web page within a few minutes. No dependencies, no build step, no nonsense. Let's bring that back, please. [1]: https://github.com/hackfixme/miu https://github.com/hackfixme/miu

jfagnani 1y ago
I wrote a couple of blog posts on why we should add native templating to the DOM so we'd need fewer libraries. The time is right for a DOM templating API: https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a... What should a native DOM templating API look like?: https://justinfagnani.com/2025/06/30/what-should-a-dom-templating-api-look-like/ https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...
- quectophoton 1y ago
  I would be very interested in an API similar to the plates[1] library, but with support for event bindings (instead of being just a one-off rendering of plain HTML). My first thought is that it might not be very maintainable, and at best might only be useful for small templates or templates that are heavy on microdata[2]. But there's just something about this type of binding that makes me want to give it a serious chance, at least once, before completely giving up on it. [1]: https://github.com/flatiron/plates https://github.com/flatiron/plates [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Microdata https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic...

jjcm 1y ago

Templates are solid and are slightly more performant than including your html-in-js for webcomponents, but that said I really wish there was some sort of web component file format that incorporated: - The HTML - The JS - The CSS In some sort of a structured way that's easy to load and distribute as a library. I don't like that to use webcomponents the right way, you have to load the logic from an import and then inline the html aspects of it.

jfagnani 1y ago
There is a spec issue open for HTML Modules [1] along with a few proposals. The concept needs some motivated champions to see it through. Microsoft has shown some interested in this lately. There are userland single-file component projects, like my Heximal[2] project. Though Hexiaml specifically doesn't tackle the module format - it requires some kind of HTML Module polyfill. I don't think the current situation is so bad though. The container format should mostly be irrelevant to consumers of a component. You need to import the component defintion whether that definition is in a .js file or .html file. Once you import it you use it the same. There should be very few cases where the file format matters. Maybe for use when JS is turned off if HTML-based web components are considered safe to evaluate (their templates might expressive enough to potentially allow attacks). [1]: https://github.com/WICG/webcomponents/issues/645 https://github.com/WICG/webcomponents/issues/645 [2]: https://heximal.dev/ https://heximal.dev/ (Sorry the site is messed up on mobile. I need to fix it!)
- epolanski 1y ago
  Not gonna lie, I like the design of heximal, but by the end of reading the docs I start missing simple php-like templating.
marcosdumay 1y ago
Well, turns out you can just add style tags to the template, and they will be scoped there. It's the only way to get local CSS rules. You can also add script tags wherever you want. They will execute when added to the DOM, but they won't be scoped.

blittle 1y ago

Shopify heavily uses <template> elements with their Storefront Web Components project, except the templates themselves are passed as a child to the web component, that dynamically queries the data necessary to render the template, before mounting the element to the DOM: https://shopify.dev/docs/api/storefront-web-components https://shopify.dev/docs/api/storefront-web-components

BobbyTables2 1y ago

What’s the point of special tags? Isn’t everything just JSON, CSS, JavaScript, and a whole lot of DIV and SPAN elements?

tmalsburg2 1y ago

What problem is this trying to solve and does it actually succeed at solving it? I‘m struggling to see the appeal given that the JS still needs to model the internal structure of the template in order to fill the slots.

WorldMaker 1y ago
The Shadow DOM can auto-fill the slots in the case where a web component has slot fillers in the main DOM. You still need JS to invoke/create the shadow DOM, but in that case your JS might be minimal and not need to model the interior structure. But the big problem that template tries to solve is building DOM fragments that are parsed but not "live" in the open documment. Before the template tag there was no good way to do that other than JS and createElement/createElementNS, and that has always been slower than the Browser's well optimized HTML parser. Also, the slot tag does solve a minor problem of being the first tag whose out-of-the-box (browser CSS) behavior is `display: contents;`. It's obviously not a huge lift from the CSS one-liner, but there are still some uses for it even outside of templates.