Browser authors are on the receiving end of over 20 years of standards all written by people who were not, personally, the ones implementing them, plus a healthy dollop of "code that worked in this one browser once and become a de facto standard", for which the way tables format themselves in all their myriad ways comes to mind, based around whatever was convenient in already-crufty codebases now long dead.

And then all these nightmares get together and interact. And the end users expect this to be fast. And web developers expect to be able to reach into the middle of this epically complicated data structure and tweak a style and have what may literally be the entire page rerender, and they expect that to be fast and easy. And using a language that was never written to be fast. (If anything, Javascript was written to be implemented quickly, if you read the story about where it came from. There was no time to be worrying about how well it could be JIT'ed 10ish years later.)

I don't spend a lot of time wondering why my browser is so slow; I often find myself wondering how it manages to be so fast. The spec for a browser is insane. I definitely believe that a future of browsers will be a combination of web assembly and a much more raw rendering layer that will offer access to font rendering and the OpenGL primitives, and a non-trivial number of the biggest websites will eventually implement their own renderers. I say "a" future because the current web rendering system will be around to the end of my prognostication powers. But I suspect this bypassing of the "legacy" renderer is also ultimately inevitable. Give it about 5 years or so.

At my job, our group recently refactored a file from over 30000 lines down to 17000. I've also seen, on multiple occasions, single methods in Smalltalk applications that exceeded 32KB and therefore broke the compiler! (The egregious sins of Smalltalk shops were weirdly parallel. The egregious sins of Smalltalk vendors were also weirdly parallel, come to think of it.)

Frankly what went wrong was that print media designers got involved and used flash and JS to turn static text into virtual pamphlets etc.

Let put a end to the madness, and say "after 2020, not more in the old apis" and do a clean standard. Then take advantage of the fact html/js have tags that could declare versions, and when a old page show, use the old rendered, and when a new, use the clean one.

By then, most PC/mobile devices are powerfull enough to have 2 renders alive and the transition will be fast for more big/popular sites.

There are multiple versions of ECMAScript, analogous to whether your compiler supports C++11/14/17/etc. It doesn't make sense to say "let's all use ES8" because ES8 is back-compatible (I think). It's up to the browser to decide what to support, and you have the same issues in C++ where some compilers don't fully support feature X.

Then, which APIs do you deprecate? How do you define "old"? Anything prior to stable is a good rule of thumb, but since JS can be loaded locally, people will use whatever they downloaded and that they know works. Some people advise not to use auto-updating CDNs precisely because a patch might break your page. And remember it's mostly down to the API developers to ensure compatibility across major browsers, not vice versa.

There's nothing wrong with vanilla JS. Really we just need to get people to be less excited about using frameworks for tiny projects that don't require them. Or you have problems like e.g. some text transition that requires loading every single version of the typeface.

Eventually, you increase ad infinitum the tech debt, or restart.

I think the cost of the whole web stack is high enough not only for the browser makers but EVERYONE ELSE. Is multiply JS (n-versions) + CSS(n-versions) + HTML(n-versions) * N Browser * N OS.

Now, what other rational option can be offered... push forward and keep doing the same and increase the tech debt? Not exist a way to refactor this?

Understatement of the century for 500.

Web developers - want a clean, extensible, sane system to code against

Major consultancies (e.g. IBM) - want lock-in, wide and cheap talent pool, and minimal changes (unless it's an issue they have)

Browsers - want to render whatever they see fastest and securely

Content developers and end customers - never want to have to update their site that they bought in 1995

So I guess the question is not if its ok for chrome to break the web for half the world its if its ok for chrome to impose this cost on site owners on behalf of users for the benefit of users.

Incidentally while there may be a lot of tiny sites that don't use https aprox 3/4 of page loads are already over https. Making myrandomhomepageaboutcats.com switch to https seems a reasonable cost for making the rest of the web more secure.

You can barely trust a typical Web site to run Javascript in your browser without leaking personal information to God knows who. I'm not going to trust them with a full-blown rendering engine.

Comparison with Flash et al. is not accurate anymore, since these ran in an unprotected environment. Also, they were cumbersome install whereas WASM apps don't need installation (but can live in a cache if desired, and could even be shared among websites).

Fundamentally the problem is the conflict between the browser as an 'app' platform and the browser as a document viewer. Put simply, would you rather your user interface be 1) a magnificent piece of software with thousands of man-years put into it, debugged over decades, where every use case has been meticulously considered, or 2) a shitty script written by an overworked web developer?

As a anadotal. We can already fo to websites that run vms and emulate old operating systems. I dont this it is far fetched to run a web browser in a web browser.

It sucks but this is the way we're heading. I'm not sure web devs will even be writing HTML in 5 years beyond adding a canvas tag.

In fact, the approach would be more general, since a lot of text is already embedded in images on a lot of websites (think also about ads).

Not to mention that there's no such thing as "Easily run OCR", considering how many weird fonts there are, and that they could be rendered in such small size as to make it difficult even for humans to tell them apart.

The simplest example: how do you indicate a graphic or piece of text is a button or link? How do I set the alternate text if it’s a graphical button.

Besides, nobody says we can't have a protocol for some additional accessibility information.

1. No-one uses it

2. There is only 1 implementation, and it is never updated

And then we wonder where all the software bloat comes from.

So why doesn't everyone roll their own? Some issues:

  - footprint - that whole runtime has to come across the wire just to render "hello world"
  - javascript's single-threaded tendencies make perf a big challenge
  - text rendering [this happens to be the thing the document-focused Web really excels at]
  - text semantics [SEO]
  - gigantic implementation effort [custom engines RARELY make sense even for the demands/budgets/returns of AAA games; how many websites justify this kind of investment?]

I don't think that's true. At least, all the browser standardization processes I've been involved in included several people who would be responsible for actual implementation.

In my ideal world, browsers are spec'd in a functional language, and optimized mechanically (perhaps based on ad-hoc human guidelines).