Rendered at 10:49:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Surac 7 minutes ago [-]
<something> rewrite to rust using AI sound like meme now.
willsmith72 52 minutes ago [-]
Are people actually using the react compiler?
Haven't heard about since ages ago when it was extremely slow
molf 19 minutes ago [-]
Yes absolutely.
It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.
A small downside at the moment is the build time. This change will hopefully help address that because it no longer depends on babel.
paavohtl 33 minutes ago [-]
We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.
ramon156 43 minutes ago [-]
I think it's fine to experiment, just communicate with your users and make sure its opt-in.
Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.
Trung0246 1 hours ago [-]
Curious but can we use lean4 as port target instead of Rust?
bhy 2 minutes ago [-]
I don’t think lean4 compiled code is as efficient as rust. For verification purposes, there are some tools allowing formal verification of rust code.
jon-wood 54 minutes ago [-]
I'm sure its technically possible, you might need to provide a bit more context if you expect anyone to change course here and port it to a programming language approximately no one has heard of rather than Rust though. What makes you think that would be a good idea?
koito17 40 minutes ago [-]
> approximately no one has heard of
Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.
Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.
I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.
HeavyStorm 31 minutes ago [-]
Oh, PhDs, you're right, that's not approximately no one... It's probably approximately one.
I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.
22 minutes ago [-]
voidUpdate 50 minutes ago [-]
What is the react compiler written in currently?
LoganDark 40 minutes ago [-]
Uh, TypeScript?
iammrpayments 34 minutes ago [-]
I think they use something called “flow” last time I’ve checked, it’s like typescript but when I went to visit the website with more information it was so slow it crashed my browser.
__jonas 21 minutes ago [-]
Are you sure? The React compiler is a fairly new addition to React, Flow is Facebook's old alternative to Typescript, but Typescript won the ecosystem in terms of broad adoption in the end. I think Flow is barely used today, I would be really surprised if they choose it for a new tool, even for a Facebook project.
You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.
LoganDark 31 minutes ago [-]
You may be right. I think Flow was a predecessor to TypeScript.
I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)
voidUpdate 11 minutes ago [-]
Isnt the benefit of rust that it's memory safe? Is typescript not?
bandrami 4 minutes ago [-]
I think the benefit of rust here is that it's not hosted whereas typescript is
LoganDark 8 minutes ago [-]
The benefit of Rust over TypeScript is that Rust is faster.
TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between workers is a bit annoying compared to structured concurrency in Rust)
LoganDark 39 minutes ago [-]
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?
molf 12 minutes ago [-]
OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:
> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.
LoganDark 10 minutes ago [-]
I saw, I just don't understand the rationale for picking Babel over OXC or something else as the interchange format -- other than "we were already doing it this way". After all, you know what they say about temporary solutions.
molf 8 minutes ago [-]
So isn't not changing more sensible than changing to an arbitrary alternative?
The current developers surely are more familiar with the Babel representation than OXC, so why switch?
LoganDark 3 minutes ago [-]
What I mean is, if you're going to rewrite it in Rust, why rewrite Babel rather than leaning on the existing ecosystem. I know they're not actually rewriting Babel, just reusing the semantic layout of its AST, but it's feeling a bit like the MediaWiki parser situation to me (roughly "if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"). Maybe that's a fairly remote analogy but it feels similar.
Haven't heard about since ages ago when it was extremely slow
It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.
A small downside at the moment is the build time. This change will hopefully help address that because it no longer depends on babel.
Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.
Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.
Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.
I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.
I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.
You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.
I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)
TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between workers is a bit annoying compared to structured concurrency in Rust)
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?
> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.
The current developers surely are more familiar with the Babel representation than OXC, so why switch?