17 comments

[ 2.7 ms ] story [ 37.6 ms ] thread
I was wondering, are template elements a good place to store json data in the page to be consumed by js?
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.
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 - 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...

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.
Frankly, preact is 4 kB, should be peanuts comparing to any image.
I hadn't considered Preact, I always forget about it honestly. That could be a good compromise. Cheers!
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?

Alpine.js uses <template> tags for if statements and for loops with stateful data. E.g. <template x-if="myVariable === 1"><div>1</div></template>

Which is a simpler way of thinking about templates, rather than slots and fragments.

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

> 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.

If you listen to people actually building frameworks (Solid, Preact, Vue, Svelte), you'll learn that "modern web features" have very few actual features that make development easier. All frameworks would absolutely love if they could replace "bloated abstractions" with actual built-in browser features. Too bad, all of those features are built in complete isolation from what anyone but a very small group of Chrome devs want.

> Web developers got used to these because of limitations of native web APIs, but the web has grown leaps and bounds since then.

It hasn't. At least not in the direction you want.

> No dependencies, no build step, no nonsense. Let's bring that back, please.

Nothing stops you from doing that now.

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.

Salesforce actually had a really nice module format called LWC that does that. Also supports one way binding. Too bad they never championed outside of customer use.
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
What’s the point of special tags?

Isn’t everything just JSON, CSS, JavaScript, and a whole lot of DIV and SPAN elements?

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.