The other big piece missing is that desktop-based GUI tools have native primitives that are designed for building complex apps. The web has bits and pieces, but is still a document renderer at its core. I’ve worked in a few of the XML-based GUI tools and MVC frameworks, and none of them were great, especially for real-time information. But at least the native SDKs provide basically everything you need.
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.
at the end of the day it is really about which poison you would pick; one team dealing with one complicated toolchain or five teams with their own bespoke OS-specific toolchains that can barely coordinate. They're both not good choices; and in an era that until recently was an era of dev scarcity, a lot of companies picked the former choice.
people also really hate feature gaps between platforms. so option one makes your customers less angry at you.
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.