3 ms·

> But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense Yeah, don't do that. Use serve

> But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense Yeah, don't do that. Use server-side includes for all the common elements. If your server doesn't support server-side includes then they're pretty easy to replicate with a couple of lines of JS, or via a web component. (But HTML really should have a client-side include tag. The Object and iframe tags sort of work but not properly.) > So for most of HTML's life, we've used the wrong tool for the job Hard disagree. HTML is great for large websites, e.g. news sites and wikis, etc., especially if you have a decent server setup. It's not so good for web apps, but we all know that. > HTML should have had first-class support for templating Would have been nice, but it's easy enough to just do that on the server with SSI or PHP, or XML+XSLT, or any of the many server frameworks.

RugnirViking 3y ago
the author wasn't saying this can't be managed by tools, I believe they're saying its kinda insane that we have tools to automatically assemble huge stacks of html on the server, very little of which is different each time, then send the whole glob over to the user. and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling
- AlienRobot 3y ago
  Yes, I forgot to include it in the original comment, but besides frames and AJAX we also have static site generators, from no-code stuff like Frontpage all the way to Hugo, and server-side templating like PHP, Jinja, etc. These are all solutions to the same problem: HTML lacks this natively. Web browsers had 20 years to provide a solution for literally copying text code and they were quicker to implement WebGL and web assembly... And the worst of all is that the only "templating" solution we got with <template> made the same mistake as frames did: the accessed page is the root and the included code is the children. HTML needs dependency inversion. Just like we include a single bundle.js that controls all pages in a website there should have been a way to include single template.html that defines the layout used through a site, the JS and CSS required by this layout, and other reusable template components too (which, imo, HTML should be to render without needing JS. Seriously, I should be able to write a web-component <my-h1> that unpacks to <div class="h1-wrapper"><h1> without needing JS because that cover 50% of the use cases...)

RugnirViking 3y ago

the author wasn't saying this can't be managed by tools, I believe they're saying its kinda insane that we have tools to automatically assemble huge stacks of html on the server, very little of which is different each time, then send the whole glob over to the user. and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling

AlienRobot 3y ago
Yes, I forgot to include it in the original comment, but besides frames and AJAX we also have static site generators, from no-code stuff like Frontpage all the way to Hugo, and server-side templating like PHP, Jinja, etc. These are all solutions to the same problem: HTML lacks this natively. Web browsers had 20 years to provide a solution for literally copying text code and they were quicker to implement WebGL and web assembly... And the worst of all is that the only "templating" solution we got with <template> made the same mistake as frames did: the accessed page is the root and the included code is the children. HTML needs dependency inversion. Just like we include a single bundle.js that controls all pages in a website there should have been a way to include single template.html that defines the layout used through a site, the JS and CSS required by this layout, and other reusable template components too (which, imo, HTML should be to render without needing JS. Seriously, I should be able to write a web-component <my-h1> that unpacks to <div class="h1-wrapper"><h1> without needing JS because that cover 50% of the use cases...)