No, there's no plans to rewrite the React core in C, Rust, Reason, WASM, or anything else right now.

Lin Clark, who works for Mozilla, gave a talk on "What WebAssembly Means for React" last year ( https://www.youtube.com/watch?v=3GHJ4cbxsVQ ). In a recent Twitter thread, she said that some more useful WASM pieces are in the works, but still not likely to be a big improvement or worth the effort to rewrite React ( https://twitter.com/linclark/status/967860936550879232 ).

Maybe Reason one day?

Then it could compile directly to native.

It would be really interesting to one day have React be a polyfill for an in-browser async DOM renderer.

Is that in (very, very, long-term) consideration?

I think my talk paints a relatively convincing picture why DOM nodes aren’t a sufficient primitive if you care about the features I described, as you’d need something like React to orchestrate those updates.

Hello Dan,

Great talk ! My thinking behind the top statement was with a native implementation of react-core, the react-native story becomes more compelling with JSX(ish) UI templates / CSS Styles and multi language business logic support.

Once you have this, the browser becomes another target. I see Flexbox implementation is already native with Yoga [0].

[0] https://yogalayout.com/

Oh sorry, I didn't do a good job explaining myself.

Currently:

    Application(JS) + React(JS) | Browser(C/C++/Rust)

Possible Future:

    Application(JS) + React(Polyfill - JS) | React(C/C++/Rust) + Browser(C/C++/Rust)

Something akin to the Browser building a "higher level" React-like API/scheduler for the DOM.

I saw somewhere that someone was working on something similar in Swift, but can't seem to find the link.

I remember a while ago someone shared a SSR C implementation of React.