As a 'somewhat' outsider (having found interest in the web mainly via asm.js and WASM) my take on the framework mess is this:

It's all about problems with the DOM, specifically about three problems: it's too opinionated, too inflexible and on top baked into browsers.

Javascript frameworks try to provide solutions to those problems, but they can only hide them, not fundamentally fix them. Because they can only implement their idea of how a 'perfect DOM' would look like by adding more code layers on top of it, but not replace it.

The alternative is to do everything yourself in a canvas, but now 90% of the browser's features are useless, because they are all integrated with the DOM.

And that is the root of all problems: the browser lacks a proper API layer model where the low level layers (2D canvas, WebGL, WebGPU) sit at the bottom, medium level layers (e.g. for text, image and vector rendering, a layout engine and an accessability API) sits in the middle, and on top of everything the DOM. Instead all we have is either too inflexible and too high level (the DOM) or too low level for many tasks (WebGL or WebGPU).

Same for audio btw, there should be a low level streaming API at the bottom, a medium level 'mixer API', and WebAudio should only come in on top of those (or even kicked out of the browser and implemented in a JS or WASM library).

...of course this all means: lets get even more Javascript and WASM into web pages, which will anger the 'web boomers' greatly I guess :D

This seems like a really important fundamental observation. I hope other folks with different perspectives see this and weigh in.

At the risk of being a tad snarky...

What does OP think is underpinning the browser's implementation of the DOM? Or Audio, for that matter?

Those low level apis exist, and they could be exposed, but there's a whole lot of reasons they aren't. To list a few...

1. The browser is handling all of the platform differences for you. The issue with low level control is... you have to understand the low level details, and those tend to be architecture & platform specific. Blink in chrome is just neatly hiding the fact that under the hood it's got considerable differences for each platform. It's having to deal with OpenGL, Vulkan, DirectX, etc. And they are ALL different. So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms (Windows, Linux, Mac, ChromeOS, Fuchsia, Android) plus unofficial support on BSD (at least OpenBSD and FreeBSD). Using the low level api... I don't have time to write a website, I'm too busy trying to read graphics api docs.

2. There is huge value in having a selection of premade utilities to work with - The honest answer is that most websites are just forms. Microsoft knew that most apps are forms way before the web (WinForms). So if you really just need to have the user enter some data, and then see a new page a framework that provides you with those tools is a huge win. This is why things like QT, WinForms, and the DOM exist - they give you an easy way to quickly make forms. Of the three - the DOM is by far my preferred. It's actually an insanely capable engine for forms.

3. The last (and arguably most important) point is that the browser is enabling you to run untrusted 3rd party software. It's not giving that software low level access because it's sandboxing your system from it to give you at least a modicum of trust that you can open a webpage and not have your whole machine compromised. Low level access is powerful, flexible, and complex. I don't want a site to be able to access my microphone or files or usb devices without control over it... because I click random links on sites like HN all day long.

> 1. The browser is handling all of the platform differences for you.

...these "low level browser APIs" would still be regular Javascript web APIs which hide the differences between operating systems (that's the whole point of the browser after all!). E.g. WebGPU can still be considered a low-level API (when compared to other web APIs, but of course slightly higher level when compared to native APIs it sits on: D3D, Vk and Metal). Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences.

> 2. ...most websites are just forms

...this is a fundamental difference in opinion I guess. I see the web mainly as an open app distribution platform, not as a library for documents.

> 3. ...about trust...

See point 1 about WebGPU.

Safety aspects aside, you can look at game engines on how to build cross-platform APIs without giving up performance. In the end, most operating systems offer the same services in slightly different flavours, and it's possible to wrap those OS services in cross-platform APIs without too many compromises (after all, Windows, Linux, macOS, iOS and Android are all sitting on top of the same hardware anyway)

> Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences.

I would suggest this is not nearly as easy as you claim.

Game engines are actually fine example of exactly what I'm talking about - Unreal might have an abstraction that wraps over system differences, but to access low level apis devs bail on it.

Take a recent game: Atomic Heart. Built with Unreal Engine 4, which claims to support: Windows, macOS, and Linux PCs; PlayStation 4, PlayStation 5, Xbox One, Xbox Series X, and Nintendo Switch; and iOS and Android mobile devices.

Platforms that they actually released on? Xbox Series X|S, Xbox One, Windows 10/11, PS4/5.

Why? Because the abstraction turned out to not abstract so well, and they didn't bother to do the platform work required for the others.

Does it run on Linux? Sort of... it runs on linux presenting the same abi as Windows through proton/wine.

And even then, they have a ton of reported issues with performance (stuttering, frame drops, screens failing to load, unable to pause) on xbox consoles.

Which they've explicitly spent time and effort on making sure the game at least sort of works.

---

Basically - No, this sort of abstraction is hardly easy. Realistically, it's right on up there with rocket science.

Last note: What hardware do you think an M1/2 mac is running on? Or an iphone? Or an old BSD machine? Or a Windows machine? Because I've spotted about three different entire ARCHITECTUREs there (x86, x64, ARM64). Not even accounting for differences based with the GPU (or lack thereof). The OS is already trying pretty hard to paper over those differences for you as a application developer...

So I'm excited to see where we get with webGPU, but if you think it's equivalent to a low level api... I'm not really sure I agree. Plus it's explicitly not functional on... basically anything right now. Take a peak: https://caniuse.com/webgpu

> Why? ...

...not really, these are business reasons, plain and simple.

The problem with games on Linux is that the market is too small, the technical problems could be overcome if there would be a will and enough money thrown at it (see Steam Deck and Proton where this approach works pretty well) - for instance the technical problems for games on Android are arguably worse, yet the market is big enough that game developers have enough incentives to deal with those problems.

Also WebGPU is not released yet, so looking at caniuse is not really useful.

As for the last point: the CPU's ISA is the least of the problems. Most applications are no longer coded by hand in assembly.

Apart from being slightly faster, I see no difference between coding on an M1 Mac versus an Intel Mac or even a Windows or Linux machine (exactly because I hardly code in assembly these days).

My (same) code runs on all of those, plus the web, iOS and Android (granted I wrote my own set of wrapper libs to make this easy: https://github.com/floooh/sokol - but it's not like that's the only slim solution for cross-platform code).