Excellent work as always. Especially appreciated the love for Harambe. He's eternalized in the test suite of a code base I worked on for several years and will always hold a special place in my heart. 🖤 🦍
really great context about async rendering in React ! Really cool to have alternative apis for delaying user input (debouncing/throttling) user input like useDeferredValue
As always, excellent presentation! Thanks, Tylor, for taking the time - you always take these high-level concepts and break them into manageable, bite-sized, engaging content. I always learn something new and interesting.
What I found fascinating about this is how much preparation work and things in advance they had to do in order to get to here. It's not something that was decided and done in 6-12months. It took years, it's crazy.
I think it's more like "We can't do this thing right now, but we can do this other thing that would set us in the path for the thing we wanted, and it makes sense to do it because it benefits us" Less of preparation and more of making the right things that could lead to the other big thing
Five years invested in workarounds (mind you, not solutions) to problems inherent to the React model. The concurrency applies not to updating the DOM (which you can't do concurrently) but to all the extra work React has to do *before* updating the DOM. All this scheduling work accomplishes (if used correctly) is optimize *perceived* performance - but the framework is actually net slower than it was before doing this extra work. Meanwhile, other frameworks such as Solid, Svelte, Imba and others have moved on to a model that updates the DOM directly, instead of doing all this unnecessary work on an in-memory duplicate of the entire DOM, which has to be reconciled with the real DOM before doing actual DOM updates. React keeps adding layers of complexity to get around a fundamental design issue - and developers seem to have the perception that all this extra complexity is inherently necessary, and even ironically take pride in knowing how to apply all the new performance features to achieve acceptable performance. Meanwhile, other frameworks are moving on to much simpler models, where these performance features aren't even necessary in the first place. Regardless of how pointless this effort is, there's a market for it, there is job security, and so on - apparently that's the only thing governing the success of any framework in this industry today. 😕
what other frameworks would you suggest ? im still new to react and i would rather not invest too much into it if another framework is objectively better
"optimize perceived performance - but the framework is actually net slower than it was before doing this extra work" -- you've just described horizontal scalability
Are you saying it's possible to have component based architecture, rerender on state and update the DOM directly in a single page application without reload and without a reconciler? If you could recreate react without the diffing on DOM component and no major drawback then people should start writing the library.
I've done this on our corporate's multi user client management/invoicing/payroll system for like 10 years now. I guess it's about time, maybe one day these things will be usable instead of me having to make everything myself. RIP harambe
EVERYONE NEEDS TO WATCH THIS! History keeps repeating itself! Notice how we keep hearing about 5 times it improved something but didn’t work on a large website. The test of a great pattern or architecture is if it was done everywhere does it still work well and is easy to maintain? Yes and it is good, no finds areas of improvement
@@DanKaschel it doesn't matter if it's the most popular, many libraries have been replaced before, React is no different and WILL certainly be replaced. I wouldn't have said this 1 or 2 years ago, but now most people are aware of React's flaws that we try really hard to avoid React, whether it's using a patch meta-framework or another library. I personally hope it's solidjs, maybe it's svelte idk (both of these have greater levels of satisfaction than react btw)
One more reason why they did not go with the service workers is the expensive context switch to perform the task. In case of state calculations it becomes even more evident and obvious to not use workers.
In the input and list example you gave, how's using the new concurrent mode different from debouncing the rendering of the list on input change, as far as visual rendering performance is concerned?
Great question. With a debounced input, you would have to wait for the debounce to timeout before the list work even begins. With useDeferredValue, the input state updates immediately AND the list work begins as soon as the input state changes. With a 500ms debounce timeout, useDeferredValue improves the speed by 500ms minimum.
@@uidotdev In that case, how is React able to stop rendering of the current list in between when a new state change happens in input? If all this is happening on the main thread, then it's not possible to stop rendering of the list in middle, as js code runs synchronously in the browser, and the input change can only be processed in the next tick of the event loop.
That's what the Fiber reconciler in React 16 provided - a way to pause low-priority work when something with a higher priority comes in. Part of it is also the `requestIdleCallback` feature in modern browsers. This video goes into much greater depth about how Fiber works, and how it paved the way for concurrent rendering. ua-cam.com/video/ZCuYPiUIONs/v-deo.html
It's still a bit unclear whether upgrading to React 18 is a good idea yet; especially if you are using Next (e.g. Suspense is discouraged for data fetching). Would be great to get your ideas on this Tyler? Thanks
All this investment in order to settle on a built-in lodash debounce methodology. Seems like hype and buzz wordy solutions to a problem seasoned developers already know how to solve.
And you probably don't really need to know. One thing that is under-communicated in React discourse these days is that all these new primitives and performance optimizations are not necessarily needed. A small and relatively simple React app will still most likely perform acceptably. React is still the same at its core as it ever was, with most importantly a very good component model. And its very close to plain js, which is also a good benefit. If you truly need more power, then React now offers primitives to achieve this. But you don't *have* to use any of them.
So for now we kind of "opt in" to these Concurrent Features on case-by-case bases in the same manner we would identify a complex situation that calls for Memoization?
Sorry, but I don’t get it. I’ve never come across an instance where I would need this (I think). Do you maybe have some real world example of where this would be absolutely necessary?
3 years ago I decided to do more front-end work and learned react, hooks where the way to go. Went on a couple interviews and they cut me dry because their codebase was still in older react versions and I couldn't use hooks. I learned from an old colleague same shit went on with Vue. Frameworks where chaning too fast for the corporate world to adopt and new releases were considered unstable bacause custom components getting incompatible... I got so frustrated I devoted to Svelte, new kid in the block but simple AF. Long story short my components from 2019 still work on latest svelte and I can inject them in any webpage, no matter what framework it uses. Best choise I've ever made.
Excellent work as always. Especially appreciated the love for Harambe. He's eternalized in the test suite of a code base I worked on for several years and will always hold a special place in my heart. 🖤 🦍
RIP 🖤 (Thanks for watching!)
This is by far the simplest and best video I've seen on React 18. I'm now a fan!
Thank you! Glad you enjoyed it!
Continuously stunned at the level of research and quality put into these videos. Just absolutely incredible
This comment and your other one means a lot. Thank you!
Another video, another banger. Thank you for producing such high quality videos for us devs. Always pleasure to learn through these
Thanks for commenting! ❤️
Loving your content, keep it up!!
Thank you!
really great context about async rendering in React ! Really cool to have alternative apis for delaying user input (debouncing/throttling) user input like useDeferredValue
Glad you enjoyed it!
Becoming a fan of your work Tyler. Glad to see your effort delivers quality output and also well received by devs!🔥
Thank you Lax!
As always, excellent presentation! Thanks, Tylor, for taking the time - you always take these high-level concepts and break them into manageable, bite-sized, engaging content. I always learn something new and interesting.
That means so much. Thank you!
Your content literally made me pause to check if I had subscribed, this is some top shelf content.
❤️❤️❤️
Harambe was like father to me
🖤🖤
Coming from today's newsletter 😎 thank for this clear and really interesting video !
Thanks for watching!
It was smart that they went with the approach of concurrent "features", instead of an all or nothing concurrent "mode"
This made so many things clear! Thank You for your work. ✨
Its scary how small this channel is. Keep the awsome work man ❤️🔥
We'll get there. Thanks for watching!
Thank you, Tyler, quality content as usual.
Thank you!
First time seeing this channel, and I gotta say, the animation and quality is amazing! Keep up the good work!
Glad that I discovered your channel. Thanks 🙏
First time discovering this creator, liked, subscribed and commented. Nice job.
The react team left us in Suspense!
🥁
Just found the channel. Had to subscribe.
Great work!
Welcome!
Actually I am new to React. I didn't get much of the things but liked your presentation style and teaching style.
Thank you!
Wow man! Time to binge watch your content
Welcome!
one of the best channels. keep going.
That means a lot. Thank you!
What I found fascinating about this is how much preparation work and things in advance they had to do in order to get to here. It's not something that was decided and done in 6-12months. It took years, it's crazy.
Totally. Lots of thought and patience.
I think it's more like
"We can't do this thing right now, but we can do this other thing that would set us in the path for the thing we wanted, and it makes sense to do it because it benefits us"
Less of preparation and more of making the right things that could lead to the other big thing
@@renatosardinhalopes6073 yeah probably. Doesn't make it less impressive in my opinion.
The quality of these videos is unbelievable
Thank you!
Great video and fantastic explanation, thanks heaps!
You're welcome. Thank you for watching!
Loved the video Tyler, keep it up.
Thank you!
your videos are very very very informative, thank you very much for explaining all these things brilliantly
awesome high quality content. I'm surprised why you don't have millions of subscribers yet :D
Thank you!
Finally more people are viewing this amazing content .
❤️
This video made me subscribe. Wonder how i haven't stumbled on the channel before
Over the years, it's easy to loose track of context. This video sums up.
So glad it was helpful!
This was so helpful, thank you! I still have one niggle: Your Suspense example conflated empty state and loading state.
It's a great explanation I've ever seen , I've been struggling to understand Suspense and useTransition hook ;)
Glad it was helpful!
Have to subscribe immediately after watching your video. Appreciated
Nice info guys 🎉. Excellent presentation
One day React is going to be awesome...
Five years invested in workarounds (mind you, not solutions) to problems inherent to the React model. The concurrency applies not to updating the DOM (which you can't do concurrently) but to all the extra work React has to do *before* updating the DOM. All this scheduling work accomplishes (if used correctly) is optimize *perceived* performance - but the framework is actually net slower than it was before doing this extra work. Meanwhile, other frameworks such as Solid, Svelte, Imba and others have moved on to a model that updates the DOM directly, instead of doing all this unnecessary work on an in-memory duplicate of the entire DOM, which has to be reconciled with the real DOM before doing actual DOM updates. React keeps adding layers of complexity to get around a fundamental design issue - and developers seem to have the perception that all this extra complexity is inherently necessary, and even ironically take pride in knowing how to apply all the new performance features to achieve acceptable performance. Meanwhile, other frameworks are moving on to much simpler models, where these performance features aren't even necessary in the first place. Regardless of how pointless this effort is, there's a market for it, there is job security, and so on - apparently that's the only thing governing the success of any framework in this industry today. 😕
Thanks for watching!
what other frameworks would you suggest ? im still new to react and i would rather not invest too much into it if another framework is objectively better
Perception of performance is often more important than factual performance when it comes to UI, but doubly so in the boardroom.
"optimize perceived performance - but the framework is actually net slower than it was before doing this extra work" -- you've just described horizontal scalability
Are you saying it's possible to have component based architecture, rerender on state and update the DOM directly in a single page application without reload and without a reconciler? If you could recreate react without the diffing on DOM component and no major drawback then people should start writing the library.
Great content; subscribed
Welcome!
RIP Harambe
🍻
I've done this on our corporate's multi user client management/invoicing/payroll system for like 10 years now. I guess it's about time, maybe one day these things will be usable instead of me having to make everything myself.
RIP harambe
RIP 🖤 (Thanks for watching!)
Terms low level and high level are so confusing in inherently high level ecosystems.
EVERYONE NEEDS TO WATCH THIS! History keeps repeating itself! Notice how we keep hearing about 5 times it improved something but didn’t work on a large website. The test of a great pattern or architecture is if it was done everywhere does it still work well and is easy to maintain? Yes and it is good, no finds areas of improvement
Great videos, learning a lot.
2 thousand freaking days! For something that we probably don't need, for a library that will probably be replaced in the next 3 years.
Thanks for watching though!
Oh definitely. Most popular framework will totally be replaced in 3 years. Sure.
@@DanKaschel it doesn't matter if it's the most popular, many libraries have been replaced before, React is no different and WILL certainly be replaced. I wouldn't have said this 1 or 2 years ago, but now most people are aware of React's flaws that we try really hard to avoid React, whether it's using a patch meta-framework or another library.
I personally hope it's solidjs, maybe it's svelte idk (both of these have greater levels of satisfaction than react btw)
I wish Harambe was still around to see React 18 😭
I like to think that he's using React 18 in heaven right now.
useId seems useful, I've been passing down uuid to generate unique ids for form input for a while now.
Yeah. Esp nice since the id is stable across the server and client too.
lovinng the content
Thank you!
The next course will be on react query I guess?? 👀
ui.dev/react-query 😘
One more reason why they did not go with the service workers is the expensive context switch to perform the task. In case of state calculations it becomes even more evident and obvious to not use workers.
Wow impressive video. You have my sub :)
Welcome!
Beautiful tribute to Harambe. RIP
Great presentation
Thank you!
Great work 👏
Thank you!
Really great content!
Appreciate it!
Great video, thanks. what do you think about the future of Svelte (Sveltekit)
It's bright! We'll have a video on it soon.
Great explanation :)
Thank you!
Thanks for the awesome content
Great content ty.
Thank you!
Awesome video!
Thank you!
In the input and list example you gave, how's using the new concurrent mode different from debouncing the rendering of the list on input change, as far as visual rendering performance is concerned?
Great question. With a debounced input, you would have to wait for the debounce to timeout before the list work even begins. With useDeferredValue, the input state updates immediately AND the list work begins as soon as the input state changes. With a 500ms debounce timeout, useDeferredValue improves the speed by 500ms minimum.
@@uidotdev In that case, how is React able to stop rendering of the current list in between when a new state change happens in input? If all this is happening on the main thread, then it's not possible to stop rendering of the list in middle, as js code runs synchronously in the browser, and the input change can only be processed in the next tick of the event loop.
That's what the Fiber reconciler in React 16 provided - a way to pause low-priority work when something with a higher priority comes in. Part of it is also the `requestIdleCallback` feature in modern browsers.
This video goes into much greater depth about how Fiber works, and how it paved the way for concurrent rendering. ua-cam.com/video/ZCuYPiUIONs/v-deo.html
These story videos are amazing ✨. Please cover vue/nuxt as well.
Planning on it!
We is this so high quality dammit!?
we don't deserve this kind of good quality lol
You do deserve it! ❤️
I got more knowledge about react in one video than my first year of using react..
Another excellent video on how ill-conceived react is. A never-ending trail of fixes disguised as features.
Thanks for watching! 😂
Man I wish my boy Harambe was here to witness this updatw
🖤
Beautiful video i love it 💕
Thank you!
Great video, didn't understand a thing, but great video nonetheless.
Hahaha I appreciate you watching and commenting regardless! ❤️
It's still a bit unclear whether upgrading to React 18 is a good idea yet; especially if you are using Next (e.g. Suspense is discouraged for data fetching). Would be great to get your ideas on this Tyler? Thanks
If you're using Next, I wouldn't worry about it.
That's one one giant small step for leap for mankind. man,
😅
useDeferredValue is debounce an alternative? It's a little confusing as a beginner
Yes. Think of it as a smarter denounce that is aware of what react is working on and when it's finished.
Great video
Thank you!
When is the server side components coming . ..?
Hi. Can you do npm vs yarn? or something like that.
"We're in the endgame now"
All this investment in order to settle on a built-in lodash debounce methodology. Seems like hype and buzz wordy solutions to a problem seasoned developers already know how to solve.
I complained a lot when Hooks was introduced. Now I have some clue why thing is what it is now.
I'm still really confused on Suspense. How do I tell react that a component in Suspense's children is not ready yet?
brilliant
Thank you!
Ah, Papyrus font in the outro. Trolling UI people, I see...
My specialty.
Hey! Nice video. What tool do you use to animate these videos ? :)
as a person who just started learning react i have no idea what this video is about :")
You'll get there!
And you probably don't really need to know. One thing that is under-communicated in React discourse these days is that all these new primitives and performance optimizations are not necessarily needed. A small and relatively simple React app will still most likely perform acceptably. React is still the same at its core as it ever was, with most importantly a very good component model. And its very close to plain js, which is also a good benefit. If you truly need more power, then React now offers primitives to achieve this. But you don't *have* to use any of them.
So for now we kind of "opt in" to these Concurrent Features on case-by-case bases in the same manner we would identify a complex situation that calls for Memoization?
Pretty much, yes.
@@uidotdev thank you 🙏
Sorry, but I don’t get it. I’ve never come across an instance where I would need this (I think). Do you maybe have some real world example of where this would be absolutely necessary?
They are rare, tbh. Essentially when you have rendering perf issues.
He got my undivided attention when he said harambe was alive
Remix video maybe? Or vue?
Yes and yes. Soon.
@@uidotdev niceeeeee ty! :D
What a great video 🤍🤍
3 years ago I decided to do more front-end work and learned react, hooks where the way to go. Went on a couple interviews and they cut me dry because their codebase was still in older react versions and I couldn't use hooks. I learned from an old colleague same shit went on with Vue. Frameworks where chaning too fast for the corporate world to adopt and new releases were considered unstable bacause custom components getting incompatible... I got so frustrated I devoted to Svelte, new kid in the block but simple AF. Long story short my components from 2019 still work on latest svelte and I can inject them in any webpage, no matter what framework it uses. Best choise I've ever made.
I mean most older React components will still work too. They might throw some warnings now but there is nothing wrong with progress
Ooooor you could make rendering the list less expensive by building a faster VDOM or just not using one in the first place ;^)
Svelte agrees
Long live react
Thanks for watching!
Why can't I just use something like debounce or throttle in that example instead of using useDeferredValue ?
Those aren't aware of what React is working on. UDV is like an intelligent debounce that is aware of React's current workload.
@@uidotdev makes sense thanks
It is and always will be too soon 🖤🦍
🖤
now that concurent is here. what's next in line?
Data fetching with Suspense seems to be the next big thing.
@@uidotdev does Nuxt 3 js has something similar?
Sorry I am still learning things.
Harambe was alive haha oh starting it off with a heart breaker
🖤
Umm yea. Just through state in Mobx and call it a day.
how do you make animations like this?
It's a combination of a bunch of stuff.
So React is finally catching up with what Angular has been able to do out of the box for years now? Am I missing something?
Yes, you're missing a lot.
@@uidotdev I figured. 😆
@@uidotdev can you please explain?
Will you be updating your courseware to React 18?
Yes. And more.
great content 👏👏 keep it up !!
Thank you! ❤️
"this is not a performance problem, this is fundamentally a scheduling problem"
Keep telling yourself that 😅
😅
Let them believe it