Edit:
The path we're on just seems so obvious I kind of just want to skip ahead and get it over with.
- Developers and content publishers love the ergonomics and control of just shipping WASM binaries that paint to a canvas and it becomes the de facto standard.
- After 2-3 years of everyone's computer being used to surreptitiously mine crypto everywhere they go we re-learn the lessons of Java applets.
- In comes browsers that require signed WASM binaries for your protection.
The world is an app store. Curtains.
Google especially is in a position to fix most of these things if they wanted to. They even have the best test-data of any company. But they choose to side-step some of these problems by introducing another, completely new technology and then a small team of people goes on to hack something useable using this technology as if they were a small startup. The problem is, Google is basically a collection of teams with very different focus points. Some are paid to develop new technology no matter if they want it for a specific product. Other people are paid to "improve" an existing product, e.g. Google Docs and have to use what is available. Any kind of exchange of information between teams is a friction and blocks things from being improved.
At OrgPad, 10% of CPU time is the maximum we can use if we want a smooth experience. The rest is eaten by the browser and inefficiencies there. I don't think we are alone in stepping over bugs, idiotic APIs and implementation differences everywhere all the time. The fix is not to delegate most of the work to the web developer but for the browser and web standards people to step up and do a thorough job with existing stuff.
I think the biggest issue is that things kept on being tacked on the primitive specification to solve ever evolving needs. The browsers themselves are written in languages that are meant to go fast - which is important for drawing of elements, rebuilding trees, etc - but not good for doing concerted async operations in a structured fashion. Just looking at those codebases makes you want to stab your eyes with a fork up to your brain.
In my, very valuable, opinion, a re-assessment of what HTML is (ignoring the name, and treating it as the language of the browser instead of hyper text) and what at web page can be - along with a browser designed to be multi-tabbed, async by nature, supporting advanced non-tree based layouts (maybe still trees, but trees that could be part of zindexed layers? detached layers that allowed for interaction handlers separate from the visual elements?) in a language that has tools to model those behaviours, could probably re-use all the lessons from HTML, CSS and JS apps.
Of course, it would still be like building everything again - but I'm not sure wasm/canvas blobs is a better solution long-term.
Edit: however, replacing HTML+CSS with a canvas is absolutely a step in the wrong direction. I'm advocating for a richer Web, not a stream of pixels controlled by Google.
What these have in common that is missing from HTML/CSS/DOM is a significant library of controls and layouts.
You mean, abandoning web applications and migrating to network-delivered desktop applications?
Because nothing 'web' remains about them: no HTML, no links, no open standards.
Web developers are the only people who actually want this. Its not something that would benefit society / users.
Performance is a poison chalice. Many, many people were won over by Chrome's blistering speed. Now they won't have proper ad blocking.
Chromium browsers do not allow you this choice. There, the philosophy seems to be that the web is a designer-driven layout medium and that the viewer should not have accessibility choices.
Btw, some of the "sites worse", if you're referring to Google, that's them just breaking things intentionally. You can sometimes work around it by specifying a different useragent and then things are fast again until they change things again.
As a browser, Firefox is standards compliant. I agree there are many applications that use a web interface as the GUI and a bunch were coded for IE6 or IE6 with ActiveX and don't display well (or at all) in Chrome. It really depends, but the problem isn't that Firefox follows standards, but that the developers did not follow standards.