3 ms·

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 h

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...)