Why are they porting the Babel-isms? They should be using Oxc tooling directly, not hanging onto JavaScript parsers, IMHO -- isn't the benefit of porting to Rust that you can use fast native code?
It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?
A couple of months ago, I experimented with this - took tsgo and ported tsc to go with Claude. The main issue why this still didn't happen yet is because tsgo doesn't expose plugin API externally, but it's still there, so you can just co-locate your plugin as extra Go module and compile everything together. Managed to get my fairly large Angular app to compile and even run unit tests. Cold compile time went down about 2x - so the benefits are there, but not as dramatic. I think this would still need architecture level optimizations that enable build parallelization, but that also requires making some changes to framework API so components can be isolated-compiled or something.
After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.
Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?
Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off
> This is an experimental, work-in-progress port of React Compiler to Rust. ...
And then gets merged.
So after the craziness to use node on the backend, we are back to using compiled languages to compile Javascript assets and Web resources, just like Java and .NET were doing in the 2000's, however since it is Go and Rust it is cool, not the boring languages grandpas were using on their heyday.
It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.
I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.
If this works and passes all of the tests, then it seems like a done deal to me. LLMs are just too good at doing ports where they have a rigorous automated test suite or oracle to compare against. They're oddly bad at following instructions like "port this mechanically, exactly" - worse than a human for sure - but they seem to do a great job of sitting there and comparing results to find bugs for hours and hours. It's hard for me to imagine a world where they aren't used to assist ports, not just writing them but especially refining them.
I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.
That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.
The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.
19 comments
[ 4.3 ms ] story [ 40.7 ms ] threadHaven't heard about since ages ago when it was extremely slow
Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.
It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?
Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?
[1]: https://news.ycombinator.com/item?id=48132488
https://github.com/tsz-org/tsz
> This is an experimental, work-in-progress port of React Compiler to Rust. ...
And then gets merged.
So after the craziness to use node on the backend, we are back to using compiled languages to compile Javascript assets and Web resources, just like Java and .NET were doing in the 2000's, however since it is Go and Rust it is cool, not the boring languages grandpas were using on their heyday.
I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.
I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.
That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.