React Compiler: It's Stranger Than You Think 

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.

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

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 big-business/mission-critical/enterprise software. Just for once.

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

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.

react compiler + million js? is that possible?

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.

In an ideal world, do you mean when using Flow?

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.

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.

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,

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

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.

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.

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.

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.

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.

I was doubtful of my compiler nerdness but yes I like the fact I am a compiler nerd now

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.

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

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.

So after all this years react eventually bring caching to components as it should be

one thing I can't get out of my mind is why this compiler exists is it because we the developers suck at react or because of a bad dx or maybe both

At 14:00, this video conviced me to checkout Solid, looks clean.

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

React becomes to Svelte. Svelte becomes to React.

React is a framework now

Why can't you build extensible rust? There's no reason in my mind that rust can't be developed with a system of future features easy to plug in. If a garbage collector can do it, then a system of add ons that easily plug into your existing project should be just as possible and reasonable in rust, doesn't it?

The part about "we like our raw plain values in React" is exactly my feelings about Solid. Regardless of its good parts - I'm not wrting "just js" with it, I'm writing something very special Solid-compatible. "Don't use destructring because it will break reactivity" (which naturally leads to "don't use default values" and "don't spread objects" - use dedicated helpers for that), "don't assign functions directly, wrap them all in intermediate callbacks", "don't use async callbacks because our linter says so for some reason"... It quickly becomes so tedious to write, that I can only pick Solid because of necessity (like when I really need to save some bundle size), never because of personal choice. While with React basically the only rule is "don't call conditionally funcs starting with 'use' prefix" - and you're good to go.

Quiche eaters

Prefer immutable array methods like toSorted, toReversed, toSpliced…

Prima gen îs moving from rust to go, because his audience is majority go developers or golang fans. Man, Theo is just spreading misinformation

My employer does not use React in their projects. They only use Vue and Angular. When it comes to my personal project, I develop a 2D videogame, so not much use for React in there either... But I watch video about React anyway because I am curious, I guess. Also, Rust shills in comments incoming in 3..2..1... Dear Rust shills, please go back to programming microcontrollers

React teams follow KISS (Keep it simple stupid) and HUGS (Help Understand, Guide, and Support) principles so well .

Hi gabrielelpidio and RonanRU from twitch chat

14:57 would definitely rather have a when component than have to use ternaries

Use immutable data. Stop inventing weird shit. Thank me later.

Like this if you like Dan

React is Quiche Eater slop - real programmers use SpringBoot

7:40 toReversed() ;-)

Wild that React is taking this long to catch up to Vue 🙄

Compiling scripts is a footgun. Use a compiled language, then.

step one: dont use react