11–20 of 128 posts
Are people actually using the react compiler? Haven't heard about since ages ago when it was extremely slow
Earlier quoted context omitted.
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?
> 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 j…
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.
Earlier quoted context omitted.
Uh, TypeScript?
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.
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)
Earlier quoted context omitted.
> 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 j…
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.
Earlier quoted context omitted.
Uh, TypeScript?
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.
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.
Are people actually using the react compiler? 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 will no longer depend on babel.
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?
> 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.
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?
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…