| The contrarian argument is that this signifies an important truth, that HTML never worked the way it was suppose to. In the same way that we might argue that a misunderstood product is the fault of the designer, not the user, we could argue that developers moving away from HTML is the fault of HTML, not the developers. This has been discussed many times, both here on Hacker News as well as elsewhere. To recap that argument, HTML started life with 2 competing and conflicting goals. One goal was to become a GUI for TCP/IP packets. The other was to provide structured information, as SGML had done for publishing. The conflict was obvious by the late 90s, and then for awhile the good folks at W3 thought that XML would provide the answer. And XML did work at providing structured data, much as SGML had for printing (though the criticism arose that attributes should have been left out of XML, as they were only useful for printing). But when XML was stretched to again try to be a GUI for TCP/IP, the system broke. Somewhere around 2006, Sam Ruby (W3C working group co-chair) shared a wonderful anecdote on his blog that revealed how broken XHTML was. He said that he had sent his daughter an SVG image, and she wanted to share it with her friends on MySpace. But she couldn't. Because MySpace was not XHTML compliant, and SVG could only render on XHTML compliant pages. And yet if he had sent her a gif or a jpeg, she would have been able to share it. Draconian error checking might be great for an information exchange system such as XML, but it did not work for a GUI that had to be somewhat informal. In 2004 Mark Pilgrim wrote the great piece "XML on the Web Has Failed": http://www.xml.com/pub/a/2004/07/21/dive.html Now it is 2016. We are looking back at 25 years of failed experience. We can clearly see that HTML and XML both failed, completely, as GUIs for TCP/IP packets. So developers are being rational. They are "voting with their feet" (actually their minds). They don't learn HTML because they know HTML has failed. What is the best way to create a GUI for TCP/IP packets? I don't know, but nearly all developers agree that Javascript is a better way to get there than HTML. There might be something even better than Javascript, and we should all keep experimenting and learning and trying new things. But HTML has failed, and it is good that developers recognize that. |