From other comments that are focused on the code part of the subject, I think there are 2 big forgotten points here: time and hype.

Time: since platforms are big machines, their timeline and backlog is huge, and the self-taught geek does not consider (care) that. So when there is an obvious little hiccup somewhere, they create a bug report that asks for details, proof, reproduceability,... and finally get pushed back to eons because there are more pressing concerns to attend to at the platform level. Meanwhile, it takes about 1h (without AI) to code a workaround and feel like a hero because "I've fixed something that took them 3 years to triage".

Hype: yes documentation and code quality and all matter, but it matters even more when it comes from Google or Meta! We all feel little compared to giants and when they open their internal secret tooling framework (with big marketing budget) then we all feel like there is a secret to grasp and a key success factor to wield. So it is not so much whether a npm library some nobody created exists, but whether the main contributor works at a big brand name. It does not prevent smaller anonymous projects from emerging but lets face it, it is much more appealing when it is how Cloudflare handles it at 1e20 scale (because we all feel we face the same challenges of course).

The main reason is flexibility.

One day your boss stands next to you and asks: "can you move this border three pixels to the left", and the only correct answer is "but that requires a complete rewrite".

<dialog> still has issues to this day that haven't been resolved - https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h... - of course these can be implemented in any framework but this makes is much easier - at the platform level - to make a browser unusable, and as it's platform it's of course never been fixed.

You can have fun with web components (https://tanepiper.github.io/webc-humour/) but from my experience trying to build UIs with them - they end up becoming an additional abstraction that instead of just using a framework to build the entire experience, it creates annoying boundaries of having to deal with DOM attributes instead of just working with properties.

~a year ago i passed a major inflection point regarding web UIs.

i built an in-browser STT app UI with dear imgui, and everything just _worked_. i’m rendering to a canvas, running the model in a service worker and heavily using web audio, among other platform APIs. but.

at this point, i’d even struggle to comprehend the concept of going back to using the DOM for anything but a static reading experience. perhaps peppered with _fancy_ web components for an interactive animation. some would argue that’s what it’s for.

well, browsers/JS engines can both be powerful and terrible at the same time. despite using imgui via typescript bindings and rendering to a canvas via webgpu/webgl2, there is almost no limit to what i can do. more importantly, how easily i can express _whatever i want to see_ without paying with terrible frame rates, gc or layout jank or some other fun webism.

i’ve built SPAs since dojo was a thing, built iAds (lol), really, i’ve bikeshedded myself to oblivion.

low key expecting some kind of communal inflection point where we stop wasting our time arguing about bronze age tools and start having fun again.

The original sin of JavaScript was such a small standard library.

React, Vue, etc are all just working around it. I’ve never been good at web programming, but the rare times I need to, I want it to be easy. Thus Vue.

Infact I’ve been building my recent web projects with Flutter and Godot. Flutter Web is such a better experience if your use case allows it.

React to some degree made immediate mode UI possible in the browser, which is part of why it is this successful. If the browser gave the option to do ui = f(state) natively, you wouldn't need React.

Because every product manager thinks they know better. I and other engineers have pushed back to "use the platform" for years and years and more often than not we get told to do something custom to please product's fantasies, because "the platform" doesn't implement some inane custom request. So we make something custom and worse at great expense of user experience/expectations, implementation cost, and maintainability.

Not that I'm bitter about it or anything.

I have been down the rabbit hole. React for a web app used for scheduling. I built my own React/Elm-like framework in Rust/WASM. Use react at work.

All my web sites / web apps now are HTML + CSS + targeted/native JS. No npm or build steps. And I don't hit any limitations. They load and run faster than ~99% of websites.

Web components are lighter than frameworks, are they not? That was the biggest benefit I saw: no dependency on an ever changing framework and toolchain.

Decades old apps written in DOM and JS are eminently more maintainable than that written in some no longer maintained backbone / 1.4 django frontend or wherever, with their cacophony of unmaintained tools.

They didn’t seem quite as polished as the latest framework offering but they promised to be around when everyone gets bored of framework x.

It's because frankly the platform has been historically shit. Web components comes to mind as someone else here has mentioned, as it's just not a good API and needs wrapping to make it usable, same as IndexedDB which the author readily admits as a creator of such tooling. It seems like the ones who determine the platform aren't actually developers day in and day out and thus don't dogfood their own products while the rest of us do, leading us to reinvent the wheel.

Here is a great comment and discussion (scroll down) by Ian Hickson who wrote the HTML5 spec on how the platform has essentially failed on its promises causing everyone to write everything in JS or even other paradigms like Flutter and other WASM or canvas based frameworks that eschew the web entirely: https://news.ycombinator.com/item?id=34612696