That's not an argument that client-side includes shouldn't happen. In fact HTML already has worse versions of this via frames and iframes. A client-side equivalent of a server-side include fits naturally into what people do with HTML.
Some content is already loaded asynchronously such as images, content below the fold etc.
> HTML is really just a markup syntax, not a programming language
flamebait detected :) It's a declarative language, interpreted by each browser engine separately.
<html src="/some/page.html">, <div src="/some/div.html">, <span src="/some/span.html">, etc.
Or create a new tag that's a noun like fragment, page, document, subdoc or something.
Surely that's no less markup than svg, img, script, video, iframe, and what not.
Nor is this something unique to SGML. XML is also a "markup language", yet XInclude is a thing.
touchay!!
> considered to be server-side
Good point! Wouldn't fetching a template partial happen the same way (like fetching an image?)
I always assumed it stood for my initials.
HTML is a markup language that identifies the functional role of bits of text. In that sense, it is there to provide information about how to present the text, and is thus a presentation format.
It is also a document description language, because almost all document description languages are also a presentation format.
Exactly! Include makes perfect sense on server-side.
But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are
1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable.
2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism.
Having said that...
I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible.
It's "solved" only in the sense that you need to use a programming language on the server to "solve" it. If all you are doing is static pages, it's most definitely not solved.
That's "using a programming language to solve the problem", isn't it?
> It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.
What work do client-side includes have to do other than fetching the page (which will get cached anyway)? It's less work to have a `<include-remote ...>` builtin than even a simple Makefile on the server.
Fetching another resource is expensive. It's another round trip, and depending on many factors it could be another second to load the page. And if the HTML includes other nested HTML then it can be much slower.
This is the exact thing we try to avoid when building websites that perform well. You want as few chained requests as possible, and you want the browser to be aware of them as soon as possible, with the correct priority. That way the browser can get the important stuff needed to display content fast.
Including HTML client side for templating is just wasteful, slow and dumb from a technical standpoint.
Every client would have to do another request for each include. It would literally be many thousands of times slower(or worse) than doing it locally where the templates can be in memory as you render the pre-render the pages. You also save a ton of CPU cycles and bandwidth, by not serving more files with additional overhead like headers.
Yeah, it's not. I'm doing client side includes and the includes get cached by the browser. I'm sure I would have noticed if my pages went from 1s to display to 1000s to display.
If you have a site/webapp with (say) twenty pages, that's only two extra requests for both header and footer.
One drawback though would be that one indeed would have to maintain dependencies, which would be error prone beyond simply adding headers and footers... I wonder if one could (ab)use CPP [1] and its -M option to do that.
An additional request is another round trip. That can be very slow. Average TTFB on the internet in the US is ~0.7 seconds.
It's much faster to send it as part of the same request as you then don't have to wait for the browser to discover it, request it, wait for the response and then add it.
A build process does not have to be complicated, at all. If you can write HTML then using something that can simply read the HTML includes you wish existed and swap it with the specified filename is trivial.
Ofc, the idea has many other issues, like how to handle dependencies of the included HTML, how to handle conflicts, what oath to use and many more.
> the problem is a solved one
is a sure-fire way to know that a problem is not solved
As the article says, the problem is a solved one. The "includes" issue is how every web design student learns about PHP. In most CMSes, "includes" become "template partials" and are one of the first things explained in the documentation.
There really isn't any need to make includes available through just HTML. HTML is a presentation format and doesn't do anything interesting without CSS and JS anyway.