If I really need HTML includes for some reason, I'd reach for XSLT. I know its old, and barely maintained at best, but that was the layer intentionally added to add programming language features to the markup language that is HTML.
My main gripe is a decade(s?) old Firefox bug related to rendering an HTML string to the DOM.
That may be a fairly specific use case though, and largely it still works great today. I've done a few side projects with XSLT and web components for interactivity, worked great.
This bug is specifically about <xsl:text disable-output-escaping="yes"> not working in Firefox. How is disabling output escaping relevant in regards to sharing templates between pages?
> The only combination that fails to render these entities correctly is Firefox/XSLT.
Which is one good reason not to adopt XSLT to implement HTML includes. You just don't know what snags you'll hit upon but you can be sure you'll be on your own.
> Bug 98168 (doe) Opened 24 years ago Updated 21 days ago
Well it does look like someone's still mulling over whether and how to fix it... 24 years later...
I think XSLT is still a reasonable technology in itself - the lack of updated implementations is the bad part. I think modern browsers only support 1.0 (?). At least most modern programming languages should have 3.0 support.
Firefox has a very old bug related to rendering an HTML string to the DOM without escaping it, that one has bit me a few times. Nothing a tiny inline script can't fix, but its frustrating to have such a basic feature fail.
Debugging is also pretty painful, or I at least haven't found a good dev setup for it.
That said, I'm happy to reach for XSLT when it makes sense. Its pretty amazing what can be done with such an old tech, for the core use case of props and templates to HTML you really don't need react.
