> Performance is not a problem for the most developers, as long as the app runs smooth.
On their machines.
That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that.
What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky."
They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically.
I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.
Most devs using React work in development mode which is several times slower than production. I used to test with a chromebook and production builds were often faster than dev builds on my macbook.
On their machines.
That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that.
What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky."
They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically.
I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.