5 ms·

HTML is one of those things that sounds easy to write, except almost nobody knows how to do it or why they should. At best people are super ecstatic when they

HTML is one of those things that sounds easy to write, except almost nobody knows how to do it or why they should. At best people are super ecstatic when they can figure out how to make it visually pleasing. The point of semantic HTML is that it benefits everybody equally by providing well described content for all readers. This is the purpose of accessibility. For visual readers this means the browser provides some default presentation that enhances the quality of output with minimal effort to the developer. For users reliant upon screen readers it means the content is communicated with greater precision and clarity. For bots it means stronger acceptance of your content versus other competing sites. Honestly, HTML is past its prime. Most developers cannot be bothered to figure this stuff out, and cannot be figured how to use the browser's compile target (the DOM), and so much more. Instead most developers are entirely reliant on enormous frameworks and HTTP to do absolutely everything for them. Its like reading a menu is too challenging so instead buying the restaurant and kitchen staff. Its exchanging one set of problems for another at 10x the expense and then crying when people point this out. None of this is challenging, but... the world is filled with non-challenges that people would rather go to war to avoid.

AlienRobot 3y ago
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.
eternityforest 3y ago
The giant frameworks are used because so much of what we're doing is apps. Imperative stuff sucks once you've tried declarative. I'm not sure why we have CSS frameworks that require buttons to have a "btn btn-filled btn-solid" class though, and be wrapped in a form-control in a control-group in a form-group-container.... semantic still works fine.
- austin-cheney 3y ago
  The giant frameworks are used solely for employers to ease candidate selection and not have to invest in training. The only business goal is to put dynamic text on screen. Many developers naively believe these frameworks are there to empower them without realizing they have become commodities or that they are unemployable and hopelessly incompetent without complete reliance upon these frameworks.
  - NAHWheatCracker 3y ago
    You might have a point, but if the frameworks didn't exist, couldn't employers commoditize around knowledge of the base HTML? In my view, frameworks are the result of someone realizing that an abstraction is easier to work with. Just like we don't write in machine code or assembly code much anymore. This seems like a simpler explanation than a conspiracy by "employers" to commoditize software development.
    - austin-cheney 3y ago
      No, absolutely not. Web technologies are now well described and well formalized, but they are built upon extremely sloppy foundations. This results in multi-paradigm technologies that work extremely well and play well together, but architecturally and stylistically are all over the place. Worse, most people are not formally educated to execute on these technologies and simply guess at correctness. If you are both smart and well experienced that expressive flexibility is not an impediment at all, you can independently find correctness through independent research and experience, but most people lack both the intelligence and experience necessary to overcome this hurdle. Let me explain it like this. Writing software is just another form of writing. Writing, at least on a very simplistic level is something everybody should be capable of achieving with even the most modest and basic of elementary education. Yet, most people cannot do more than write shopping lists or granular syntax like filling out forms or writing small letters. The effort to achieve something actually original is not great, but its entirely reliant upon a high level of openness which is tightly coupled with high intelligence, and most people don't have that. Even worse is the ability to do it often enough as required for employment requires high industriousness and there is absolutely no correlation between industriousness and intelligence, which means intelligence alone is not a sufficient predictor of success. The problem is then expectations to achieve original output are inversely proportional the availability of people to do the work even for the smallest of tasks. Compensation does not make up for this, not even close. For one thing the demand for the requisite labor is too high. Secondly, most of this output requires extremely low effort and most employers cannot bring themselves to pay extremely high incomes to tiny repetitious tasks even if few people are capable of doing it well. Third, even if they were willing to pay in excess of $300,000 for a person to put text on screen 2 hours a day the greater concern is how to replace that person should they get hit by a bus. The high salary, even for low cost geographies, is not a stretch after consideration for recruitment and benefits and so forth, so other factors become greater constraints. The solution business has settled upon is to architecturally constrain the effort, even at great expense. Then everybody must do things the same certain way and do so without any investment of training on the part of the employer. The output can be garbage, but if the developers are commodities at least the cost of continuity remains low and finding replacements is dramatically faster.

AlienRobot 3y ago

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.

eternityforest 3y ago

The giant frameworks are used because so much of what we're doing is apps. Imperative stuff sucks once you've tried declarative. I'm not sure why we have CSS frameworks that require buttons to have a "btn btn-filled btn-solid" class though, and be wrapped in a form-control in a control-group in a form-group-container.... semantic still works fine.

austin-cheney 3y ago
The giant frameworks are used solely for employers to ease candidate selection and not have to invest in training. The only business goal is to put dynamic text on screen. Many developers naively believe these frameworks are there to empower them without realizing they have become commodities or that they are unemployable and hopelessly incompetent without complete reliance upon these frameworks.
- NAHWheatCracker 3y ago
  You might have a point, but if the frameworks didn't exist, couldn't employers commoditize around knowledge of the base HTML? In my view, frameworks are the result of someone realizing that an abstraction is easier to work with. Just like we don't write in machine code or assembly code much anymore. This seems like a simpler explanation than a conspiracy by "employers" to commoditize software development.
  - austin-cheney 3y ago
    No, absolutely not. Web technologies are now well described and well formalized, but they are built upon extremely sloppy foundations. This results in multi-paradigm technologies that work extremely well and play well together, but architecturally and stylistically are all over the place. Worse, most people are not formally educated to execute on these technologies and simply guess at correctness. If you are both smart and well experienced that expressive flexibility is not an impediment at all, you can independently find correctness through independent research and experience, but most people lack both the intelligence and experience necessary to overcome this hurdle. Let me explain it like this. Writing software is just another form of writing. Writing, at least on a very simplistic level is something everybody should be capable of achieving with even the most modest and basic of elementary education. Yet, most people cannot do more than write shopping lists or granular syntax like filling out forms or writing small letters. The effort to achieve something actually original is not great, but its entirely reliant upon a high level of openness which is tightly coupled with high intelligence, and most people don't have that. Even worse is the ability to do it often enough as required for employment requires high industriousness and there is absolutely no correlation between industriousness and intelligence, which means intelligence alone is not a sufficient predictor of success. The problem is then expectations to achieve original output are inversely proportional the availability of people to do the work even for the smallest of tasks. Compensation does not make up for this, not even close. For one thing the demand for the requisite labor is too high. Secondly, most of this output requires extremely low effort and most employers cannot bring themselves to pay extremely high incomes to tiny repetitious tasks even if few people are capable of doing it well. Third, even if they were willing to pay in excess of $300,000 for a person to put text on screen 2 hours a day the greater concern is how to replace that person should they get hit by a bus. The high salary, even for low cost geographies, is not a stretch after consideration for recruitment and benefits and so forth, so other factors become greater constraints. The solution business has settled upon is to architecturally constrain the effort, even at great expense. Then everybody must do things the same certain way and do so without any investment of training on the part of the employer. The output can be garbage, but if the developers are commodities at least the cost of continuity remains low and finding replacements is dramatically faster.