[throwaway_bad]

Throwing promises to emulate algebraic effects seems really hacky.

I wonder if React would've needed to go down this path if they were built by a different company.

For example Google/Apple/Microsoft all have huge influence over browser implementations (chrome/safari/edge respectively). They might've been able to push a ECMAScript proposal for proper language support instead.

It's a very clever hack regardless but it only seems necessary because Facebook doesn't have control over the whole stack.

(it does seems like Facebook trying to fix this by building their own React-optimized javascript engine but only for react native on android right now: https://facebook.github.io/react-native/blog/2019/07/17/herm...)

[davnicwil]

> push a ECMAScript proposal for proper language support instead

I don't think this is the way it does (or should) work, though.

No company should be able to just come up with essentially an application layer pattern and immediately push that pattern down the stack, just because it's their idea and they think it's good.

A pattern needs to get a lot of practical usage, be iterated on a lot, and have strong consensus behind it before it's pushed down the stack to become a more fundamental building block in ECMAScript / browser APIs.

It's a form of make it work -> make it good -> make it fast. The process should take years. It's what happened with jQuery which eventually inspired the native DOM selector APIs, and I think the same is happening with React.

I honestly wouldn't be surprised at all to see JSX standardised as part of ECMAscript within the next 5 years. The rest of the stuff they're doing with the fibre architecture etc may follow too, eventually, if it turns out to be a really good idea after years of people using it in practice and agreeing it really ought to be part of the stack.

[erikpukinskis]

I agree. JavaScript obviously has problems but it’s also the most used development platform of all time.

Part of that is because the runtime API really doesn’t change much. And for many years the only changes allowed were very tightly scoped: a single new function call, that takes two strings. Stuff like that. The attitude was “what is the smallest thing we can do to make it technically possible for to get the job done” and leave developer ergonomics to the web frameworks.

It forces people to build real platform layers on top of the browser. That causes fragmentation but it is also a hot crucible for competition. It has led to arguably the most competitive developer tool landscape of all time.

It’s easy to say “browsers should just standardize on X” and be right.

However it’s exactly the very slow acceptance of standards that had led to such a strong ecosystem of ideas. So in the aggregate, as you indicate, it’s not good to land on standards too fast.

[orange8]

Markup (aka JSX) in js was already a standard way back in 2004 as E4X. It was however only implemented by firefox and adobe (actionscript).

[underwater]

Members of the React team are active in TC39. There are some features of React that have been replaced by language features (like spreading props into another component).