For smaller projects, this seems like great chance. On the other hand for major enterprise apps, you still want separation of concern. You will not mix your server calls with the pages, you will not mix server calls with frontend calls.
PHP devs nowadays (not WordPress devs) actually care a lot about separation of concerns haha. It's the JS folks that made mixing concerns "cool" again, in the name of speed and ease of development
All this "JS-Everywhere" journey (and ssr in this case as an extent of that) that the Industry has been on is imo just finally embracing that you cannot find a technical solution/barrier to the problem of "shitty programmers will write shitty code". If you want to have a nice codebase you will always need clear goals/feature sets, good devs and enough time. So you might as well have something that gives you all the options - something that lets you run your code on server or on client properly. More options make it easier to write better code (to some extent). Trying to remove options/making an option more difficult in order to prevent bad/undereducated programmers from writing shitty code just doesn't work out in practice. But I'm sure that the eternal pendulum will eventually revert in another 5-20 years and we'll all be writing another Java/C# derivative with the most rigid of structures again.
So true...lemme see if I can find where the problem is in the jungle of code...O here it is in the middle of 32 promises that the debugger can't navigate.
It sounds like I'll have to relearn a foundational concept about how to use React. I'm all for evolution, but I'd like to hear if anyone feels like using a collection of libraries or a framework can make an app more difficult to maintain compared to using HTML, CSS, and vanilla JavaScript? I used the usual suspects in a React app I built 2 years ago. (MUI, Axios, React Router, etc) As each of those libraries release newer versions, I asses if I should update the app and fix any breaking changes. I didn' t use SSR because I didn't see the need. But if React itself is moving in that direction, then I have another decision to make about keeping the app current so I can continue to develop new features. I'm relatively isolated as a dev, so I'd like to hear from the community about this.
If you have a need simple enough that hand-writing your text into your HTML, and adding some JS to that suffices, then yes, absolutely. If you can get away with just loading .md files in a fetch request and running them through a function and replacing the current document body with the result, then it's all you need to do. The challenge is when you need an app that runs in multiple themes, in multiple languages, has many user interactions, pulls data from many sources, needs to operate as a traditional application (and not like a blog or a catalogue), et cetera, the amount of code you need to ship to make that happen is immense. Yes, if you write it all, yourself, by hand, you could possibly make it much smaller and more optimized than shipping all of React, et cetera... but you are then replacing the core functionalities of React, yourself as abstractions... or, writing tens/hundreds of thousands of lines of low-level DOM manipulation, yourself, by hand. It really all comes down to the problem you have. Making a personal blog, you could do yourself with 0% JS, if you are willing to write all text and HTML at the same time, and publish individual files, and serve that from some fileserver. If you are making Crysis, and trying to get it to run in the browser, or you are building a browser version of Photoshop or DaVinci Resolve, you're going to be writing very little HTML, and mountains of JS (or some WASM-compiled language plus JS bindings) / WebGL / WebGPU.
The problem with this that I just can't get over is the server-side await thing. That opens the potential that people are going to think you can use await everywhere. So you could have a component tree with nested await. Then every time you call that page, you could be SSRing and then pausing to await and then SSRing and then pausing to await. I don't think that's actually better than getServerSide props which, for it's awkward limitations, enforces the one place where you should do all of your async SSR logic. I also don't hate the T3 model where you just don't SSR that data, you grab it from the SPA perspective, but I could see this kind of flow slowing down builds for SSG even if SSG becomes more adaptive to different scenarios. Obviously good devs will learn/know to avoid this but I think this will become the next big React foot gun.
The problem with SSR is that you can have only one call per page which really restricts your development. I use it wherever possible, but I have a dashboard with a few cards - all of them pulling data from different source.. I use react query to tackle this (like many others), but with this.. It's just a game changer :)
@@CryptoDigger yeah and that limitation is a pain, but the model described in the Layouts RFC would really cut down on that limitation (and if you structure your pages well, it could eliminate that limitation), while cutting down on linear promise resolution because if you know what route you're on, then you should know what layouts need to be run, so they should theoretically fire off nearly in parallel.
@@EthanStandel so, for a react simpleton like myself, this enables next to do what remix is doing where it addresses waterfall requests and allows them to flow to a central promise resolver rather than chaining them in staggered lookups?
I didn't realize it was broken. Wait...why are we going back to SSR? That's the past. Client side rendering with XHR is just so much better. Or maybe I'm just stupid. But I just spent the past 10 years moving away from server side rendering and now I'm supposed to go back? Why?
Hmm interesting I quite really like ssr and majorly use ejs with node And i think enabling react to be ssr will come in handy as most people who do ssr will be able to harness the npm packages that come with react This would expand boundaries to many things
@@ezrakeeps like I’m not saying you are wrong, because I don’t know everything. I’m fact I’m constantly amazed at how much new stuff I am behind on. It just feels odd. Is all we are gaining from this is bots can crawl a pre-rendered initial page and there isn’t a short loading interstitial. It just feels like we are going to a lot of trouble to solve such a small problem. And it feels like we are coupling our front end to our back end instead of just creating an api that can be used by anyone. But then again I suppose we could just make an XHR call to a separate service from where ever the Next.js assets are being served from. But I digress, clearly there is some learning to be done. I am just salty that the paradigm is shifting again :/.
@@buresj you make an excellent point. I think either way it feels like a huge paradigm shift. One I’m sure I will adjust to. It just feels wrong. Then again I used to feel that way about React until I started using it. The way it melded controller and view together just felt so weird compared to Angular and Vue. But now I can’t imagine it any other way. So perhaps this will too.
This feels so tightly coupled to the backend that I only see headaches in the future. Can someone provide a counter argument as to why I would want to tightly couple my client to DB all for the sake of SSR ? Is there anything else than SSR to be gained here ?
Does it mean that with server components we won't be able to host the React app as a static text anymore? (seems like yes) If so - this will raise costs of a hosting and removes clear client/server separation, so I really doubt that everybody will use it
Great to see this FINALLY. Anyway...since we as devs all secretly love torture. What's next on the list we really really get frustrated about why it has to be like it is?
It could be the new stage, where the developer finally could say enough in the front-end side (cuz it is simpler) and can re-branding to become full-stack without sacrificing the UX on FE side
I honestly don't think front end is simpler at all. Backend work feels like a breeze these days, I'll admit though that my backend work is basically writing resolvers for gql. But I dev find that easier than making nice looking responsive components that arnt full of bugs.
Feed me with more personas as Theo & Primeagen for my opinionated devheroes squad please! This content lowers beginner confusion a lot. The practical examples & direct comparisons of old form & mechanics to new explain everything so well.
I still don’t entirely understand how these new async server components can be used in Next.js. Isn’t a big part of Next.js that all components can be rendered on both server and client? This is how the framework supports page navigations without full reloads. This would not work anymore if some components can only be rendered on the server. Am I missing something?
Been in this industry for 10 years, I find all this very funny. Won't be long till we realise what a disaster all this is and go back to actual SSR like jinja lol. It's all so needlesy complex. All we're trying to do here is render html...
In my Opinion, this sounds like a bad change, if I'm wrong please correct me, but it promotes API-Second Approaches and Monolithic Architectures. Isn't that the stuff PHP is hated for, at least among Software Architects?
Wow. This is exciting stuff. I've been a bit skeptical about Next lately after my experience trying to deploy an app I built with Appgyver which builds into Next. It spit out working code that I simply couldn't understand, and it got me interested in how no-code platforms are built. I'm currently experimenting with generating Vue components on a Rust server based on user inputs as a sort of prototype, but that architectural comparison you laid out toward the end gave me some perspective as to why the Appgyver team may have gone with Next as their build target, though this was only recently achieved. It would be really cool to see some big improvements in the no-code landscape as a result of this newfound backend superpower.
@@andrerosenkilde yes, something like that. I have worked with document signature, but I want to create a product where the client can establish the workflows for their documents. For example, here every year the salaries are updated according to the inflation and the employees must sign an addendum to the contract to reflect the salary update. I want the client to be able to define how the document is signed (someone have to approve? The order of signing matters or not?) And add other services which they can choose to use or not in their workflow (notifications, cloud storage, immutable storage, etc)
I wonder what this means for testing. Are there going to be lots of focus on mocking mechanisms? Writing tests for a component that fetches data directly like that prisma example is not going to be super simple. One might say you can just create your own mocks with jest or vitest, but what about component testing tools like Storybook, Cypress and Playwright ?
Server first react is great but it feels so weird calling data directly from prisma in a component. Is there a way to always know if a component is server or client? I’m scared to expose server side functions to the client and this doesn’t feel like there is a clear distinction anymore.
Running on server by default sounds good in theory but if the processing is now mostly on the server, and you're working for a company that watches the pennies, how will this effect server CPU time costs? It's got to be so much more expensive to run?
Let’s say there’s an endpoint that takes 20 seconds to complete (some bigdata request that does a lot of work with a lot of data). How should React, well, react to that, according to this new approach? If there’s no loading stuff now.
As I understand it you just don't handle loading states in your components directly but rather as a suspense fallback. There is still loading states as I understand.
Well your promise would be fulfilled once the endpoint request completed correct? So now you just wrap your component with a suspense component and in that Suspense write whatever happens before the is fulfilled. Your Suspense fallback is where you would write "Loading..." whatever.
@@rutabega306the virtual dom brings in a lot of overhead so for someone with slow internet they would have to wait a bit for the page to load. While there are definitely frameworks that reduce the overhead as much as possible such as preact. A framework that has a vdom also cant say they have true reactivity since the entire dom updates whenever a component rerenders while for instance solid-js only updates the component in the dom.
Well done mate! I appreciate your work!) But to be completely honest it’s kind a marketing thing in transition between OldMethod and NewMethod. I mean with NewMethod you’ll have to make API call every time when a component renders. Otherwise you have to store the response in state like you did in OldMethod. Of course you can move this logic to prisma but you can do it with OldMethod as well. So it’s not clear how we can avoid useEffect/useState.setState with this sync/await stuff
@@BleedingDev Almost like the stale-while-revalidate cache invalidation strategy never existed. Imagine if Vercel had released a library called useSWR back in 2019 to solve this exact issue, life would have been so different... 🤦♂
Wow this is great. The main issue with react is that it's easy to end up writing a lot of code to do a simple thing. Couple that with devs who haven't used react much and you get a massive spaghetti mess of useeffects. Hopefully this more clearly outlines the structure to follow and cleans it up a bit.
Yeah, react is still a hard pass. I won't learn all this new stuff just to find out next year that this feature has a lot of problems and now we have to rewrite everything again
What lol? React is simple to get started in and this whilst it's a big change doesn't have to be used. It's just another option. If you don't like learning then enjoy being stuck in php land forever.
@@ChillAutos it's not about learning new stuff, it's about learning new stuff and then realizing it comes with a lot of problems and side effects. Maybe you're stuck in react land 😉
react being server-first is utterly stupid. we select the language used for a given project by the requirements. if the requirements were, that the thing runs on the server, with server side rendering, we would have selected php.
Most companies I have worked for use react with no thought to the affordances of ssr. PHP is seen as antiquated and the talent pool is slowly drying up. Plus PhP has none of the client side affordences of React.
@@DrClocktopus1 that seems not like a proper assessment. most "big player" software on the web ist still written in php. version 8 with jit compiling eats javascript for breakfast, performance wise btw. the "talent pool" argument comes up from time to time, but i never understood that anyway. we hire computer scientists, not persons that have a limited skill set in a particular language. i would expect every employee to master any language in less than week, if necessary.
tried implemeting a serchbar with relay (which doesn't have loading and error states) and it is bad, had to switch back to react-query because i don't need the suspense fallback covering the screen while the query runs
Relay is extremely powerful for those that know how to actually use it… if you want to build something small then don’t use it. If your building a powerhouse app it’s a solid choice
Gosh, i have been learning html,css,js, node for a few months, and wanted to learn react now. Should i even try to learn it from ”old” videos, or should i just wait until someone uploads a whole new tutorial on it with all of the updates included just to not confuse myself?
Seems like react just became a little more like Laravel. I've been learning the Laravel over the past couple years and thinking about learning react after a project I'm working on currently. Wondering if this would make the learning curve a little less steep
It won't replace Laravel, it won't replace your back-end (API, database communications, mailers, etc..). The only difference is that your front-end is now *really* generated on the server-side the same way PHP does it.
I'm not sure, getServerSideProps just fetchs data on the server and you pass this data to your regular component, here it seems you can write server side code directly inside your components like in his NewMethod one
@@heroe1486 yeah, but the result / behaviour is the same, isn't it? it's not like using await inside the component will cause any client-side fetching.
UI that is literally married to business rules? What a terrible mistake. This is a cool two-liner for an example. But this will not scale to the needs of enterprise software. React is better when it's unopinionated. Because if you want to design your codebase into the ground (which I have seen everywhere), it was your choice. Now, we have guardrails to ensure that it is run into the ground.
I am a desktop developer and just started learning web dev, but havent reached react modules in my course yet. Should I find a new react course with this updated version ? Or learn the older version anyways? Asking because it seems web devs really seem to hate the old/current reactjs. Thanks
I would just keep learning with react hooks and try to keep an eye on this stuff as it come in over time. The thing about web dev is that it is always rapidly evolving, and if you're always trying to learn the next thing in advance before just digging into what's relevant now, you'll never actually catch up.
That's Remix only, but since this is React wide, any React framework can take advantage of it. In a way, creating Remix paved the way for this big React change, it looks like to me.
And Nuxt (when Nuxt 3 finally comes out), and SvelteKit, and SolidStart, and all the MPA frameworks. So this is big news for React/Next folks, but nothing groundbreaking for others--am I getting this right?
@@zzzyyyxxx i don't have a problem with react itself getting new features! but the way he talks about it makes it feels like a revolutionary thing however it's not and there are react based framework offered the same thing! anyways my question is more of a verifying my info than arguing
I do see the appeal of using suspense to avoid loading spinner hell. But I don't understand the part about calling prisma in the component and react being 'server first'. Is that a new feature in Next or React?
Also would it be more dangerous since you're putting the call to your database very close to the user side without any real input validation? Since it's so compact idk where I would implement server side request validation
9:39 "How do you express the loading state." "There is no loading state to express. It blocks until the data is there." "The loading state is a side effect of bad architecture" Okay... but if it's blocking until the data is there... doesn't that mean it's loading in some sense? And don't you want to express that the app is loading to the user? I wonder if the question was too simple for your level of expertise, and you misunderstood the simplicity of the question... Here's what I think you mean, and correct me if I'm wrong: It sounds like what you're saying is that the server doesn't respond to the request until it has a fully rendered page or component for the client that will not require the client to make any more requests to load components, because the components were fully rendered server side, and that is opposed to what used to happen, which was the "bad architecture" of loading a component partially, sending that to the client, then the component sending a request for more data which is on the server, which should have just been sent all at once with the component in the first place, considering how long requests take to go over the internet, and so now you need loading spinners, and then every level of your component that loads is requiring a loading spinner, and that's what causes loading spinner hell, so... the new way is better, no more loading spinners. Right?
So if you have an async component, it's rendered on the server. From the code you've shown, it doesn't seem like there is a way to have reactivity/state from inside this. From the RFC, "A limitation of async Server Components is that they cannot access Hooks. We don't expect this to be an issue because Server Components are stateless and Hooks are rarely useful in that environment. However, you can use supported Hooks (for example, useId) inside Server Components that are written as regular functions." So it possible to do more than just display a list of data with this method, and if so how?
@@theklr oh 100%, it’s just that I’ve been getting a somewhat “anti-remix” vibe from Theo, who otherwise has takes I wholeheartedly agree with, and I’ve never really known why. When he treated this as revolutionary, it made me wonder “then why don’t you ever talk about remix in your videos?”
It's a little different, same problem but it's a more flexible strategy. Remix has the opinion that the data for your app should correspond with the routes that you have. I'm getting the sense with this strategy you'r data control is by component, not by route. I'm not sure if that flexibility will actually result in people making better apps or not. I think remix kind of hit the nail on the head that data usually corresponds with routes. But I imagine there's sometimes where a solution to component level fetching will help remix-ers (Can we call ourselves DJs)
@@jon1867 I think that if for some reason you want data fetching at the component level, it probably does correspond to a route especially considering a Nested Routing setup
I see why folks don’t like JavaScript. I started with it and recently been doing work in go. JavaScript community is such a mess. I’ll learn this but geez
Exactly. Most JavaScript developers are junior developers with a lot of "experience". Stick to real non-Javascript backend. It makes more sense, pays more and has a ton better tooling. Go is awesome.
I'm curious on how this all will come to the React Native ecosystem, i feek like as react progresses, react native stays kinda stuck in time. I would love to see both technologies merging more in the future since i do a lot of work with it.
9:39 Wait wait, does this make React based apps not SPAs anymore? As in the js bundle is no longer sent to the client? Now the page load blocks untill all the suspended components are rendered to HTML and that is then delivered by the server? Im quite confused, can someone help me understand?
We have come full circle haven't we? We started with server side static HTML, it felt too bland so we invented stuff like jquery and dom manipulation libs, manual dom manipulation got too complex so we invented libraries like react, turns out doing everything on client side was a bad idea so now we need to go back to statically generated HTML again.
To those who recently began to program, this appears to be a brilliant ideas. I feel this is full bat shit -- the effort is awesome, but the collateral damage won't be accounted for.
Are we at that time of the year where hype zombies get excited with more broken trivial updates that only bring more problems, breaks legacy code, and only exist because their hype tool of choice is completely broken? REACT UPDATE: It feels like building a paper boat and trying desperately to fix it with more propaganda paper. JavaScript was always enough for 99% of cases.
We're at that time where people stuck in their ways, feel enough change to come out of their caves... And exclaim the same boring arguments against change, we've heard the past 6 decades.
@@neonraytracer8846 OMG that new hype corporation just announced a new way to do the same exact things but in a new hyped way that is much worse, bloated and inefficient than before, but makes them much more money. OMG Let's change our ways, spend our time and money to make sure they'll profit upon our indoctrination. OMG Hype Zombies for the win! Propaganda Oriented Programming is so much bettern't! 👍
webdevs will this finally make you acknowledge that most of the people in the world that access the internet use it in their phones and stop making jittery sites that scroll hijack but popping content in minutes after the site has loaded just at the right spot for you to click it by accident?
So, the type safety thing -- isn't this exactly what GraphQL is for? That or you have an interceptor layer in between your API and your front end that spins up concrete models/contracts before they're consumed by the front end. Serious question, not asking to be a jerk.
It’s so much more work to set up a graphql server. Then once it’s created you have to manage it. This allows you to get the type devs directly from prisma.
Nice video. IMHO I don’t quite understand it yet. If we are now calling the DB directly on our React code, then what about all of our Json endpoints? Do we loose them? We are essentially skipping the API creation part and instead running the DB queries directly on React. Meaning we no longer have a Json server which may be usefully if we have, for example, native apps that need to get data from it. Am I getting something wrong? Thx
Well yes and no. The reason this is happening now is because we have Edge computing of SSR. This is the only way this is viable at scale. NextJS has a layouts RFC detailing how this is gonna work. You can decide if you wanna have a JSON backend or not. If you’re using rest endpoints now (then I assume you’re using a fetch library for those). It’s as simple as flipping a flag in SWR, urql or React Query, setting suspense: true. These hooks will switch to returning promises and make the request on the server to the server. No further implementation is needed. And you can keep your JSON server API for external apps :)
Just going to go out on a limb to add the usual caveat: this is going to be a powerful tool that is good sometimes, and should not be used at all times. If your SSR output is hinging on all network / DB calls from all components completing, and inside of a bunch of components, someone has made the cardinal sin of sequentializing many async calls that could be parallelized, just because they're allergic to Promise, or the services that are called do horrible things with the data, this will result in *terrible* load times for the end-user (whether the fetching is done as part of the SSR, or the fetching is done from the client determines if the page is all-white, or a skeleton). A handful of oracles will become the "load-perf gurus" of the next generation, knowing where to parallelize, and knowing which layers to inject Suspense into, to make the rest of the app usable on a 5 second query to some ancient Java 7 system... None of this is to say that it's a bad feature, or a bad path. It's a good tool that, in large production environments, will require more knowledge and nuance than it appears.
You do realize when a React component makes an API call client-side, the API is doing of all those DB calls ? If they're done server or client, it doesn't matter.
@@charlesm.2604 It matters a lot. Let's forget about React, for a second. Presume it's a Java server that makes a bunch of DB calls, and those calls take 5 seconds, before it spits out an HTML page. What does the user see when they go to the site? A white page. How long do they see it? 5 seconds. Now, let's say we are in a case where we have hand-written the front-end HTML/CSS and there is enough JS to make calls to the server (and those calls still take 5 seconds). What does the user see when the page loads? Whatever HTML/CSS is already prepared, plus spinners for widgets, or a spinner for the page. For how long? ~5 seconds. Actually less, because in Java those requests were made in serial sequence, whereas in the front end, you could have the browser parallelize ~6 at a time, as long as you don't do something like `await` all of them, one after the other. See the difference? The second one sucks. In the first one, the user doesn't even know if the request has gone through. And that sucks even more. A really good experience for a web site (not an app, but a traditional site) would be to load whatever you can in the first ~300ms (the "front page"), serve that while caching the responses for the other data that was primed, that will be requested and loaded in from the client side. If you have content that virtually never changes, then spending 5 seconds rendering on the server is fine... if it's not a user that is requesting the page, but rather a build step that's going to take 40 minutes to build out your whole site and cache all of the pages on a CDN. A good experience for an app would be that it loads in the shell, ideally with content, and the whole app is navigable and traversible and usable, while loading in data, which is cached on device. How long your calls take and where they are made absolutely matters. These tools are a good thing, but shouldn't be used directly by the average developer until great usage patterns and new quality-of-life tools are built on top, otherwise we will be going back to the days where JSPs took 3 seconds to load the HTML page and everyone was miserable.
@@SeanJMay I wasn't talking about user experience but about the performance aspect. Those DB calls still need to be made and wether they're made during server side rendering or upon an API request doesn't change the fact that they still happen. As for caching, server side caching exist for a reason, and it's even more effective as the data will be cached for every request, no matter if the client already cached it or not (e.g: new visitors).
@@charlesm.2604 Of course it doesn't. But the *user* is the one who *uses* the site. With no *user*, there is no reason for the site. If you give a *user* the shell of an experience and some spinners, it's a pain. If you give the *user* a blank screen for several seconds, on their first visit, you will never, ever see them again. Ergo, where and when the calls occur in the process of serving the user absolutely matters.
Yeah dude. IMO, serving the front-end from a CDN and having it run fully clientside was why I used React for my latest corporate projects. I don't see how these changes are getting so many people excited. Maybe I'm missing the point of it all?
@@weegee_ Just hype IMO. Even tough, interacting with multiple origins from the client (in a complete “serverless” way) might degrade performance because of DNS resolution / TLS setup & etc. Might be negligible.
@@IslamIsDanger the only problem I had with this approach so far is the added request time because of aws lambda function's cold starts, but other than that this approach is so far the most superior in my opinion, it's cheap, it's reliable, and it doesn't require a lot of monitoring. That's why I embraced full-on serverless coming from a serverful approach.
so getServerSideProps is same as this asyncronous Compnents now? if I understood correctly, if yes then what use has NextJS now if regular react can do same now?
and when we have a so server-side rendered component, can we perform data fetching in it in the client also? I'm thinking that you often want to initially populate with some data, but if the app is very reactive than it should perform other data fething and rerenders for components while the app is used
Is this live yet or no? If not, where do I keep track on when it’s live to use? (I’m new to react). Also is this server side thing gonna improve SEO too I guess or?
Interesting, but is the suppression of the "separation of concerns" a good thing? curious to see the best practices emerging from these new design patterns. After all, we don't want to end up like the good old days of the internet with one single file containing all the code? I'm playing the guy who is meticulous but in reality, very excited about those changes.
Didn't Vue got suspense in 3.0? And that was quite some time ago now. I mostly use Vue and always had this idea in my mind that React is the older but more advanced framework but the more I look the more I feel Vue surpassed React long ago. NuxtJS with it's asyncData is so far the best way of fetching data from server I've ever used.
It does state that it's a library, ok fair. This wasn't my point tho. But if it's just a library.. shouldn't React be at least smaller size then? Because it's not. Vue manages to do more, arguably better, while being younger and smaller size - that was my point.
going back to server side rendering :)) also the way i write apps in my vue js apps is, "you have a bigger page response, that contains all the data i have on the page (making the php API kerner on the backend initialize once) after that i only request granually" but this only works if you dont have infinite micro components in your main component calling stuff in parallel for no apperant reason yes initial load tine is bigger but what people fail to notice is the end client doesnt care, most dont even see the difference between 1sec and 3 sec loading time
If 3 sec is nothing then why not load whole backend to browser, sending server to client. After loading it's faster than edge. Next step after edge really. You already have a free SQL database in browser 😂 you also have fast bun now. One will say spread centralisation makes servers so close that browser seems obsolete. Other one will say depending on central authority is the last thing we need to keep free internet & full variety of content. And we have powerful browsers which still don't use full power (GPU). Everything moves in cycles & waves.
Nice video! Could you make a new video explaining a little bit more about the current status of data fetching with Suspense? Also, could you show more details about how these changes affect the UX?
I was on board but this video opened my eyes and not in a way that you might expect. Who's to say we're not just going back and forth between SSR and CSR? Would love to have a crystal ball and see if this still holds up in the next five years.
9:13 soooo....... it won't work on client? I don't know. We were rendering everything on server. Then we added JS. Then we started rendering on client. Now we're back on square one. But we're using js this time. Like... why?
Separation of concerns is important, or? Seems like something that could be useful for Next.js maintainers and Apollo/Urql libraries to solve some SSR issues. I get that. If you're past a simple example project you probably have different APIs (in-house and third party), different teams maintaining them, authentication/authorization, API gateways, caching layers, business logic you don't want in your UI, etc. Are we going to call Stripe to ask them to let us connect to their SQL database now? 🐈⬛
What about partial removal of placeholder of spinners when the data is available?, because instead of one single spinner you have mini "spinners or place holders" in each part of the interface that must load?
Js developers rewrite frameworks because of dynamic typing. Dynamic typing languages make easier to rewrite anything from scratch than to support existing projects. If your employer gives you task to support project written in js or python - run. RUN as fast as you can.
I curious how react-native will make use of this server-first approach, or react-vr for the 7 people using it. these are React changes right? not React-DOM changes?
I think angular ssr is still better designed. On server side, the framework waits for the state to be settled, then renders the app. With react, the components are run only once and then rendered, changing state isn't possible during server-side render. Why can't the react framework wait for state to be settled on the server, and then render the app? Why can't the state be changed before server-side render? Then, whether the component code runs on client or server, useEffect would work.
Hey React community folks, Im pretty new with React and Im not understanding what this all means. What concepts of React should I be studying to understand the importance of this new fix?
so basically we can have async components that react will 'await' automatically ? And till then a loading state will be visible. Now if there's a child that's async how do we await for it inside the parent comp ? I am excited for the answer, its so simple to have a mental model on the components execution now. Its 'suspended' until its 'ready' like any other (awaited) async function.
Regarding the example where you put `await prisma.example.findMany()` in the React component: how can that work on the client? For SSR purposes that looks cool, but what if I want to create a "refresh" button that will cause reloading the data and rerendering the component?
For someone who never worked with nextjs and only done react on the frontend, what does server component means? It’s not jamstack architecture anymore?
For smaller projects, this seems like great chance. On the other hand for major enterprise apps, you still want separation of concern. You will not mix your server calls with the pages, you will not mix server calls with frontend calls.
Great, I'm back to being a junior engineer again, lol
😂
We never left, did we?
@@oskrm 😂😂😂😂
well this is true
Same here..🤣🤦
"The ecosystem has to shift"
"No more separation of concerns at all"
"It's like PHP"
That... doesn't sound positive at all
Yep. 5 years ago the devs was justifying why the server rendering concept was bad. Nowadays, they want to bring it back. "IT IS LIKE PHP"!
Tottaly agree. For me this is a Downgrade. Misconception.
It's evolving there's no doubt about that, just... backwards
@@christianmartinez2179 🤣
PHP devs nowadays (not WordPress devs) actually care a lot about separation of concerns haha. It's the JS folks that made mixing concerns "cool" again, in the name of speed and ease of development
changes **Frontend Developer** title to **Full Stack** in resume
haha
lmao
pretends he's superman and flies away from planet Earth.
@@sidthetech7623 and actually does it
If you maintain the database yourself and host the app too, sure, why not
We went from spaghetti code to separation of concerns just to end up again with spaghetti code LOL
hahahhahaha so true
The infinite cycle....
spaghetti tasting a little better this time around. just a little
All this "JS-Everywhere" journey (and ssr in this case as an extent of that) that the Industry has been on is imo just finally embracing that you cannot find a technical solution/barrier to the problem of "shitty programmers will write shitty code". If you want to have a nice codebase you will always need clear goals/feature sets, good devs and enough time. So you might as well have something that gives you all the options - something that lets you run your code on server or on client properly. More options make it easier to write better code (to some extent). Trying to remove options/making an option more difficult in order to prevent bad/undereducated programmers from writing shitty code just doesn't work out in practice.
But I'm sure that the eternal pendulum will eventually revert in another 5-20 years and we'll all be writing another Java/C# derivative with the most rigid of structures again.
So true...lemme see if I can find where the problem is in the jungle of code...O here it is in the middle of 32 promises that the debugger can't navigate.
It sounds like I'll have to relearn a foundational concept about how to use React. I'm all for evolution, but I'd like to hear if anyone feels like using a collection of libraries or a framework can make an app more difficult to maintain compared to using HTML, CSS, and vanilla JavaScript? I used the usual suspects in a React app I built 2 years ago. (MUI, Axios, React Router, etc) As each of those libraries release newer versions, I asses if I should update the app and fix any breaking changes. I didn' t use SSR because I didn't see the need. But if React itself is moving in that direction, then I have another decision to make about keeping the app current so I can continue to develop new features. I'm relatively isolated as a dev, so I'd like to hear from the community about this.
If you have a need simple enough that hand-writing your text into your HTML, and adding some JS to that suffices, then yes, absolutely. If you can get away with just loading .md files in a fetch request and running them through a function and replacing the current document body with the result, then it's all you need to do.
The challenge is when you need an app that runs in multiple themes, in multiple languages, has many user interactions, pulls data from many sources, needs to operate as a traditional application (and not like a blog or a catalogue), et cetera, the amount of code you need to ship to make that happen is immense.
Yes, if you write it all, yourself, by hand, you could possibly make it much smaller and more optimized than shipping all of React, et cetera... but you are then replacing the core functionalities of React, yourself as abstractions... or, writing tens/hundreds of thousands of lines of low-level DOM manipulation, yourself, by hand.
It really all comes down to the problem you have. Making a personal blog, you could do yourself with 0% JS, if you are willing to write all text and HTML at the same time, and publish individual files, and serve that from some fileserver.
If you are making Crysis, and trying to get it to run in the browser, or you are building a browser version of Photoshop or DaVinci Resolve, you're going to be writing very little HTML, and mountains of JS (or some WASM-compiled language plus JS bindings) / WebGL / WebGPU.
The problem with this that I just can't get over is the server-side await thing. That opens the potential that people are going to think you can use await everywhere. So you could have a component tree with nested await. Then every time you call that page, you could be SSRing and then pausing to await and then SSRing and then pausing to await. I don't think that's actually better than getServerSide props which, for it's awkward limitations, enforces the one place where you should do all of your async SSR logic. I also don't hate the T3 model where you just don't SSR that data, you grab it from the SPA perspective, but I could see this kind of flow slowing down builds for SSG even if SSG becomes more adaptive to different scenarios.
Obviously good devs will learn/know to avoid this but I think this will become the next big React foot gun.
The problem with SSR is that you can have only one call per page which really restricts your development. I use it wherever possible, but I have a dashboard with a few cards - all of them pulling data from different source.. I use react query to tackle this (like many others), but with this.. It's just a game changer :)
@@CryptoDigger yeah and that limitation is a pain, but the model described in the Layouts RFC would really cut down on that limitation (and if you structure your pages well, it could eliminate that limitation), while cutting down on linear promise resolution because if you know what route you're on, then you should know what layouts need to be run, so they should theoretically fire off nearly in parallel.
@@EthanStandel so, for a react simpleton like myself, this enables next to do what remix is doing where it addresses waterfall requests and allows them to flow to a central promise resolver rather than chaining them in staggered lookups?
I didn't realize it was broken.
Wait...why are we going back to SSR? That's the past. Client side rendering with XHR is just so much better. Or maybe I'm just stupid. But I just spent the past 10 years moving away from server side rendering and now I'm supposed to go back? Why?
Hmm interesting
I quite really like ssr and majorly use ejs with node
And i think enabling react to be ssr will come in handy as most people who do ssr will be able to harness the npm packages that come with react
This would expand boundaries to many things
@@ezrakeeps like I’m not saying you are wrong, because I don’t know everything. I’m fact I’m constantly amazed at how much new stuff I am behind on.
It just feels odd. Is all we are gaining from this is bots can crawl a pre-rendered initial page and there isn’t a short loading interstitial. It just feels like we are going to a lot of trouble to solve such a small problem. And it feels like we are coupling our front end to our back end instead of just creating an api that can be used by anyone. But then again I suppose we could just make an XHR call to a separate service from where ever the Next.js assets are being served from.
But I digress, clearly there is some learning to be done. I am just salty that the paradigm is shifting again :/.
@@deusprogrammer_thekingofspace is it paradigm change or rather switching to the multi-paradigm?
@@buresj you make an excellent point. I think either way it feels like a huge paradigm shift. One I’m sure I will adjust to. It just feels wrong. Then again I used to feel that way about React until I started using it. The way it melded controller and view together just felt so weird compared to Angular and Vue. But now I can’t imagine it any other way. So perhaps this will too.
This feels so tightly coupled to the backend that I only see headaches in the future. Can someone provide a counter argument as to why I would want to tightly couple my client to DB all for the sake of SSR ? Is there anything else than SSR to be gained here ?
Does it mean that with server components we won't be able to host the React app as a static text anymore? (seems like yes) If so - this will raise costs of a hosting and removes clear client/server separation, so I really doubt that everybody will use it
exactly what i was thinking
There will likely always be a build script for the react server to statically render your react files to html js and css
I assume its only server first if you define your component as async? Just don't do that and its same old react
This is gonna pave the way for a JavaScript centric Wordpress alternative
Isn't that Ghost already?
WordPress can be javascript centric WordPress alternative
@@ajiteshmishra lmao
@@lasfito why, we can use wpgraphql or rest api to build headless WordPress apps
You mean Strapi?
"No more separation of concerns at all" 08:46
That got me as well lmao
And that fool celebrates it. What a garbage mess. Might as well become a php dev, especially since they are better paid
Great to see this FINALLY.
Anyway...since we as devs all secretly love torture.
What's next on the list we really really get frustrated about why it has to be like it is?
It could be the new stage, where the developer finally could say enough in the front-end side (cuz it is simpler) and can re-branding to become full-stack without sacrificing the UX on FE side
Oh hell no, it maybe is simpler but still there are tons of stuff that are really hard to do.
That's what we call going full circle
I honestly don't think front end is simpler at all. Backend work feels like a breeze these days, I'll admit though that my backend work is basically writing resolvers for gql. But I dev find that easier than making nice looking responsive components that arnt full of bugs.
Feed me with more personas as Theo & Primeagen for my opinionated devheroes squad please!
This content lowers beginner confusion a lot.
The practical examples & direct comparisons of old form & mechanics to new explain everything so well.
Agreed! Are there python dev or data science equivalents? I can't find them 😭
@@aaronm6675 become one
@@aaronm6675 check out sentdex:
ua-cam.com/users/sentdex
@@aaronm6675 Arjan Codes for python
I still don’t entirely understand how these new async server components can be used in Next.js. Isn’t a big part of Next.js that all components can be rendered on both server and client? This is how the framework supports page navigations without full reloads. This would not work anymore if some components can only be rendered on the server. Am I missing something?
I’m guessing it will be a big part of the “Layouts RFC” that next has had for a while
Been in this industry for 10 years, I find all this very funny. Won't be long till we realise what a disaster all this is and go back to actual SSR like jinja lol. It's all so needlesy complex. All we're trying to do here is render html...
Render reactive html…
@@seasonsunite Render HTML which ships JavaScript that modify the DOM. It's still HTML.
You're so enlightened aren't you. The elite
@@matisowagm calm down
Same. After a decade, there is no new technology, just new marketing of old ideas
In my Opinion, this sounds like a bad change, if I'm wrong please correct me, but it promotes API-Second Approaches and Monolithic Architectures. Isn't that the stuff PHP is hated for, at least among Software Architects?
Wow. This is exciting stuff. I've been a bit skeptical about Next lately after my experience trying to deploy an app I built with Appgyver which builds into Next. It spit out working code that I simply couldn't understand, and it got me interested in how no-code platforms are built. I'm currently experimenting with generating Vue components on a Rust server based on user inputs as a sort of prototype, but that architectural comparison you laid out toward the end gave me some perspective as to why the Appgyver team may have gone with Next as their build target, though this was only recently achieved. It would be really cool to see some big improvements in the no-code landscape as a result of this newfound backend superpower.
No code is ass
which material ar you reading? I want to create a visual editor for orchestration of some services (something like camunda but simplier)
@@hck1bloodday What are you trying to build? Are you trying to create your workflows or front end?
@@andrerosenkilde yes, something like that.
I have worked with document signature, but I want to create a product where the client can establish the workflows for their documents.
For example, here every year the salaries are updated according to the inflation and the employees must sign an addendum to the contract to reflect the salary update.
I want the client to be able to define how the document is signed (someone have to approve? The order of signing matters or not?) And add other services which they can choose to use or not in their workflow (notifications, cloud storage, immutable storage, etc)
I wonder what this means for testing. Are there going to be lots of focus on mocking mechanisms? Writing tests for a component that fetches data directly like that prisma example is not going to be super simple. One might say you can just create your own mocks with jest or vitest, but what about component testing tools like Storybook, Cypress and Playwright ?
Server first react is great but it feels so weird calling data directly from prisma in a component. Is there a way to always know if a component is server or client? I’m scared to expose server side functions to the client and this doesn’t feel like there is a clear distinction anymore.
Where do you normally fetch data from currently?
Running on server by default sounds good in theory but if the processing is now mostly on the server, and you're working for a company that watches the pennies, how will this effect server CPU time costs? It's got to be so much more expensive to run?
Let’s say there’s an endpoint that takes 20 seconds to complete (some bigdata request that does a lot of work with a lot of data). How should React, well, react to that, according to this new approach? If there’s no loading stuff now.
As I understand it you just don't handle loading states in your components directly but rather as a suspense fallback.
There is still loading states as I understand.
Well your promise would be fulfilled once the endpoint request completed correct?
So now you just wrap your component with a suspense component and in that Suspense write whatever happens before the is fulfilled.
Your Suspense fallback is where you would write "Loading..." whatever.
It's definitely not fixed when it still has a virtual dom and the gzipped size is 40kb.
What's wrong with a virtual dom
@@rutabega306the virtual dom brings in a lot of overhead so for someone with slow internet they would have to wait a bit for the page to load. While there are definitely frameworks that reduce the overhead as much as possible such as preact. A framework that has a vdom also cant say they have true reactivity since the entire dom updates whenever a component rerenders while for instance solid-js only updates the component in the dom.
We've really come full circle haven't we 😅
Well almost
React making PHP great again
The comment
You say “no more loading states”, but isn’t the fallback component just your new loading state (I.e. that is what you’ll render while loading)?
yes I guess we just save some time by not managing it ourselves.
agreed, just dont have to write if for wait component loading and change the state
Well done mate! I appreciate your work!)
But to be completely honest it’s kind a marketing thing in transition between OldMethod and NewMethod. I mean with NewMethod you’ll have to make API call every time when a component renders. Otherwise you have to store the response in state like you did in OldMethod. Of course you can move this logic to prisma but you can do it with OldMethod as well.
So it’s not clear how we can avoid useEffect/useState.setState with this sync/await stuff
Just read the RFC, ona of the reason for use instead of await is cache (you will be able to override), so it will not call the API all the time. :)
@@BleedingDev Almost like the stale-while-revalidate cache invalidation strategy never existed. Imagine if Vercel had released a library called useSWR back in 2019 to solve this exact issue, life would have been so different... 🤦♂
@@charlesm.2604 Yes, I know about it and also about stale-while-revalidate. :) It is just really important to have it in React. :)
Wow this is great. The main issue with react is that it's easy to end up writing a lot of code to do a simple thing. Couple that with devs who haven't used react much and you get a massive spaghetti mess of useeffects. Hopefully this more clearly outlines the structure to follow and cleans it up a bit.
Spiral of frameworks keeps spinning!
Yeah, react is still a hard pass. I won't learn all this new stuff just to find out next year that this feature has a lot of problems and now we have to rewrite everything again
What do you use?
What lol? React is simple to get started in and this whilst it's a big change doesn't have to be used. It's just another option. If you don't like learning then enjoy being stuck in php land forever.
@@ChillAutos it's not about learning new stuff, it's about learning new stuff and then realizing it comes with a lot of problems and side effects. Maybe you're stuck in react land 😉
@@nreekm what problems and side effects? You still havrnt told us what You use.
Am i the only one who didnt understand the server component and use hook
react being server-first is utterly stupid. we select the language used for a given project by the requirements. if the requirements were, that the thing runs on the server, with server side rendering, we would have selected php.
Most companies I have worked for use react with no thought to the affordances of ssr. PHP is seen as antiquated and the talent pool is slowly drying up. Plus PhP has none of the client side affordences of React.
@@DrClocktopus1 that seems not like a proper assessment. most "big player" software on the web ist still written in php. version 8 with jit compiling eats javascript for breakfast, performance wise btw.
the "talent pool" argument comes up from time to time, but i never understood that anyway. we hire computer scientists, not persons that have a limited skill set in a particular language. i would expect every employee to master any language in less than week, if necessary.
@@miko007 not master, but be productive in a week for sure
@@miko007 agreed. Talent pool is bigger but most JS developers can barely code. PHP, Java or C# are much better.
I’m hyped!! This is great news, been using rtk query and I really like it but down to see what will be the native implementation.
This is why i don't like react, you need 5 functions and 3 libraries for anything
this right here is why i dont get the fanboying
"React is server 1st"
we fucked......
Isn´t it satisfying to see someone really exciting with some tech? =)
not really, when it doesnt really work for me
Haha yeah why it's wierd nd still not 😅
kinda cringe lol
no
tried implemeting a serchbar with relay (which doesn't have loading and error states) and it is bad, had to switch back to react-query because i don't need the suspense fallback covering the screen while the query runs
Relay is extremely powerful for those that know how to actually use it… if you want to build something small then don’t use it. If your building a powerhouse app it’s a solid choice
Gosh, i have been learning html,css,js, node for a few months, and wanted to learn react now. Should i even try to learn it from ”old” videos, or should i just wait until someone uploads a whole new tutorial on it with all of the updates included just to not confuse myself?
Seems like react just became a little more like Laravel. I've been learning the Laravel over the past couple years and thinking about learning react after a project I'm working on currently. Wondering if this would make the learning curve a little less steep
It won't replace Laravel, it won't replace your back-end (API, database communications, mailers, etc..). The only difference is that your front-end is now *really* generated on the server-side the same way PHP does it.
to be honest, we basically had this before with Next.js getServersideProps but now it's directly inside react and more universal.
I'm not sure, getServerSideProps just fetchs data on the server and you pass this data to your regular component, here it seems you can write server side code directly inside your components like in his NewMethod one
@@heroe1486 yeah, but the result / behaviour is the same, isn't it? it's not like using await inside the component will cause any client-side fetching.
UI that is literally married to business rules? What a terrible mistake. This is a cool two-liner for an example. But this will not scale to the needs of enterprise software. React is better when it's unopinionated. Because if you want to design your codebase into the ground (which I have seen everywhere), it was your choice. Now, we have guardrails to ensure that it is run into the ground.
I am a desktop developer and just started learning web dev, but havent reached react modules in my course yet. Should I find a new react course with this updated version ? Or learn the older version anyways? Asking because it seems web devs really seem to hate the old/current reactjs.
Thanks
I would just keep learning with react hooks and try to keep an eye on this stuff as it come in over time. The thing about web dev is that it is always rapidly evolving, and if you're always trying to learn the next thing in advance before just digging into what's relevant now, you'll never actually catch up.
@@normalmighty thanks 👍 you are right because I am learning to find a job and jobs might still needs hooks with their existing code.
@@Touseef some really older legacy code probably still have class based components too lol
how is this different than what remix is currently offering?
That's Remix only, but since this is React wide, any React framework can take advantage of it. In a way, creating Remix paved the way for this big React change, it looks like to me.
And Nuxt (when Nuxt 3 finally comes out), and SvelteKit, and SolidStart, and all the MPA frameworks. So this is big news for React/Next folks, but nothing groundbreaking for others--am I getting this right?
@@zzzyyyxxx i don't have a problem with react itself getting new features! but the way he talks about it makes it feels like a revolutionary thing however it's not and there are react based framework offered the same thing! anyways my question is more of a verifying my info than arguing
@@dannydevs yes but still with all these alternatives out there i still pick things which are based on react
@@ibrahimmohammed3484 "there are react based framework offered the same thing"
Where?? Show me.
I do see the appeal of using suspense to avoid loading spinner hell. But I don't understand the part about calling prisma in the component and react being 'server first'. Is that a new feature in Next or React?
Also would it be more dangerous since you're putting the call to your database very close to the user side without any real input validation? Since it's so compact idk where I would implement server side request validation
9:39 "How do you express the loading state." "There is no loading state to express. It blocks until the data is there." "The loading state is a side effect of bad architecture"
Okay... but if it's blocking until the data is there... doesn't that mean it's loading in some sense? And don't you want to express that the app is loading to the user? I wonder if the question was too simple for your level of expertise, and you misunderstood the simplicity of the question...
Here's what I think you mean, and correct me if I'm wrong: It sounds like what you're saying is that the server doesn't respond to the request until it has a fully rendered page or component for the client that will not require the client to make any more requests to load components, because the components were fully rendered server side, and that is opposed to what used to happen, which was the "bad architecture" of loading a component partially, sending that to the client, then the component sending a request for more data which is on the server, which should have just been sent all at once with the component in the first place, considering how long requests take to go over the internet, and so now you need loading spinners, and then every level of your component that loads is requiring a loading spinner, and that's what causes loading spinner hell, so... the new way is better, no more loading spinners. Right?
HOLY, i'm really excited, it's not anything new but now we have it inside React itself, no more need to look for other solutions.
So if you have an async component, it's rendered on the server. From the code you've shown, it doesn't seem like there is a way to have reactivity/state from inside this.
From the RFC, "A limitation of async Server Components is that they cannot access Hooks. We don't expect this to be an issue because Server Components are stateless and Hooks are rarely useful in that environment. However, you can use supported Hooks (for example, useId) inside Server Components that are written as regular functions."
So it possible to do more than just display a list of data with this method, and if so how?
Not really.
Using client components, they're kinda like astro islands, you should check out the server components rfc
@@Luka-he5mr I did read it. did you read my comment? I quoted directly from the rfc
So the revolutionary react thing is ... Remix?
Hey, if it’s good it should propagate to a primitive, right?
@@theklr oh 100%, it’s just that I’ve been getting a somewhat “anti-remix” vibe from Theo, who otherwise has takes I wholeheartedly agree with, and I’ve never really known why.
When he treated this as revolutionary, it made me wonder “then why don’t you ever talk about remix in your videos?”
@@kylar13 I’m guessing that maybe due to the talk and his connections within Next.
It's a little different, same problem but it's a more flexible strategy. Remix has the opinion that the data for your app should correspond with the routes that you have. I'm getting the sense with this strategy you'r data control is by component, not by route.
I'm not sure if that flexibility will actually result in people making better apps or not. I think remix kind of hit the nail on the head that data usually corresponds with routes. But I imagine there's sometimes where a solution to component level fetching will help remix-ers (Can we call ourselves DJs)
@@jon1867 I think that if for some reason you want data fetching at the component level, it probably does correspond to a route especially considering a Nested Routing setup
I see why folks don’t like JavaScript. I started with it and recently been doing work in go.
JavaScript community is such a mess. I’ll learn this but geez
Exactly. Most JavaScript developers are junior developers with a lot of "experience". Stick to real non-Javascript backend. It makes more sense, pays more and has a ton better tooling.
Go is awesome.
I'm curious on how this all will come to the React Native ecosystem, i feek like as react progresses, react native stays kinda stuck in time. I would love to see both technologies merging more in the future since i do a lot of work with it.
When are we gonna see the RN re-architecture?
It’s already there in 0.70.
Latest React native is using react 18. You have full access
9:39 Wait wait, does this make React based apps not SPAs anymore? As in the js bundle is no longer sent to the client?
Now the page load blocks untill all the suspended components are rendered to HTML and that is then delivered by the server?
Im quite confused, can someone help me understand?
It messed that it is optional now
Rails prescribes "Hotwire" for the frontend, don't know if it's a distraction to add that to the diagram.
We have come full circle haven't we?
We started with server side static HTML, it felt too bland so we invented stuff like jquery and dom manipulation libs, manual dom manipulation got too complex so we invented libraries like react, turns out doing everything on client side was a bad idea so now we need to go back to statically generated HTML again.
To those who recently began to program, this appears to be a brilliant ideas. I feel this is full bat shit -- the effort is awesome, but the collateral damage won't be accounted for.
Are we at that time of the year where hype zombies get excited with more broken trivial updates that only bring more problems, breaks legacy code, and only exist because their hype tool of choice is completely broken?
REACT UPDATE: It feels like building a paper boat and trying desperately to fix it with more propaganda paper.
JavaScript was always enough for 99% of cases.
We're at that time where people stuck in their ways, feel enough change to come out of their caves... And exclaim the same boring arguments against change, we've heard the past 6 decades.
@@neonraytracer8846 OMG that new hype corporation just announced a new way to do the same exact things but in a new hyped way that is much worse, bloated and inefficient than before, but makes them much more money. OMG Let's change our ways, spend our time and money to make sure they'll profit upon our indoctrination. OMG Hype Zombies for the win! Propaganda Oriented Programming is so much bettern't! 👍
Fortunately there is a salvation for all that invested so much in React from this paper boat - is SolidJs
The tense of this video seems incorrect.
It's talking about planned development...as if it's already done and merged...
What does this mean for apps that have a backend like java and the frontend in react?
Nothing other than UX improvements. The double load (first the component then hydration) jankiness can be mitigated
I feel like React was all a rouse to get front end devs in to backend all along.
at this rate, I just want solidJS to pick up steam and become popular.
webdevs will this finally make you acknowledge that most of the people in the world that access the internet use it in their phones and stop making jittery sites that scroll hijack but popping content in minutes after the site has loaded just at the right spot for you to click it by accident?
so if i started learning react should i stop ? and wait for the updates
So, the type safety thing -- isn't this exactly what GraphQL is for? That or you have an interceptor layer in between your API and your front end that spins up concrete models/contracts before they're consumed by the front end. Serious question, not asking to be a jerk.
It’s so much more work to set up a graphql server. Then once it’s created you have to manage it. This allows you to get the type devs directly from prisma.
@@coolr557 Prisma and tools like it can autogenerate a GraphQL API and separation of concerns is important for architecture that needs to scale.
Nice video.
IMHO I don’t quite understand it yet.
If we are now calling the DB directly on our React code, then what about all of our Json endpoints? Do we loose them?
We are essentially skipping the API creation part and instead running the DB queries directly on React.
Meaning we no longer have a Json server which may be usefully if we have, for example, native apps that need to get data from it.
Am I getting something wrong? Thx
Well yes and no. The reason this is happening now is because we have Edge computing of SSR. This is the only way this is viable at scale.
NextJS has a layouts RFC detailing how this is gonna work. You can decide if you wanna have a JSON backend or not.
If you’re using rest endpoints now (then I assume you’re using a fetch library for those).
It’s as simple as flipping a flag in SWR, urql or React Query, setting suspense: true. These hooks will switch to returning promises and make the request on the server to the server. No further implementation is needed. And you can keep your JSON server API for external apps :)
@@philheathslegalteam Oh, that makes sense. Thx
Huh? So no more writing APIs? Sounds too good to be true... What happens to the client then? How do I authenticate/authorize users and such?
HttpOnly cookies to auth and then just dont let them access stuff they're not meant to
Just going to go out on a limb to add the usual caveat: this is going to be a powerful tool that is good sometimes, and should not be used at all times.
If your SSR output is hinging on all network / DB calls from all components completing, and inside of a bunch of components, someone has made the cardinal sin of sequentializing many async calls that could be parallelized, just because they're allergic to Promise, or the services that are called do horrible things with the data, this will result in *terrible* load times for the end-user (whether the fetching is done as part of the SSR, or the fetching is done from the client determines if the page is all-white, or a skeleton).
A handful of oracles will become the "load-perf gurus" of the next generation, knowing where to parallelize, and knowing which layers to inject Suspense into, to make the rest of the app usable on a 5 second query to some ancient Java 7 system...
None of this is to say that it's a bad feature, or a bad path. It's a good tool that, in large production environments, will require more knowledge and nuance than it appears.
You do realize when a React component makes an API call client-side, the API is doing of all those DB calls ? If they're done server or client, it doesn't matter.
@@charlesm.2604 It matters a lot.
Let's forget about React, for a second.
Presume it's a Java server that makes a bunch of DB calls, and those calls take 5 seconds, before it spits out an HTML page.
What does the user see when they go to the site? A white page.
How long do they see it? 5 seconds.
Now, let's say we are in a case where we have hand-written the front-end HTML/CSS and there is enough JS to make calls to the server (and those calls still take 5 seconds). What does the user see when the page loads? Whatever HTML/CSS is already prepared, plus spinners for widgets, or a spinner for the page. For how long? ~5 seconds. Actually less, because in Java those requests were made in serial sequence, whereas in the front end, you could have the browser parallelize ~6 at a time, as long as you don't do something like `await` all of them, one after the other.
See the difference? The second one sucks. In the first one, the user doesn't even know if the request has gone through. And that sucks even more.
A really good experience for a web site (not an app, but a traditional site) would be to load whatever you can in the first ~300ms (the "front page"), serve that while caching the responses for the other data that was primed, that will be requested and loaded in from the client side. If you have content that virtually never changes, then spending 5 seconds rendering on the server is fine... if it's not a user that is requesting the page, but rather a build step that's going to take 40 minutes to build out your whole site and cache all of the pages on a CDN.
A good experience for an app would be that it loads in the shell, ideally with content, and the whole app is navigable and traversible and usable, while loading in data, which is cached on device.
How long your calls take and where they are made absolutely matters.
These tools are a good thing, but shouldn't be used directly by the average developer until great usage patterns and new quality-of-life tools are built on top, otherwise we will be going back to the days where JSPs took 3 seconds to load the HTML page and everyone was miserable.
@@SeanJMay I wasn't talking about user experience but about the performance aspect. Those DB calls still need to be made and wether they're made during server side rendering or upon an API request doesn't change the fact that they still happen.
As for caching, server side caching exist for a reason, and it's even more effective as the data will be cached for every request, no matter if the client already cached it or not (e.g: new visitors).
@@charlesm.2604 Of course it doesn't. But the *user* is the one who *uses* the site. With no *user*, there is no reason for the site.
If you give a *user* the shell of an experience and some spinners, it's a pain. If you give the *user* a blank screen for several seconds, on their first visit, you will never, ever see them again.
Ergo, where and when the calls occur in the process of serving the user absolutely matters.
@@SeanJMay That's not what I'm arguing about brother, care to read a reply ?
Correct me if I’m wrong, but I think server-side default rendering is still in beta.
I use serverless architecture and a cdn to serve the frontend. I'm almost not affected by this change. What do you think of that?
The best approach in (in terms of performance)
Yeah dude. IMO, serving the front-end from a CDN and having it run fully clientside was why I used React for my latest corporate projects. I don't see how these changes are getting so many people excited. Maybe I'm missing the point of it all?
@@weegee_ Just hype IMO.
Even tough, interacting with multiple origins from the client (in a complete “serverless” way) might degrade performance because of DNS resolution / TLS setup & etc.
Might be negligible.
@@IslamIsDanger the only problem I had with this approach so far is the added request time because of aws lambda function's cold starts, but other than that this approach is so far the most superior in my opinion, it's cheap, it's reliable, and it doesn't require a lot of monitoring. That's why I embraced full-on serverless coming from a serverful approach.
wait, it never supported async? Frontend devs are weird... I've been working with async for almost 5 years already
Did you hire a new editor? real W stuff here
Nope - mir's just getting that good that fast!
So does this make tRPC for typesafety now obsolete?
so getServerSideProps is same as this asyncronous Compnents now? if I understood correctly, if yes then what use has NextJS now if regular react can do same now?
and when we have a so server-side rendered component, can we perform data fetching in it in the client also? I'm thinking that you often want to initially populate with some data, but if the app is very reactive than it should perform other data fething and rerenders for components while the app is used
Aaaah, I see. We're missing those old days. So php9, support for client side ?
Is this live yet or no? If not, where do I keep track on when it’s live to use? (I’m new to react).
Also is this server side thing gonna improve SEO too I guess or?
as others have pointed out, we went from server side to client side, now going back to server side again??
Interesting, but is the suppression of the "separation of concerns" a good thing? curious to see the best practices emerging from these new design patterns. After all, we don't want to end up like the good old days of the internet with one single file containing all the code? I'm playing the guy who is meticulous but in reality, very excited about those changes.
It seems we are going to there.
Ok this is unrelated, what notes app is he using? This looks really cool/useful.
Didn't Vue got suspense in 3.0? And that was quite some time ago now. I mostly use Vue and always had this idea in my mind that React is the older but more advanced framework but the more I look the more I feel Vue surpassed React long ago. NuxtJS with it's asyncData is so far the best way of fetching data from server I've ever used.
react is not framework. Library is something that can do 1 or only several things, framework is whole package - react is only library.
It does state that it's a library, ok fair. This wasn't my point tho.
But if it's just a library.. shouldn't React be at least smaller size then? Because it's not. Vue manages to do more, arguably better, while being younger and smaller size - that was my point.
what is the name of the vscode theme?
Hi Theo, your vscode looks beautiful, can you tell me the theme pls? :o
going back to server side rendering :))
also the way i write apps in my vue js apps is, "you have a bigger page response, that contains all the data i have on the page (making the php API kerner on the backend initialize once) after that i only request granually" but this only works if you dont have infinite micro components in your main component calling stuff in parallel for no apperant reason
yes initial load tine is bigger but what people fail to notice is the end client doesnt care, most dont even see the difference between 1sec and 3 sec loading time
If 3 sec is nothing then why not load whole backend to browser, sending server to client.
After loading it's faster than edge. Next step after edge really.
You already have a free SQL database in browser 😂 you also have fast bun now.
One will say spread centralisation makes servers so close that browser seems obsolete.
Other one will say depending on central authority is the last thing we need to keep free internet & full variety of content.
And we have powerful browsers which still don't use full power (GPU).
Everything moves in cycles & waves.
*this method does not allow isomorphic retrieval and updating of data, it only receives them once on the server. Horror.*
Guys I am not familiar with react much, just getting started with it what exactly was the change that happened? A use case will be helpful!
Nice video! Could you make a new video explaining a little bit more about the current status of data fetching with Suspense? Also, could you show more details about how these changes affect the UX?
I was on board but this video opened my eyes and not in a way that you might expect. Who's to say we're not just going back and forth between SSR and CSR? Would love to have a crystal ball and see if this still holds up in the next five years.
9:13 soooo....... it won't work on client?
I don't know. We were rendering everything on server. Then we added JS. Then we started rendering on client. Now we're back on square one. But we're using js this time. Like... why?
Meanwhile Elixir Phoenix came with LiveView components rendered on the server side and pushed to the frontend even with disabled JavaScript
Separation of concerns is important, or? Seems like something that could be useful for Next.js maintainers and Apollo/Urql libraries to solve some SSR issues. I get that. If you're past a simple example project you probably have different APIs (in-house and third party), different teams maintaining them, authentication/authorization, API gateways, caching layers, business logic you don't want in your UI, etc. Are we going to call Stripe to ask them to let us connect to their SQL database now? 🐈⬛
What about partial removal of placeholder of spinners when the data is available?, because instead of one single spinner you have mini "spinners or place holders" in each part of the interface that must load?
I spent a year learning React moving from php, now react copying php
Me: o-o
you definitely got my sub. thank you so much for posting and explaining the practical effects of the changes! awesome channel!
Js developers rewrite frameworks because of dynamic typing. Dynamic typing languages make easier to rewrite anything from scratch than to support existing projects. If your employer gives you task to support project written in js or python - run. RUN as fast as you can.
Where does the t3 stack fit into all this?
I curious how react-native will make use of this server-first approach, or react-vr for the 7 people using it. these are React changes right? not React-DOM changes?
what is application that you use for notes? xD
I think angular ssr is still better designed. On server side, the framework waits for the state to be settled, then renders the app. With react, the components are run only once and then rendered, changing state isn't possible during server-side render. Why can't the react framework wait for state to be settled on the server, and then render the app? Why can't the state be changed before server-side render? Then, whether the component code runs on client or server, useEffect would work.
Are you referring to Angular Universal? Or Scully?
Well put!
You seem like a guy who could get rid of nestJS from an app after finding telefunc
Does that mean no more client routing and fast page loads. So we get back on page refresh again? Wtf
Hey React community folks, Im pretty new with React and Im not understanding what this all means. What concepts of React should I be studying to understand the importance of this new fix?
just wait till they release the new information and learn from zero
Which VS code theme are you using?
so basically we can have async components that react will 'await' automatically ? And till then a loading state will be visible. Now if there's a child that's async how do we await for it inside the parent comp ? I am excited for the answer, its so simple to have a mental model on the components execution now. Its 'suspended' until its 'ready' like any other (awaited) async function.
Regarding the example where you put `await prisma.example.findMany()` in the React component: how can that work on the client? For SSR purposes that looks cool, but what if I want to create a "refresh" button that will cause reloading the data and rerendering the component?
For someone who never worked with nextjs and only done react on the frontend, what does server component means? It’s not jamstack architecture anymore?