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'm really looking forward to Temporal [0] reaching a larger baseline. Between that and a lot of recent Intl pieces we are so close to not needing libraries for much of anything datetime related.
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.
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?
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.
> 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.
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 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.
17 comments
[ 2.7 ms ] story [ 37.6 ms ] threadI 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:
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'm really looking forward to Temporal [0] reaching a larger baseline. Between that and a lot of recent Intl pieces we are so close to not needing libraries for much of anything datetime related.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I guess maybe slots for web components is the other point?
Which is a simpler way of thinking about templates, rather than slots and fragments.
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
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.
- 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.
Isn’t everything just JSON, CSS, JavaScript, and a whole lot of DIV and SPAN elements?