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. 🖤 🦍
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.
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
@@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'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
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ZCuYPiUIONs.html
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.
What's wrong with web developers guys? this is a solved problem for almost 30years now, don't put expensive and unpredictables tasks (like a network call) on the rendering loop, so simple.
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.
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?
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?
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.
