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. 🖤 🦍
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.
really great context about async rendering in React ! Really cool to have alternative apis for delaying user input (debouncing/throttling) user input like useDeferredValue
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.
@@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)
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. th-cam.com/video/ZCuYPiUIONs/w-d-xo.html
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
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
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.
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
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?
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.
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.
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.
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!
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!)
Another video, another banger. Thank you for producing such high quality videos for us devs. Always pleasure to learn through these
Thanks for commenting! ❤️
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!
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!
Becoming a fan of your work Tyler. Glad to see your effort delivers quality output and also well received by devs!🔥
Thank you Lax!
Loving your content, keep it up!!
Thank you!
Harambe was like father to me
🖤🖤
Your content literally made me pause to check if I had subscribed, this is some top shelf content.
❤️❤️❤️
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!
Coming from today's newsletter 😎 thank for this clear and really interesting video !
Thanks for watching!
Just found the channel. Had to subscribe.
Great work!
Welcome!
Thank you, Tyler, quality content as usual.
Thank you!
Its scary how small this channel is. Keep the awsome work man ❤️🔥
We'll get there. Thanks for watching!
This made so many things clear! Thank You for your work. ✨
It was smart that they went with the approach of concurrent "features", instead of an all or nothing concurrent "mode"
Glad that I discovered your channel. Thanks 🙏
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!
First time discovering this creator, liked, subscribed and commented. Nice job.
The react team left us in Suspense!
🥁
First time seeing this channel, and I gotta say, the animation and quality is amazing! Keep up the good work!
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.
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.
Loved the video Tyler, keep it up.
Thank you!
Finally more people are viewing this amazing content .
❤️
Great video and fantastic explanation, thanks heaps!
You're welcome. Thank you for watching!
awesome high quality content. I'm surprised why you don't have millions of subscribers yet :D
Thank you!
your videos are very very very informative, thank you very much for explaining all these things brilliantly
It's a great explanation I've ever seen , I've been struggling to understand Suspense and useTransition hook ;)
Glad it was helpful!
Over the years, it's easy to loose track of context. This video sums up.
So glad it was helpful!
The quality of these videos is unbelievable
Thank you!
I wish Harambe was still around to see React 18 😭
I like to think that he's using React 18 in heaven right now.
Have to subscribe immediately after watching your video. Appreciated
This was so helpful, thank you! I still have one niggle: Your Suspense example conflated empty state and loading state.
This video made me subscribe. Wonder how i haven't stumbled on the channel before
RIP Harambe
🍻
One day React is going to be awesome...
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 content; subscribed
Welcome!
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)
lovinng the content
Thank you!
Wow impressive video. You have my sub :)
Welcome!
Beautiful tribute to Harambe. RIP
Great videos, learning a lot.
Terms low level and high level are so confusing in inherently high level ecosystems.
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.
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. th-cam.com/video/ZCuYPiUIONs/w-d-xo.html
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
Really great content!
Appreciate it!
These story videos are amazing ✨. Please cover vue/nuxt as well.
Planning on it!
The next course will be on react query I guess?? 👀
ui.dev/react-query 😘
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!)
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.
Great work 👏
Thank you!
Great presentation
Thank you!
Great explanation :)
Thank you!
We is this so high quality dammit!?
we don't deserve this kind of good quality lol
You do deserve it! ❤️
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.
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.
Thanks for the awesome content
Hi. Can you do npm vs yarn? or something like that.
Awesome video!
Thank you!
Great content ty.
Thank you!
When is the server side components coming . ..?
Beautiful video i love it 💕
Thank you!
I got more knowledge about react in one video than my first year of using react..
Great video, didn't understand a thing, but great video nonetheless.
Hahaha I appreciate you watching and commenting regardless! ❤️
Remix video maybe? Or vue?
Yes and yes. Soon.
@@uidotdev niceeeeee ty! :D
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 🙏
Man I wish my boy Harambe was here to witness this updatw
🖤
Another excellent video on how ill-conceived react is. A never-ending trail of fixes disguised as features.
Thanks for watching! 😂
Ah, Papyrus font in the outro. Trolling UI people, I see...
My specialty.
That's one one giant small step for leap for mankind. man,
😅
It is and always will be too soon 🖤🦍
🖤
Hey! Nice video. What tool do you use to animate these videos ? :)
I'm still really confused on Suspense. How do I tell react that a component in Suspense's children is not ready yet?
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.
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
Great video
Thank you!
how do you make animations like this?
It's a combination of a bunch of stuff.
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
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.
brilliant
Thank you!
I complained a lot when Hooks was introduced. Now I have some clue why thing is what it is now.
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
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.
Will you be updating your courseware to React 18?
Yes. And more.
Long live react
Thanks for watching!
What a great video 🤍🤍
"We're in the endgame now"
He got my undivided attention when he said harambe was alive
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?
Harambe was alive haha oh starting it off with a heart breaker
🖤
great content 👏👏 keep it up !!
Thank you! ❤️
Umm yea. Just through state in Mobx and call it a day.
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.
"this is not a performance problem, this is fundamentally a scheduling problem"
Keep telling yourself that 😅
😅
Let them believe it
Should be little project with all new features