Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5

Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5 and web technology in general. The web has many positive aspects but modularity isn't one of them. HTML5 has turned into an unfocused attempt to specify a whole computer from bottom to top - everything from a [virtual] CPU, to programming languages, graphics stacks, text rendering, UI toolkits, MIDI, sockets, storage, Bluetooth, USB and more. Unlike other operating systems, the resulting Chrome pseudo-OS has nearly no extensibility. Attempts to use WebAssembly to hack around this yield mixed results at best given the problems of needing to constantly re-download the modules (cache segmentation), needing to re-JITC the modules and inability to share code (process isolation). Images are a core part of the web's functionality, they were literally one of the first features ever added to HTML. The fact that new image formats can't be added for code maintenance reasons, even when having clearly unique features and interest from major companies, worryingly suggests that the web platform may be heading towards a form of technical bankruptcy. HTML has support for obscure features virtually no web sites will ever use like MIDI or USB support, whilst an upgrade to a core feature that every website uses (except HN of course!) apparently cannot be done any longer. It means implementing a complete yet non-extensible OS stack from top to bottom is a task too large for even the world's largest and richest corporations. In the beginning, the web's architects realized and understood that it wasn't feasible for browsers to implement everything you might want to embed in a web page. The plugins API was an early addition to the platform as a consequence. When it was deprecated, the stated reasoning was as follows: https://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html https://blog.chromium.org/2014/11/the-final-countdown-for-np... "Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base" At the time this sounded wise. But since then tens of millions of lines of code have been added to Chrome (almost all C++) so "reducing complexity in the codebase" seems like a hard argument to make with hindsight. Browsers were capable of running plugins inside their process sandboxes and exploits in Blink are found regularly, so it's not really clear that it made much security difference either. So maybe that's one reason it's getting such a reaction. This JXL incident isn't just about JXL. It's about what it implies for the future. Who will even bother researching new image codecs now, if even Google itself can't get a better codec into the web? It may be time to start thinking about what alternative designs to the web might look like, with a strong focus on modularity and extensibility whilst still taking into account everything that was learned over the past 30 years. I have some ideas already but haven't written them up yet.