React Compiler: It's Stranger Than You Think

I hope we don't "forget" this history of React Compiler now that it's here. It's been a wild journey, and I'm thankful Dan took the time to share so much from it

SOURCE

S/O Ph4se0n3 for the awesome edit 🙏

[ToroidalFoxCasual]

I really don't know Theo that much, but he keeps saying things like "rust is bad when you have to change stuff often". But I haven't seen him doing any rust project that requires huge refactors. How does he know that rust is bad for it? Also feels like refactorability is a function of time and scale than a language choice.

[PhilipAlexanderHassialis]

Theo, we may have our differences on opinions but for this I need to take a stance: there is a reason why the core stuff of any big/critical application is written in C/C++/Rust/what-have-you. Because you need that peak performance - and you have the scores of developers to be able to re-write the whole thing, even from scratch if necessary. I understand where you come from and I get the "but we are in the move-fast-break-things phase" mentality. Nonetheless, the endgame is *AND ALWAYS WILL BE* to reach the performance that only pedal-to-the-metal gives. Go or Node or whatnot will never get to that point - and that's a good thing! But please, for the love of all that's holy, for once, make a video or something coming from the other viewpoint.

Not every developer will work on the "move-fast-break-things". Not every developer will want to stay there. Many developer's careers will take them to the mythical lands of big corporations who write enterprise code - and there, every picosecond is worth millions.

So please, for once, make a video coming from the other viewpoint. From the software. Just for once.

[tarasturchenko]

Specifying deps manually is insane. I always have hated react for that. Also using immutable data seems nice at first look but later it brings a lot of complexity when your app scales

[shapelessed]

If they had a compiler before they introduced hooks, then hooks suddenly turn into an even bigger abomination in my eyes.
It isn't for no reason so many people hate on React. Part of it is JSX, but the bigger part is the use of hooks that quite literally come and go every few versions and blow your whole leg off when what they promised was joy of use and at most a light bullet hole. If they went deeper into the compiler route, it would have enabled React to have a WAY better DX than the today's versions.

[omarshref]

You can easily put .reverse() after the .map() not before so it will just reverse the array of child components not the data array

[pencilcheck]

Haven't watched the video but doesn't matter what language, if you have to change often it just means the client or PM is bad (or perhaps is good because client is asking for a lot of features and you are raking in the money that way). The question isn't how many changes, but what changes are there. A lot of changes are simple to make, some changes are hard. Of course this is all relative to the language. With strong typing and a lot of restrictions I can see why Theo said the things he said. I would say that everyone is different, some people are just better at changing a lot of typing and a lot of structures very quickly. But it also might not be readable to other engineers either so the process will take longer.

[Supergeckos]

13:57 It's not *React* in a traditional sense. There's no inherent idea of reactivity in JavaScript. And it's pretty ridiculous to keep hearing that "React is just traditional JavaScript", but something like Solid isn't. Solid is just reactive programming, which in itself is older than React.
Heck, you can run Solid signal code without components and it will still work, because it is just rather simple reactive primitives.
Also, "data" is not reassigned. And I wouldn't expect code to rerun when data is reassigned. That is wrong terminology, especially because "data" is set as const. Using setState is not re-assignment. Only because setState hooks into the React renderer, does the code run as expected. And in that regard Solid actually behaves more like traditional JavaScript, where you setup subscribers and expect those to rerun when calling a signal setter.

[anon_y_mousse]

I'd never heard of HIR before, but after a quick search I suppose it makes sense as a buzz term for a transpiler. I would've just called it IR instead of trying to confuse people, because it doesn't matter how high or low it is, it's still an IR. Of course, I also didn't know that React had a compiler they were working on and now I have to go read it.

[Holobrine]

14:00 In traditional JS, I expect the log to run once if it’s called once. The Solid way, and also my favored Svelte 5 way, make it clear that you are establishing a declarative binding and not making a simple procedural function call.

[jarrodhroberson]

rust is not “bad” when you need to change it any more than any other language at a given scale (loc) appropriate to the language if the application is written naively. 20k of JS, Python or any other dynamic typed language is “bad” if you need to change it even when a skilled person wrote it initially

[jaredsmith]

I'm still experimenting with what React Compiler does to bundle size before I commit. I would love to see the team add some optimization level flags (a la gcc and clang) with some heuristics about trading off memoization against code size inflation. They'll probably just say to use Lazy and Suspense, as if the whole point of having the compiler wasn't to *not* have to rewrite your app, but I can dream.

[kamalkamals]

before i remember reactjs developers refuse sveltejs because they cannot trust to compiler sveltejs and they cannot understand how compile code js, but now they accept reactjs compiler, really bizard,

[simonhartley]

I don't understand the characterization of "not JavaScript" when code isn't re-run when data is reassigned. That seems React-brained because JS isn't reactive in that way.
It does seem to highlight that React is a framework and not a library, since it's calling your code, rather than the other way around.

[noahwinslow]

If I'm not mistaken, you don't need the For or Show components in solid, they're there for even better performance, they effectively replace keys in react

[voidmind]

9:13 YES! I have had so many issues with devs ignoring the React rules and arguing that it still works, and no matter how much I try to explain that it will blow up in their face in unexpected and hard to debug ways, I keep seeing it in their code. I'm going to love that compiler doing those code reviews for me.

[tarasturchenko]

I was really shocked when i did learn that react didnt cache your components by default and don’t have any adequate methods to cache data. In terms of DX vue is SO MUCH better than react that’s just insane

[shapelessed]

7:35 - No. This is not the "only way to do this code safe".
Just map the thing before you reverse. Map already produces a modified copy of the source array. Problem solved. Your example, my friend, was actually quite terrible.

[gageracer]

I want to see some benchmarks with compiler as people keep saying your code will be faster but it's doing 100% same optimizations you would do with memoization so technically there shouldn't be any hidden performance up. krausest's benchmark list has 20 react examples but none says anything about compiler(as they are all v18) but I assume most of them use the same memoizations and more optimizations like using signal solutions etc. If anyone have a data to show this actually improves performance that gets react closer to vue-solid-svelte level I would be really happy.

[SirCorrino]

About the Readonly thing, the team building the common components at my job mark all props as Readonly. I never really understood why since why would you want to change these things anyway?

As for not changing the data for sorting, we usually slice the array. Not sure how that compares to spreading it performance-wise, though.

[primostasis]

react compiler + million js? is that possible?