3 ms·

I've always felt the main use case of HTML is for a single page document, like PDF. When it's for that, it excels at what it does. But when you have a website w

I've always felt the main use case of HTML is for a single page document, like PDF. When it's for that, it excels at what it does. 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. So for most of HTML's life, we've used the wrong tool for the job, but because it was the only tool we had, we used it anyway. HTML should have had first-class support for templating, in my opinion. The model should be that a page references a template by a URL, and the browser won't render anything until it has fetched the template. But they were adamant in sticking to the isolated document model that hasn't made sense for pretty much all of HTML's applications. I wish Google or Microsoft would come up with a replacement for HTML that was website-aware. It really only needs to replace text/html with text/html2 and have the server send this new markup that is parsed in a different way. Most web technologies could remain the same and it would be a huge leap forward. In fact, considering how much the code generation is done by frameworks anyway, most developers wouldn't even notice they aren't sending normal HTML anymore, just like they wouldn't notice when HTTP2 is being used.

austin-cheney 3y ago
Content is just text, a more expressive form of raw data. It's the organization and description of that data which makes it useful. For example steps in a set of instructions are less valuable than the instructions as a whole when clearly organized as a series of steps. This remains true regardless of the context, format, or means of conveyance. Whether HTML is provided as a full document or in micro-segments with/without templates is irrelevant. This is actually a form of empathy failure. Templates exist as a convenience to developers as necessary to reduce or eliminate code repetition, but your users are reading the inter-working of your source code.
- AlienRobot 3y ago
  I understand, but by this logic, no technology matters so long as it gets the pixels on the screen, because that's what the user ultimately sees. In that case, why even use HTML at all? Just upload a huge JPEG that looks like a page and call it a day. I think HTML vastly outgrew its use case because it kept avoiding breaking backward compatibility. It was obvious from the start, but we patched the lack of built-in templating with frames and then with AJAX.
  - austin-cheney 3y ago
    That depends on how you define a user. In many cases this is too narrowly defined to a specific subset of visual users only and thus may present output that legally qualifies as discriminatory in many jurisdictions. What matters is not what is visually viewed according to a tracking metric but what is cognitively consumed by the intended audience such that it results in dedicated engagement or interaction. Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
  - ungamedplayer 3y ago
    A dynamic document format outgrew it's use case as a document format. Programming separates out presentation and logic (html and JavaScript). This is a good thing. I'd like to see the separation to go further. Locking presentation to logic language is a great way to stifle innovation, it's the same reason why we are not browsing the web through a pdf renderer. I'm sure Adobe would love that timeline.
perilunar 3y ago
> 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...)

austin-cheney 3y ago

Content is just text, a more expressive form of raw data. It's the organization and description of that data which makes it useful. For example steps in a set of instructions are less valuable than the instructions as a whole when clearly organized as a series of steps. This remains true regardless of the context, format, or means of conveyance. Whether HTML is provided as a full document or in micro-segments with/without templates is irrelevant. This is actually a form of empathy failure. Templates exist as a convenience to developers as necessary to reduce or eliminate code repetition, but your users are reading the inter-working of your source code.

AlienRobot 3y ago
I understand, but by this logic, no technology matters so long as it gets the pixels on the screen, because that's what the user ultimately sees. In that case, why even use HTML at all? Just upload a huge JPEG that looks like a page and call it a day. I think HTML vastly outgrew its use case because it kept avoiding breaking backward compatibility. It was obvious from the start, but we patched the lack of built-in templating with frames and then with AJAX.
- austin-cheney 3y ago
  That depends on how you define a user. In many cases this is too narrowly defined to a specific subset of visual users only and thus may present output that legally qualifies as discriminatory in many jurisdictions. What matters is not what is visually viewed according to a tracking metric but what is cognitively consumed by the intended audience such that it results in dedicated engagement or interaction. Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
- ungamedplayer 3y ago
  A dynamic document format outgrew it's use case as a document format. Programming separates out presentation and logic (html and JavaScript). This is a good thing. I'd like to see the separation to go further. Locking presentation to logic language is a great way to stifle innovation, it's the same reason why we are not browsing the web through a pdf renderer. I'm sure Adobe would love that timeline.

perilunar 3y ago

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