Imagine a world where you just had drawing and input handling primitives on the web. You wouldn't invent the DOM and then something like React to wrangle it that's for damn sure.
Good news! We do have those primitives! The canvas element can - and is - used for drawing, and input events are fairly easy to manage. Larger projects like Google Docs or Figma often go in this direction, because for very complicated applications, it's useful to be able to handle every part of the rendering process yourself.
That said, it turns out having a rich selection of easily-debuggable, accessible components attached to a powerful layout engine is also really useful, hence why people mostly stick to the DOM unless they specifically need something that only canvas can offer.
I think this gets to the core of web devs seemingly not knowing anything else. Not knowing that, from a technology standpoint, how much better you could have it.
We can talk all day about how there are better ways to do it, but until you solve the distribution problem, the technology doesn’t matter. Mobile apps sort of solved it, but even then, the bar for installing an app is higher than the bar for clicking on a link. Plus there are cross-platform tech and policy differences to deal with, you can’t guarantee your users are running the same version of the app, etc.
writing native apps means having to have basically 4+ development teams for Windows/Mac, Android/iOS, and 5 if you want to have Linux. And it is pretty logistically difficult to herd five separate teams using the same product roadmap because the implementation of one feature can vary so wildly. But if you don't and someone gets a feature someone else doesn't get then people get upset.
I think the reactivity model React has is very compelling, and once you start thinking in terms of “GUI as a function of state,” you start trying to do the same in PHP or Swift and it just doesn’t work out as well. (Though there’s now SwiftUI which is a more reactive way to do iOS GUIs.)
I think react struck gold conceptually, and in a world where the “native sdk” (the browser) didn’t give you much, it became very compelling for many people. I think it has struggled to create intuitive APIs, and has struggled to handle real-world performance without clunky APIs.
Not to mention, browser environments face a slew of problems desktop apps don’t. You have to ship much smaller bundle sizes, no type-safe language, immature language requiring polyfills for useful language features, and the list goes on. Each problem introduces a new tool (webpack, typescript, babel, etc.), and they don’t frequently place nicely together. If I’m writing a Rust or Go program, practically every dev tool I need is part of the language toolchain. And while there are projects that aim to do that for web, they run into the “yet another standard” problem.
Backend has complex problems to solve, but at least you fully control the stack. You can use languages with simple toolchains and good libraries for writing web servers. On the front-end, every library you use is ultimately at the whim of the browser.
people also really hate feature gaps between platforms. so option one makes your customers less angry at you.
I think this is a really good thought experiment and that you are right - we wouldn't end up with the DOM if we started from scratch. It's a pretty bad local optima resulting from decades of legacy cruft. However, I do think react is closer to that ideal than the DOM.
Then you'll also have to reimplement accessibility features yourself. For a lot of use cases, that isn't worth the trade-off, imo.
