This is actually a good change. We are seeing a literal 1 second delay in skeletons showing due to expensive rendering passes down the tree. React better release their component to fix this though.
Im not a JS dev but im confused by the logic applied from react devs. WHY would you change the default behavior of a functionality if there are other options or rather it should be the developer that fixes the issue. If you have an expensive component why not make it also be self suspending that would eliminate the need to throw away the first render. Or if that is not possible than why not add an "attribute" to Suspense defining how it handles its children. for example default is "parallel" if you need to you set it to "sequential".
because it is not changing any default behavior. Suspense is going to be release in full with React 19 only. The behavior that these lib authors used was still beta. If you didn't notice only lib authors are complaining about this, because they went ahead and used React's internal/beta features.
Suspense is actually great, though. If you're currently not using suspense in situations you could benefit from, that means you're effectively waiting for everything to load before showing anything to the user which is worse than even the react 19 version of suspense.
"Still recommend preloading but recognize it's not always practical" What do they mean by that? Sure you can preload initial data serverside but if the component is dynamic with dynamic data (like what most of react is used for) you need parallel fetching. I have no idea what they were thinking with this. Am I just missing something?
Dude, they literally call SPA approach a "legacy mindset of building FE apps". Going all-in for the Backend-centric rendering. Now we're expected to clean freaking browser cache from the server... The proclaimed benefit is "performance" but IMO it's more about control over ecosystem than anything else.
@@IvanKleshnin I'd get it if this was ruby on rails or laravel + livewire where serverside rendering is integrated properly, but they expect us to do that in NextJS ? Yeah no, that's crazy. The whole point of react is client side responsiveness, if they take that away might as well use HTMX+backend of choice and call it a day.
@@andrewdrone yep, just today we've got another controversy. This time it's React-19 being 6x slower than React-18 on some SPA example. The release is suspended and they apologize like "We forgot that many people still use SPA and other legacy tech. But don't worry, we'll fix your problem". So, assumingly, it's a shame and a problem that some people use SPA and don't buy into new shiny NextJS approach @_@ I agree with all your points btw 🤝
Hey Josh. very basic question :D. What keyboard and mouse you are using? im currently looking for a "good" keyboard for programming and personally i dont like the 100% keyboards
Very curious to see what the solution to this is since they’ve walked back. Seems they liked this feature at Facebook and it helped them. Easiest way would seemingly be a prop for the method, parallel or waterfall on each Suspense. Default it to parallel.
No nooooo , i try it before , its awesome but has less community packages / libraries and the support of typescript in svelte components is weird Thats it everything else is good
@@gamingwolf3385 I believe Svelte 5 solved the inability to use TS outside . Generally, yes, Svelte has a smaller community, but I find shadcn-svelte works great, and TS/JS libraries work without a framework-specific wrapper. I far prefer it to React
Great vid mate! Sure it's good they listened... But why did they make such a breaking change without feedback in the first place? JS land is embarrassing at times.
@@gcash49 What qualifies to be objectively better? perfs? bundle size? reactivity? maintainability ? DX? cause react is behind in most of these aspects. But definitely react has a very huge community and a lot of loyalists.
I really don't want to criticize your video. However, I believe that those who find this a breaking change are not truly familiar with the framework and are just following trends. For instance, the definition of Suspense in the initial React 16 (now React Legacy) was: ```React.Suspense lets you specify the loading indicator in case some components in the tree below it are not yet ready to render. In the future, we plan to let Suspense handle more scenarios such as data fetching.``` If developers now have unoptimized code that wraps multiple different queries to multiple APIs, what do you expect? Just duplicate your React.Suspense for each component.
@@statuschannel8572 exactly. Honestly I think it’s great that we as a community have a voice and we can prevent stuff like this from coming out and they actually want to listen to us
@@marcuss.abildskov7175 lol only from react 19 there is a compiler and it's magic. so by your logic everyone who uses a library or framework don't know anything about software engineering. Tell me you're a blind hater without telling me you're a blind hater moment!
