Awesome -- gonna try this. Thanks for the tip! And lit-html looks cool btw.

Update: I'm using importNode() now -- works great too.

Thanks! Hopefully it delivers.

I haven't seen that, actually -- looks very nice. We do render a heatmap already, but I'm learning that heatmaps are very tricky to tune to be most useful/interesting. I will try to learn from that project.

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.

Ha, thanks. It's hard, so no shame for being "stuck". I've iterated on this for over a decade at this point. Still more evolution to come... but I really want this for my family.

It's this: https://tabler.io/admin-template

Still highly unstable between versions, but for being free, it looks really good and is very flexible. I've been pleased with it for this project.

It doesn't actually get any of your data, let alone anyone else's. It's just an organizer, so please elaborate.

Not gonna lie, I like the design of heximal, but by the end of reading the docs I start missing simple php-like templating.

Styles aren't scoped to templates.

You might be thinking of shadow DOM: if you clone your template into a ShadowRoot, then any included styles will be scoped to that ShadowRoot.

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.

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.

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

Thank you. And that proposal seems really interesting. Can I ask for a link if you happen to have one publicly accessible?

What do you mean with shape? Are you concerned about escaping and such?

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.

well one difference is that application/json scripts are still subject to CSP policies

I skimmed through your blog posts, and the WICG proposal, and my main objection to it is making it depend on JavaScript.

There are plenty of ways HTML templating can be done already using JavaScript. The simplest approach of using tagged template literals, as you mention, doesn't even require external dependencies.

The problem with this approach is that it makes JavaScript a requirement for all but static sites, and those doing templating on the server. This shouldn't be the case.

The web as a platform should be flexible, and provide tools to build maintainable web sites and applications without forcing developers and users to depend on a specific runtime. JS should be an optional dependency, just like CSS is today. Even HTML should be optional, as Web Assembly gains traction, and the web browser becomes a software delivery platform.

Furthermore, making what should be a core HTML feature depend on JS is a colossal violation of separation of concerns. HTML modules should be a standalone feature, and we should be able to define a tree of HTML modules, import modules, reuse them, and so on. That should be the core groundwork on top of which templating is built on.

We've had Server-Side Includes and XSLT since the 90s, yet HTML templating should depend on JS? That's just silly.

Besides, there's a strong argument to be made for minimizing logic in templates or avoiding it altogether. Mustache and Handlebars have shown that this can work simply and elegantly. Whenever I see JS inside HTML attributes, I curse whoever came up with the idea. It's awful for legibility, maintainability, and plain sanity.

HTML can be a lot more capable without having to depend on JS. I think the discussion to drive this implementation forward would be well served by first principles thinking, instead of being inspired by modern web frameworks and JavaScript features.

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

[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic...

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

That depends on the subjective definition of "easier", but most of these frameworks use abstractions that are too complex and not worth the value they deliver. They ironically make development more difficult, since there are more moving parts, more concepts to understand, and more things to break, which in turn makes the user experience much, much worse.

The entire idea of writing fake HTML that gets parsed, compiled, and interpreted in JavaScript to manipulate the DOM at runtime is wrong. The concept of a virtual DOM, diffing, reconciliation, and a bunch of related nonsense, is wrong. The insanity of an entire ecosystem of tools built around solving client-side state management. The trend of moving everything, including CSS, to be interpreted in JS is insane. Abstractions like Tailwind that shouldn't exist in the first place, which are then further abstracted away by abominations like daisyUI. The numerous frameworks that promise to blur the line between frontend and backend development, only to fall flat on their face when the insanity of the approach becomes apparent, but not before amassing a significant user base in the process. The fact most web developers have accepted that 100MB+ of dependencies are required to show a "Hello World!" in a web browser. The idea that every web site must be a SPA, and the numerous hacks around that to make it work like a traditional web site. I could go on, and on...

The popularity of these tools and ideas is not an indication that they lead to a sane, let alone optimal, development environment. It just means that the field has become dominated by influencer developers, to the point that junior developers entering the field are not aware of other ways of building web applications. After all, React and Vue stand out in a CV much more than JavaScript. It's practically unheard of to be considered a web developer without having one of these frameworks under your belt, so it becomes a reinforcing loop.

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

That's not true. JavaScript in web browsers is a stable, modern language. HTML has received numerous transformative updates over the years, such as the `template` element we're discussing here. The evolution of CSS has been mind-boggling, and difficult to keep track of. Gone are the cross-browser quirks and incompatibilities, which is mostly due to Google dominating the web, but that's beside the point. Web servers have become more flexible and easier to deploy. And so on.

Frameworks like Datastar prove that web development can be much simpler, and deliver better user experiences in a fraction of the complexity of traditional frameworks. This is not because it reinvents the same abstractions used elsewhere, but because it takes a first principles approach and rejects building on top of the existing pile of abstractions. It leverages proven technologies such as Server-Sent Events, and doesn't reinvent the wheel. If you've seen the demos and examples, the results speak for themselves.

It's not difficult to imagine a similarly simplified workflow becoming standard across web clients and servers. All it would take is an industry-wide push to bring all existing technologies together in a cohesive package. We're not technically far from that, so frameworks like Datastar are still needed, but we definitely don't need the bloated frameworks of yore.

Could you not achieve the same with a <div hidden>?

Why not just use handlebars js?