I don't even know why things like templating and inclusion are not just part of the core web stack (ideally declaratively with no JS). There should be no need for an external tool or build process or third-party framework.

▲

skydhash 5 days ago | parent [-]

Html is rendered document. It’s ok to write it if you only need one document, but it’s better to use an actual template language or some generators if you’re going to have the same layout and components for many pages.

You’re asking to shift this job from the editor (you) to the viewer (the browser).

▲

lenkite 5 days ago | parent [-]

Maybe it was a "viewer" in the 90s. The viewer is not a viewer - it is a full fledged application runtime that has a developer environment and media stack, along with several miscellaneous runtimes. A standard template language and document inclusion feature is very small peanuts compared to that. A teeny house compared to the galaxy already built-in - with several planets worth of features being added yearly.

▲

cestith 4 days ago | parent [-]

You both make good points, and I come down on the side of adding some template mechanism to web standards. Of course, that all starts with an RFC and a reference implementation. Any volunteers?

	▲	lenkite 4 days ago \| parent [-]
		Would raise my hand to volunteer for the reference implementation. I guess it would need to be in C++/Rust ? RFC, however, involves way too much talking and also needs solid networking amongst the web crowd. Not qualified for that. For a template language, it would be better to copy a subset from an existing de-facto standard like jinja2 which already has a lean, performant subset implementation at https://github.com/Keats/tera. Document/template inclusion model should be OK now in modern era thanks to HTTP/3. Not really sure how that should ideally look like though.