Honest warning; this is a random brainfart. Take it with a grain of salt, assume it won't ever be a real thing. This prevents you from disappointed. Let's talk html templates. Now you may think that this is slow because all the things JS. But you'd be thinking about something different. I want "static" declarative html templates that the browser applies natively.
So the rationale is pretty simple; we can cache css and js but we can't cache the html sans content. Even though the majority of page weight these days is in fact the html because we externalize the css and js. Why can't we solve this with cachable templates and a declarative list of symbols to replace with actual content? The browser would do a fairly straightforward (tm) injection of said content into the templates.
Now my brainfart is hiding a lot of details of how this would work. In principle you would be able to set a header that loads html templates and injects them into the document at said positions on demand. Something like;
<!doctype html>
<html>
<head>
<link type="html/template" src="foo.htpl" id="my-tpl">
</head>
<body>
<template ref="my-tpl">
<s for="$head">Declarative html templates</s>
<s for="$content">
<p>It's fine to inject more html, I guess</p>
<p>Also because I'm not entirely sure how to properly deal with content like this where it has multiple paragraphs in the same section.</p>
<p>Of course you could also opt for an approach where you put these in an array-like structure instead for such cases.</p>
<p>Because I could envision a future where html should also be separated from the actual content, just like you do with css/js/html now.</p>
</s>
<s for="$menu">
....
</s>
</template>
</body>
</html>
Of course this is just an example. The template would look something like
<h1>$head</h1>
<content>$content</content>
<menu>$menu</menu>
Now I understand that there's a few considerations to be made here. For one; the syntax obviously needs quite a bit of bike shedding. And that's fine. Feature creep will be a problem, but kind of unavoidable in these situations.
A more pressing issue is progressive loading. Obviously having to load the html externally means having to actually load the whole template or content before being able to inject content back into the template. And while we can inline both of them, probably interleaved too, this would make it problematic to serve the content because you wouldn't know whether to serve the template-less file or the interleaved version. There are workarounds for this like cookies or having two different remote resources (with and without) and letting the browser decide. But these obviously come with their own problems. Hey I never said I'd present you a solved problem :)
An upshot to this kind of approach is that the original content remains in the document being fetched. So even if you don't have the template you still have the actual content. That should help with automated tools, maybe even make it easier for them, but that's a different story altogether.
The templates shouldn't be limited to the body. I'd imagine them being a direct inline replacement of the document being loaded. Or at least at the point where the template is actually being used. I guess it would be similar to loading html externally first and then later doing a document.write to literally inject the html.
The example may look trivial, and it is, but try to think of this generically. Look at the source code of popular sites and think of the amount of overhead that html carries on its own.
But also keep in mind this is just a brain fart. It's not thought out well. I'm just fleshing it out as I'm writing it down now. So I'm sure there are serious concerns to be had here. Others than what I've already outlined. This blog post serves more an entertaining purpose with a side of having written it down in case it ever becomes a reality after all. I mean, that'd be fun :)
In a world where templating is already a thing anyways but relatively slowed down by JS semantics it seems to me like declarative templates would be a welcome thing.