"JSX is supported by quite a lot of frameworks, so you aren't locked into React"
Just not the browser natively....
Most backend frameworks don't need numerous layers of transpilation because they're on an actual OS and arent trying to work around an insane environment like the browser that's full of warts and incompatibilities.
What's the churn on Pandas? It's been around over a decade. And it can probably be reliably counted on to be around a decade more.
It will be surprising if React is around in 5 more years and hasn't been replaced by something else.
Is EmberJS still around? How much longer will webpack be around?
Stability in the browser ecosystem starts with stability in the browser.
I think instead of investing all this energy into browser frameworks we need to be devoting energy into making the browser do what we want it to do natively.
And as web assembly matures that's where I think this is headed.
> "JSX is supported by quite a lot of frameworks, so you aren't locked into React"
> Just not the browser natively....
Angular's *directive and [weird] (binding) [(choices)] will never be supported by the browser natively either. The fact that Angular uses an HTML file extension is a delusion (they really should have picked a different extension, it's such an ugly lie) that the templates will ever be more portable than they currently are. Sure, you generally have better raw copy/paste behavior of real HTML into Angular's templates than JSX, but if you think the mess that is the average Angular template will ever be portable to "native browser functionality", I may have a bridge to sell you.
I think it is a worse anti-pattern than JSX: JSX at least uses its own file extensions and doesn't pretend to be HTML. Angular uses the HTML file extension and in my experience confuses a lot of people into thinking the "Angular Template Language" is "just HTML" when it very definitely is not.
Most backend frameworks need literal compilation - all that's different here is that the target is a specific JS version, not machine code. Additionally, there's a bit of "naivety" here - browser vendors are the ones that implement native features, and that's clearly not a domain that a random developer can impact. Instead it's JS frameworks and associated tooling, which is all very strong now. The idea that Angular or Vue are somehow going to work in the browser directly is, once again, absurd, and please stop saying it.
> What's the churn on Pandas
I find it silly that you'll cite Pandas as not having churn when its parent language just underwent a large, painful, poorly received transition.
> It will be surprising if React is around in 5 more years
You are saying the same things people said 5 years ago about React. My React code from 2016 still compiles against the newest version of React, and works correctly.
Honestly, you're a classic example of this - you started developing not in JS, you felt some warts of JS, and now you hate JS and are ready to throw the baby out with the bathwater.
I'll be more surprised if "native web components" or "webassembly" are actually supporting production use cases in 5 years than if React is.
Just not the browser natively....
Most backend frameworks don't need numerous layers of transpilation because they're on an actual OS and arent trying to work around an insane environment like the browser that's full of warts and incompatibilities.
What's the churn on Pandas? It's been around over a decade. And it can probably be reliably counted on to be around a decade more.
It will be surprising if React is around in 5 more years and hasn't been replaced by something else.
Is EmberJS still around? How much longer will webpack be around?
Stability in the browser ecosystem starts with stability in the browser.
I think instead of investing all this energy into browser frameworks we need to be devoting energy into making the browser do what we want it to do natively.
And as web assembly matures that's where I think this is headed.