100% this, there's no good reason to do this in JS.
Apache has supported Server Side Includes forever. All you need to do is drop an 'include' in your HTML file and Apache will inject the contents in the right place.
<!--#include virtual="/header.html" -->
I don't know for certain but suspect other webservers will have similar functionality.
The benefit of their approach is that they can drop the files into basically any server, and the site will work. Seems like a good tradeoff for the sort of concerns they have.
Upvote for Apache Server Side Includes. Two years ago I was tasked with redesigning an important informational website that never got the proper attention because all devs were occupied with maintaining the different web application stacks. I wanted something future-proof that an intern could update, basically straight HTML and minimal CSS. I replaced anything that would normally use PHP (and in some cases JavaScript) with stuff built in to Apache. It's cool that Apache also supports conditionals.
I mean, that's all cool, except now the next person needs to know (or learn) Apache directives. I would assume that intern is more likely to know PHP or JS. This solution is a compromise at best, and to me it doesn't sound like Apache is a good choice here (granted, there could be other circumstances I am not aware of).
If I received your code I would start by rolling my eyes, then by wasting some time learning Yet Another Technology (TM) that I will likely forget before the next time it comes handy.
In my experience, if you care about maintenance, one should stick to the worn path unless they have a good reason not to.
> It's cool that Apache also supports conditionals.
Indeed, xinclude would be great. Combine that with an HTML-based and declarative web-component solution and it would go a long way to reducing the need for scripting on basic websites.
Sure, but it's about as far from user/dev friendly as it gets. I recently had to make a standalone FAQ-style page and got the idea to use XSL to render it from an XML file (since you can teach any semi-literate person how to write XML in like 5 minutes). Firstly, XSL is so much weirder than any templating engine we're used to, that it took me stupidly long to do the most basic things. Then it turns out, browsers don't include default styles in XSL-rendered documents (no headings, no lists, nothing!), so I had to style it completely from scratch.
Everything in the XML "ecosystem" (XSL, XPath, XDT, SOAP) is so unfriendly that I'm no longer surprised everyone is reinventing these concepts in (unfortunately) JSON these days.
I’ve messed around with generating SVG classes in python and C++ using the XSD schema and while it is pretty good it falls flat on its face for anything complicated like SVG.
Resorted to using the DTD schema as it can support complex things (and that’s what they use for the probably never to be released updated version) through some python hackery to generate a hundred or more classes that takes forever to compile and, strangely enough, actually does what its supposed to do which is represent SVG as a bunch of classes with reading/writing to xml.
I was going through a phase and tried that with rss but it was more hassle than it was worth.
—edit—
Should add the DTD makes things like enums for tags or whatever simple so you can have typed values and property formed xml documents — can’t remember if I ever managed to get that working with the XSD.
Frames trigger bad memories for some older devs for how they were abused but this is really the best way to do it. Doesn't depend on server modules for includes, and even text-mode browsers generally support frames (but many do not support JavaScript).
Pandoc will create self-contained documents with the '-s' switch. It's also pretty easy to use a custom template as well. You can go from markdown (or asciidoc or whatever) to plain but templates HTML with a single command. You then have an HTML file you can stick anywhere.
Golang Templates also offer the ability to do this. I have an entire enterprise site built this way with separate header, footer, toolbar, search box, etc. And it’s silly fast too. We use AlpineJS for client side interactive bits. (edit: typos)
Rather than JS, one can use Caddy's built-in template engine [0] to include headers/footers server-side (but way more powerful than SSI):
{{include "/includes/header.html"}}
No JS, no external build step, still static HTML files -- just pieced together by the server at request-time. Works great [1]. (Or use plain Markdown, and have Caddy's template engine render it as HTML on-the-fly. Your choice.)
Smarty always amused me a bit, with how PHP had started as a templating language but had grown so far from that that people felt it needed a templating language of its own.
I'm kind of wondering why JQuery is needed for that, but I'm not curious enough to dig into nav.html to see why. The navigation looks simple enough. An at-home static site generator that literally replaces a custom tag with the contents of a file using sed would take less maintenance it seems to me than keeping JQuery updated.
There is a modern fervor over tech minimalism/purism where using even a little bit of Javascript, for example, is just a reminder that perhaps the answer all along was to just to use the trade-offs that work for you.
Note, the people in the article were burned by wiki software that went unmaintained during its rewrite from Python 2.7 to Python 3 (afaict). Now they are editing HTML files on a production server. I'm sure getting let down like they did gave them a specific distaste for certain trade-offs that work for the rest of us, but you can also imagine the babies being thrown out with the bathwater like scaling out an article database without revision history.
That said, it tends to be a good thing when you realize a vastly simple solution works for you.
