React's Magic Compiler You Can't Use (Yet)
HTML-код
- Опубликовано: 12 сен 2024
- React Forget is so promising. But it also disappeared. Or did it?
REFERENCED THINGS:
/ 1734897835521331451
• React Advanced London ...
• React without memo
• React Forget: React fo...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
Beyond React forget itself I think the most reassuring thing about the whole React Advanced talk is that Meta tests new React stuff on their own products before shipping it to us! Thats so freaking cool!!!
"I expect other frameworks will copy this homework"
...eh? Forget is solving a memoization problem that React created. Other frameworks use compilers today to trace dependencies and just update HTML bound to state. Frameworks like Solid also avoid the memory usage and virtual DOM this solution needs. I'm excited, but only for the vacuum of React 🤷♀
this is exactly what i was thinking!
fair point
React blinders are on
Totally agree, just use Solid and Forget about React. All this caching will suck up so much memory in large applications
@@Kaczucha888 solid is the way to go. i've worked on an application which is quite big and rendering anything is very expensive and even with my spaghetti code, the count for re renders is literally 0. i'm not sure if it was possible back then but surgical dom updates should have been in react from the beginning
Customary “they forgot about it harr dee har” comment
I'm no longer a react developer after theo labeled himself as a below average react dev
you're just a dev. why would one even want to be just a react dev.
@@nahfamimgood Exactly
@@FranFiori94yup. Probably why he doesn't live code anymore.
I aspire one day to be a below average react dev.
@@natescode I don't think live coding is easy. I mean I can easily imagine the situation where I will totally fuck up while being live even in the codebases I can easily deal with if I am not live.
6:35 with solid it can
Ah yes, a magic framework that allows your whole UI to be 3 DOM levels deep 😂
Yeah I can't wait for React Forget. It's one of those things that I'm genuinely hyped about when it comes to the future of React. It's unfortunate that it's taking them so long to ship it as stable, but I do also understand that it's not an easy thing to do. Although I would love it if they released a v1 of it with minimal optimizations and then gradually added more and more because it seems they are trying to do many code transformations initially so they maybe blew the scope of the initial idea.
One thing I'm sure of is when it lands as stable, it will already be battle tested.
but i thought react devs hated compilers because they all think it's magic. That was the whole anger against Svelte eh? How the tables have turned.
😂
react forget ❌
forget react ✔
🤣🤣
By the time react forget gets released all the frameworks would have already moved to better things. Theo mentioned that other frameworks will copy how react forget works... What copy? Vue already has watchEffect, svelte already has $derived, solidJS is solidJS. What react is "inventing" has already been invented.
He's clearly biased since he's dedicated basically all his coding time to it
Vue, Solid, Svelte were inspired by React initially. There would have been no web development we know today wihtout React.
@@maxwellcoding Not sure how this relates to what he said. Anyway, where's the limit? I could argue that React would not be there without AngularJs as well. If React didn't come out we'd surely have had something as good if not much better to fill the void...may be a better version of KnockoutJs which was the library that introduced .value which Vue now uses.
@ziad_jkhan Maybe doesn't mean surely.
For example, Vue, Solid, and Svelte were inspired by React. It is a fact. How can you state that without React something would have been better?
There are facts and opinions. The fact about React is that it is a library. People whine about that and try to make it a framework by comparing it with all the frameworks today.
@ziad_jkhan Vurtual DOM, Component based architecture, jsx, unidirectional data flow, reconciliation, .etc
You think no other frameworks got inspired by what I listed above?
if its a low level compiler thing,
they technically can release it under a flag
not sure why they're holding off releasing it...
I hope that they’ll actually release it as a new React version and not just inside of Next
you can use Next without ssr
@@marusdod3685 Which still doesn’t make sense in some stacks
if something this makes me wanna get as far as I can from react, it’s getting farther and farther from just javascript, its initial concept
come to the greener grass of SolidJS where the only code that isn't "just javascript" is JSX
Well, if you hate React for that, you will hate others frameworks more.
This React problem is the exact reason that in my company we switched from Starting every new project with next js to Sveltekit in svelte this not a problem at all.
@13:36 - I feel that sentiment from solidjs (state management) having just played with it especially within a ts app, it seemed I was maybe in some state management anti-pattern where my state "variables" were all signals and.. this felt very unwieldy... I was not fond of it.
(my goto 'app' for playing with ui is a 2d map editor type gizmo, where you have vertexes lines and can select vertexes/lines and see properties on them, the view is in svg with pan/zoom controls - this is what I was trying out in the above)
React is really starting to look like a Frankenstein of a library with the complexity of RSC now Forget.
Starting from zero is always easier that maintain code
@@neociber24 Vue enters the chat...
@@gro967vue is worst xd
RSC is complex but worth it, you ship way less javascript to the browser.
MobX and chill. React team should make reactivity pluggable and then just stop.
I'm hyped that React is still leading the way with RSC, as well as fixing its own issues with Forget. Great developments lately!
Can we all instead just forget react?
How about we just Forget React instead
htmx. thanks for the memories.
Or, you know, just use Signals and don't have all this compile time stuff complicating things even further.
Deciding between good UX and DX is basically the core of React 😂
SolidJS is 1.1 times slower than vanilla js, and react is 1.7 times slower than vanilla
If react forget can bring it down to even 1.6, then that would mean react would only be 1.45 times slower than SolidJS, the fastest framework we have.
And that's without any of the NextJS magic or the Million compiler. It really feels like the performance questions are being sufficiently addressed, and I'm excited to finally be able to use react without feeling guilty about all the perf I'd be losing.
Why should you worry about your app performance in the first place? I bet it's not even an issue in your apps. And for 99% of React apps, it won't be an issue. People should focus on maintainability and architecture first and don't prematurely fix potential perf problems. These speed comparisons are nonsense, many other things come before perf that affect user experience and devs should worry about them more. Nobody needs a fast app with terrible UX
@@guuhuu1337Nothing about performance means you'll have bad UX and as someone working in ecommerce I can tell you that performance is one of the metrics that has biggest impact on sales. Performance matters far more than you think it does and affects UX a lot.
However, that doesn't make what you said inherently false, what you're making is probably performant enough. I just don't like the whole attitude of performance last. If you know something is going to be used a lot, put a bit more thought into if you need to worry about performance, because the vast majority of performance issues are death by a thousand cuts. If you get to that point you're essentially looking at an entire rewrite.
Those benchmarks are averaged across lots of different tests. React can be a lot slower in some cases I care about.
@@guuhuu1337Imo it’s an issue in almost all apps, and you can’t always fix it later without a rewrite. I agree there are plenty of other important things of course.
@@CottidaeSEA I didn't mean that performance is the last thing you need to think about, of course not. I mean that in the vast majority of cases, your app is performant enough. In most cases, bad perf is just a skill issue, as far as I can see.
I develop data-intensive SPAs with react - MES (manufacturing execution systems) apps for a factory - and, oh mama, there are apps written awful (by me btw) and still, it works fine on old laptops employees use.
Theo, Appreciate video production quality and your enthusiasm. Thx.
Amazing! I could use signals today but I'm going to wait 5 more years for react to release something, hopefully I don't forget
"It's not magic it's computer science" I thought they were the same thing? Damn and here I thought I was a wizard
did u reupload the video or something ? I swear either the thumbnail or the title was different
3:32 The problem here is that AddTodo is contained within TodoList (does that even semantically make sense?). But that can be solved by passing a `children` prop to TodoList and then composing AddTodo as inside the BlazingTodoList parent. Then you can set the themeColor prop directly on AddTodo without passing it through the props of TodoList, and thus TodoList actually doesn't re-render when themeColor changes. But TodoList will re-render by default when it's parent BlazingTodoList re-renders anyway, so you need to wrap TodoList function like this `const TodoList = React.memo(function TodoList({ children }) { ... }` To avoid it being re-rendered when its props have not changed, even when its parent is being re-rendered. But significantly, TodoList won't be re-rendered when the props of it's children components have changed. Because React (when React.memo is used) only does a shallow comparison of changes to a component's own props when deciding to render it or not. Thus, by composing components like that, you've made it slightly more semantically clear, and avoided using hooks like useMemo or useEffect. Maybe you should even have put AddTodo below TodoList not inside it as a child, for better semantics here, but this is just an illustration of the various patterns you can use. Just to illustrate that if you need useEffect or useMemo there are often (always?) better (more composable) patterns to use.
thanks for that!
21:50 👍
It is more like Compose in Kotlin Multiplatform where they also memoise parameters using Kotlin compiler and update it conditionally
Theo, tell us more of your secrets. Just blink with left eye.
Isn't this just like computed in vue? it already automatically tracks which variables are used in the computed property, and only when any of the properties changes does it rerun the computed function again on the next render so you don't need to declare the dependencies. Sure, we have to write computed() but if vue could do that, why does react need a whole new compiler process to do this?
So that means - I will need to compile my typescript to javascript, then compile my react to react, and then bundle it? Are we going crazy?
it's weird to see React pull up compiler to do the thing, that Vue is doing from 2.x with computed and now with watchEffect, picking up reactive dependencies on the run
it's hard to turn a big boat like that
Yeah, this seems like a somewhat weird and overly complex solution when other frameworks have already solved this problem years ago. Maybe this is somehow better than those, and I get maintaining support (hard to turn a big boat indeed) but again, if vue did this with computed years ago, is it that hard to create an alternative version of useMemo? It can't imagine it being harder than making this compiler stuff, at the very least. Maybe call it something different while you're at it since it's a terrible name
Anyone know which font Xuan is using?🤔
I'm building a todo list while I'm watching the video LOL
At this point, React just feels like Apple of frontend frameworks. They "reinvent" what already exists and present it as Innovation.
I loved and learned React for its simplicity but the more I used it the more I realised its just a false promise and anytime you want to do something even remotely useful, you have to throw the "simplicity" into a trash can.
I wish in the future React fixes itself with a major non-backwards compatible version that just forgets existing React and applies the collective knowledge of decades to actually make a decent framework.
Or
It gets replaced by something already doing things right, like Solid.
If I need a front end JS solution, I use Vue.
Solid JS is still in beta. React Forget is aimed to make everything simple in terms of DX. Isn't it what you are talking about?
Solid is not in beta, Solid Start a metaframework of Solid is still in beta as they decided to make beta v2 learned on competition experience
I bet this would help a ton of shoddily coded react native apps
will they deprecate the useMemo hook? i feel like it could confuse the compiler quite a bit 😅
i wonder what will happen to context api and how it will behave with it
Have we gone full circle? Reinventing compilers now? Finally?
The amount of mental gymnastic to avoid re-rendering issues and footgunning yourself in React is just ridiculous.
It is the one area where the whole UI is a function of state UI = f(state) fall flat on its face. Coupling UI (and re-rendering) and state so tightly was bound to create re-rendering.
How about React reconsider that mental model and follow what SolidJS is doing? React is an "unopinionated" library no?
"unopinionated" just means it is a huge mess that constantly changes.
Why do all of this for years and years when you could have spent the time to write a compiler that translates code to raw dom-manipulation?
I'm going back to PHP and JQuery
bro what are those thumbnails
What it they would adapt the compiler to run with server components, seems like it could be integrated quite seemlesly.
Omg! Yes! Btw, I’ve never used memo. Just gotta wait it out 😂
It’s these kind of compiler optimizations that make me thankful I use svelte
Does anyone know which font Xuan Huang is using?
We really need to move beyond React and front-end frameworks and instead focus on making the browser itself a better platform.
nah build tools forever!
@@SamualN if you are happy with the current state of the browser, which really hasn't evolved very much since its inception, then sure lets keep investing in larger build chains and download payloads.
@@catwhisperer911 you can have larger build chains that make smaller payloads
What about React Hermes? Can we have a video about that, thanks
I really looking forward to this thing. The whole memo is just a horrible bug to developer UX. Good old classes.
Can u make a video about the new t3-turbo monorepo?
We forgor 💀
Does forget with Million? If so, that'd be quite a rocket.
Has no one heard of Recoil ?
Dead project.
Interesting indeed
Wow It's almost as if..... we forgot about it..................
I think we forget it
Wow, I'm hyped!
Miduu :D
Got forgotten 😢
I think they forget about the React forget
25 min in, I still don't know W.T.? it is... :-/
That's a lot of messy code just for a ttodo list.
Funny how React tries to recreate what Vue does just as a core feature for years :D
and then theo says everybody will copy react forget :D
Vue itself is a recreation of React initially. There would have been no Vue we know today without React.
@@maxwellcoding take a look at the use of directives (v-if, v-for) and dependency injection. You may find that Vue is more of a "remake", friendlier version of Angular (ngIf, ngFor). Very few patterns in Vue were inspired by React.
Evan You himself, creator of Vue, used to work at Google ...
Kind of too bad their example code has .filter() written out as a for-loop. It’s irrelevant to the problem at hand, but still; this ain’t Fortran.
Midu god
Vue has already had this for years
Vapor hasn't shipped yet?
yo
To be honest, I don't know what Meta is doing with React. The last release, v18.2.0, is over a year and a half old, while new commits arrive on a daily basis, React Forget was hyped ages ago, they are suggesting frameworks to use canary (so by definition unstable) releases. In what universe does any of this make sense?? At this point I'm not hyped for React Forget, I can't trust it to ever ship.
Vercel is running the show now.
There's no incentives at Meta to improve it. It has no value in the annual evaluation. People have to show real monetary impact, so it's relegated to a side project
i forgor
They are lying (yet again)
this is cool shit
Just qwik
please make about video about why Prisma, a part of your channel name stack, is so good for doing code join and not SQL join
LFG!
I am the firstest
So once again React sticks to its cope and does whatever it takes just to keep the fundamentals that make it slow, hard to work with and unoptimized and instead build a tool that would do the manual work for you instead of rethinking where they failed 10 years ago
@@beowulf_of_wall_st only in youtube comments and twitter do you find this many hardcore React haters lol. sadly most of them are irrelevant though as it's still the dominant framework in the job market and only trending upwards. I'm not going to say that for every use case it's the tool you should reach for, but it definitely has its use cases
@@beowulf_of_wall_st it's not a failure, because it's the most popular out there. However picking React for a new project nowadays, simply based on it's popularity is just unreasonable
What a nonsense. Why is it hard to understand that React is a library. It rolls out a bunch of tools you can apply the way you wish. It is meant to be that. It can't be Vue or Angular, or whatever framework you tried to compare it with.
And about failure - today's web development wouldn't have been as we all know without React.
@@maxwellcoding about the "it is a library not a framework" bs - only React and the fanboys calls itself that, there is no reason to call it a library as long as you base your whole app codebase on top of React.
Yes, you can partially apply React to your app, but guess what - you can partially apply Angular and Vue too.
Yeah you can apply many tools on top of it, in fact that is what a library is - an enhancement on top of your code, you can apply hundreds of libraries on top of a Vue, Angular or Svelte app so I don't get your reasoning. A library is something you can detach from your app that won't break the whole thing, what happens when you remove React from the app you wrote that i majority relies on useStates and other hooks? It will break entirely and would require you to rewrite the whole thing.
It can't be compared to Vue or Angular? Lol what, it has always been and it most definitely can because it solves most of the same issues. Not having a unified, standard way of handling global state or routing is not a reason to call it something completely different.
Yeah today's web dev would not be the same if not for React, same applies to backbone, jquery, knockout, angular.js and many more, but that is not an argument against what I said - "choosing React for a new project nowadays is unreasonable"
1st
A bunch of whining React haters in the comments that don't understand what React is and its purpose.
They are supposed to be working on Vue, Angular, Solid JS , and so on, but for some strange reason they watch content about React.
Its purpose is to give FE devs jobs because they couldn't learn BE /s.
@@natescode That's you it seems
We just start using "facebook(meta?) time" just like "valve time"