One thing you haven't addressed is if you want to to have a different backend language, like Go or C#. If you have different clients like mobile app, or watch making calls its better to have decoupled frontend and backend. Isn't bad practice for server to be in charge of both sending HTML and being an API to multiple clients? And TRPC isn't language agnostic.
nothing's stopping you from using a different backend language and rendering stuff the "traditional" way in react, these changes are new things you can use and NOT something that gets rid of old things. With RSCs, if you ever change your mind and want to start supporting a mobile app, then you can abstract bits out to functions and API routes and then decide if you want the website to continue using RSCs for data-dependent things or if you want to fetch from your own api afaik tRPC wasn't even mentioned in this video and it isn't a thing for RSCs (as of now). the name of it is "TypeScript Remote Procedure Call" so I don't know why you're bringing that up. btw, there are Rust crates that can act as a tRPC server and client, and the API methods are just HTTP requests at heart, so if you needed to you can treat it as language-agnostic, without the other benefits tRPC provides such as cmd/ctrl click to go to the source code of the server function
They can still be used. Now your API calls are going to be much faster since you are doing the fetching on the server. The page will load quickly because there won't be multiple round trips.
@@samuelgunter it’s just Theo tends to shill TRPC so much and comparing it to language agnostic API paradigms. GraphQL and REST. Not an apples to apples comparison because of that.
"The old ways are still best at Los Pollos Hermanos" - Breaking Bad. I just got from a video about Amazon Prime saving 90% after moving to monolith to this video. Tech always flips back to old ways.
Severless was dumb from the gecko. Most smart phones this day are more expensive than a laptop. Internet is getting faster and everything is getting faster, but instead of taking advantage of that compute power. We want to do everything like we did in 2005. There is a reason every company and language out there are investing in web assemblies.
my main problem with ssr with next (and most front end frameworks, they are all guilty of this) is that html rendering performance is horrible. Just try rendering a simple html structure in a compact html string (express res.send(`string`), for example) and do the same component in next, or fresh, or others. The difference is 15x or plus in my machine on requests per second.
"You have the ability to start from the server code that starts fetching from the database, instead of returning JSON, you return HTML..." This is assuming you can integrate React Render phase into your backend. But that only works for the Node backend. What do you think about the backend written in other languages? Also, what about the backend that needs to support iOS / Android?
Backward compatibility is huge. It's pretty much a given in not-javascript world. Glad to see the value is being recognized. I can compile and run C/C++ that was written before-I-was-born.
Being completely honest, all of what’s happening now around web dev feels like an absolute shitshow I used to be a PHP dev and enjoyed using Laravel. I’ve recently come back to development to create a couple of apps and wanted to learn new practices. Since then every week something revolutionary came along which completely changed how to develop apps - either new Next version, new library which would have saved me hours if it came along few days before, some feature going out of beta, new infrastructure service, new framework which would be better for my uses etc. And now after relearning dev patterns we’re going back to full-stack days again and reinventing features, just in JavaScript It doesn’t feel exciting. Honestly I’m really worried about maintainability of code in server actions and that my code will get instantly obsolete and unmaintainable after I write it. This video made me a bit less worried about at least the React front-end part
The only benefits I see to moving away from Laravel (Laravel dev of over 10 years here btw) and to something like Next for everything is the benefit of one language across it all. People claim better DX but I would say that’s not even true because you have to re-invent so many things yourself that you get out of the box with other well tested server side frameworks like Laravel, Rails etc. I have struggled with this topic for a few years and I even took a job working primarily in React just because I felt like I didn’t understand it enough simply because I don’t “get” why it’s so big. But my mind is made up, Laravel is still the best tool for building great products with small teams and I’ll continue to use it because it’s the only thing I truly enjoy using that lets me focus on the product and not the code.
Bridging the gap between server and client development also blur the lines between two very different fields that require not only different skills, but also different focus. I still believe a FE/BE split will be necessary, specially for large projects and teams. While it is not mutually exclusive with the new model, I do worry that the market will start pushing too much responsibility on react devs who are not ready or even willing to wear both hats at work.
Are you aware there are developers who do not work for a company and that they have to do everything including UX and SEO? No small or family-owned company will look for "frontend developers". They need a developer. They do not understand the differences. On another hand: if you're not willing to adapt and continuously learn........... yeah, I don't even have to finish this sentence.
@@MauricioAndrian yes, I’m aware. I’ve been a full stack dev for 17 years. I’ve worked in such small startups you speak of. But I have also worked in enterprise scale. I didn’t say full stack devs are useless. I said the FE/BE split is necessary. Not always. But often, specially at scale. You don’t do a FE/BE split because you lack full stack developers, or because someone is unwilling to learn. You do it to separate concerns and let people handle different parts of the stack with greater focus and expertise.
@@kasper_573 I am full stack too at my own still small business. My backend communicates with very different kind of software and I wouldn't want to have the web front end dictate how the rest is working. Also I personally would rather like to push Rust to the front end rather than Javascript to the backend.
Man it's been so awesome to see the quality of your videos improve this much! Even though I don't catch the streams, I thoroughly enjoy every video including this one! Great take!
im a big svelte fan but im also very excited about the future of react i feel like they can both coexist because while they both solve very similar problems, they do so in different ways which i think can be very beneficial depending on the type of app you are building! it is a blessing that we get to pick between so many different yet very good solutions
I'm still a little confused about the new model. At what point does client-side React come into play? if I ship a server only page, is it zero JS, or is React loaded on page load? I think of other frameworks that tend toward import-then-go models, and I'm wondering if _that_ is what's happening, or if server actions are solely to minimize client-side virtual DOM changes.
well I think the point is you get to decide what happens on the server and what happens on the client, you need content that needs to be seo friendly you build it on the server and serve html, you need to update something on the page without reloading the page you use the client
I asked the same question. I don't know. If you find out let me know. It's easy to do, create a server component without any states and send to frontend and see in the browser how much javascript is shipped with it. I suspect it ships the entire javascript bundle. Next' bundle size sucks monkey azz. 85 kByte of JS for an empty project...
Uhh Vue as well has a big community+ vite as well was made because vue existed, the tootling and Vue with laravel.... Both Vue and react interchangeably are great and for angular ( I just see Google so it's great as well )
85KByte is too much for a naked NextJS app... 10 Calls on a simple app are already 1MByte of traffic. This is why I am learning Solid Start, which ships I believe around 20kByte. I yet have to watch the video of you porting your app to solid, must find time for it. I haven't played with server components though yet. How much Javascript is shipped if I have server components ONLY (not states etc)? Is the whole thing still being send to the browser?
I just don't get why would we like to have bigger payload to rerender data, is it possible to send just compressed bits instead of whole html? Obv, there are bandwidth concerns, sending repeated tw classes will feel like wasting resources for me. Optimistic UI all the way, but sometimes there is an operation that can't be assumed, so it would make sense to use old model of just calling api and awaiting result. For that reason I feel like this would cause fragmentation in codebases and community.
I feel like most web frameworks are kind of converging in the same place. Similar stuff is going on with the Rust frameworks and PHP frameworks. I'm looking forward to seeing all of these evolve and hopefully become even greater.
I'm fairly new to React (about 6 months in) and I'm absolutely stunned how much I love it....but I was worried I might be too late to the game. This video really helped allay those concerns and worries entirely!
React's future is currently very unclear, in my opinion, and there seems to be a lack of unified vision within the community, there is a division between those who prefer server-side generation and those who prefer client-side rendering. The introduction of new concepts has made everything even more confusing, and understanding them requires thinking in a React-specific way that may not come naturally to everyone. It feels like you have to train your brain to think in the React way to make sense of it all.
Ya I'll learn it but not putting it in projects I care about .. I regret using react for a major one JS community is always bouncing around rationalizing it which is good sometimes but others it's like who wants to build a business on this
@@MauricioAndrian The only reason React is used is because its early adoption rate when it came out (~2023), at the time it offered a new and "better" way of doing things that led to many people using it, but recently React's game is slowing down compared to other frameworks who are constantly innovating, like Vue with Vapor Mode. Adam explains it better: th-cam.com/video/Zt8mO_Aqzw8/w-d-xo.html
As promising as Svelte, Solid, and especially Qwik looks my company isn’t leaving React anytime soon. Why? Two words: UI libraries. To make me consider a new framework for my company’s web app I’d have to see solid Tailwind support and a good high quality stable headless/unstyled ui library.
1. Tailwind is framework agnostic. 2. Qwik team has made an adapter for React. This means that you can use React component libraries like Material UI in a Qwik project.
I'm glad react is continually trying to improve itself but the virtual Dom and rendering problem is a deal breaker for me. I definitely prefer some of the newer frameworks like Solid
Could you please briefly describe what exactly is the problem with virtual dom and rendering in React? I certainly have seen a lot of benchmarks where React is behind frameworks like Solid and etc, but does it actually matter that much in production? From my personal experience, most of the issues with slow websites usually come from poor image optimization, JS animations and other similar stuff which are not issues related to the framework at all. Will be glad to hear more on this
@@bthero03the virtual Dom is unnecessary and manipulating the Dom directly is more efficient and costs less in terms of memory as well. As for the rerendering issue, anyone who has worked with react will tell you their issues. Everyone has them and this video by Jack Harrington displays it well th-cam.com/users/shortssQKTv4ulj_0?feature=share . Finally, I don't have professional experience with anything but React but shipping less JavaScript is always a good choice when trying to get the user to interact with the page ASAP and Reacts clientside JavaScript file is quite large when compared to other more modern frameworks
@@bryson2662 the React team have been talking about this problem, and why that's not the problem when sites feels slow. The network server-client waterfalls, that's the priority and that is something that neither Solid or Qwik (both amazing frameworks btw) addresses (you have some primities for doing $server or $loader, but is not the same level of power and introduce some problems to use it wrong (client-server waterfalls)). Also SC arquitcture reduce some JS by doing some in the server, not the level that you want but is something. But yeah, new frameworks like Solidjs or Qwik are amazing, and soon they'll have SC arquitcture too, so is matter of time.
No you can't take old cold and run it now. And you know why? Because to build anything functional you need a lot of other libraries or a separate framework like NextJS because React isn't a framework it's VDom UI library.
I saw some people on Twitter talk crap about server components (actions particularly) because you would need to rewrite endpoints for your phone apps etc, not compatible... would be curious to see your take on this
If you learn your programming chops and abstract that logic out and just reference it within the component / api routes then this problem is mitigated. Essentially the API route or action just becomes something that passes the request details to your business logic. Not that I code in JS / TS regularly, I still believe PHP / Laravel is the most effective solution for small teams building products.
Next has its own node server which generates code on the "server". Your django backend is another server. The next server can call your django server for data, then build html and send it to the browser. I'm not 100% sure about this, but I'm like 99% am :D So you end up having 2 servers.
I gotta say, it definately beats the IE5 vbscript + jscript + active X objects in IE5 compatability mode I still have to support sometimes. That code was written before i was born
Good points here. At this point people should understand the API changes for react RSC. There's none. Your app will continue working. The only disruptive workflow is for the library authors who will now have to add "use client" and export every client component as a file. There will obviously be some footguns with the new pattern but im quite happy that its not as bad as an infinite loop like with hooks.
Great video. One point though, is that I don't feel like react is leading the way on this one. At least not like they have paved the way in the past. I feel other technologies and frameworks have been leading the way. When React initially launched hooks, although somewhat similar to other frameworks, was leading the way. I know react has had react server components planned forever, and it was on their roadmap many years ago, but at this point I feel like they are a bit late to the party. I do agree though that them embracing it really does shift the entire ecosystem.
Regardless of whether or not you use React / Next, I think it's worth learning. The ecosystem, innovation, and best practices change, and I think it's a good insight into how that compares with your framework of choice. I use Qwik, and by playing around with current ideas in the React space it's helped me reason about my applications in a way I never would've thought possible. It's also made me realize how similar Qwik and React Server Components are similar in some ways, and also the tradeoffs that both have made.
I love React, but my biggest problem is it's learning curve. The one way binding, changing the state of an array, depending on your task can become a pain sometimes... But it works so good with Typescript and other tools, it is really good that React is still being taken care and being a better framework day by day 🎉
Except we're not. Php and Rails were server rendering. Then came client rendering with Angular and React. These new frameworks mix server and client rendering.
Probably a dumb question because I haven’t actually looked too closely into how RSC actually works, but from a development perspective, what is different about writing server components vs a regular next app with getServerSideProps?
How many times should I tell you kits?, THERE IS NO SILVER BULLET, there are a lot of cases where next is not the ideal tool, some times is better to use client side render
Theo, this is a great video that addresses what a lot of us devs have been wondering about. Will Next take over Solid and Svelte? Are server actions colocated with the client code a good idea? What problem does server components solve? You explained these concerns very well. Thank you for your valuable input.
Really wish the backward compatibility would get credit to Ember. The react ecosystem creators give (and have) a lot of ex Ember devs CRA was originally inspired by Ember’s cli. React router was referenced from Ember router. It’s long overdue we really understand where this SPA history comes from and how we can understand how we got here and where we’re going
Great vid! Thanks! One of my main worries with the new model is that it is to complex and to much magic. But you saying that it’s straightforward and great to work with really alleviates that! Looking forward to digging into this as well!
The huge promotion of SSR is happening to increase cloud costs. CSR is so much faster with many more capabilities it aint even funny. I like that SSR is there just in case you need it but making it the default direction and main focus is stupid or a ploy to increase the bills, there is really no other explanation.
People are saying that its php again and we are stupid. I'm sure thay dont understand neither php or react.But what they dont understand is its not a circle but a spiral that goes up due to increased DX as you said in a previous video.
One of the features that made me start using React is its freedom. And I am most afraid that at some point for the average developer react == next, one of the more restrictive metaframeworks
Yeah, because you have millons of frameworks in Svelte, Solid, Qwik, even in Vue. React have the most number of frameworks by far. There's nothing that the React team is doing for Nextjs specific.
@@oscarljimenez5717 i mean: SolidStart and Nuxt are flexable. Both use external libraries under the hood (e.g. routing). Next has its own solutions with its own API. You should do thinks Next-way
@@untlsn what? Nextjs have a fetch library called SWC (you have to install it), i never use it, i use React Query Instead. Nextjs have the API routes, i use tRPC instead. I don't know what your talking about. Nextjs don't try to make you do the thinks in a Nextjs way at all. You clearly are using Nextjs the wrong way. Every nextjs package is optional, the framework core is very clean, probably the cleanest of all, you have to install a lot of things to make it complete and DX friendly.
@@untlsn and also, how is that SolidStart and Nuxt use external libraries under the hood for routing? What? Every framework own his routing because routing is the base of the framework.
@@oscarljimenez5717 I mean SolidStart and Nuxt are more of a bundle of external packages. Most of their functions, e.g. routing or meta tags, come from external packages that I can use in a clean project. In theory, you can build a metaframework yourself from the same building blocks. Next, on the other hand, is practically standalone, even its tooling is unique, because instead of using Vite like most metaframeworks (I'm not saying it's good), it (will) uses tools like SWC or TurboPack For example, in Solid Start, I can use the built-in files based routing, or build my own based on @solid/router. Both will work. In Next, creating subpages without using pages or app directory is not very pleasant It's not my intention to attack Next, because I use it myself and find it really nice, especially for typical large sites. I'm just afraid that at some point Next-way will be the only "right way" and the niche in which I work will be neglected
For most devs does this stuff even matter - why isn't it just pick something and get your project done Lot of this stuff blinds you from what's going on so if something breaks ... better hope your learned the mechanics behind all his magic
As a back end dev that used to hate front end, im increasingly excited by the way the industry is moving and your videos make it less intimidating to get into it, thank you ❤
It is a good thing that the web develops. But we also need security in investements into code. A customer of mine invested USD 4 Mio into an application in angular 1.x. The customer didn’t want to throw away everything. The developers didn’t want to invest time into an obsolete framework. So the developers ran away. A financial desaster. How can we get some safety into the investments. We need customers that are willing to invest into modern web apps.
I wish angular 1.x would not have died but develop in an compatible way. And angular 2 should have been named angoola or any other different name to show that they are different frameworks. Using the same name many customers understood that angular 1.x is dead and JS frameworks are dangerous to invest in. C# and Java look old but don’t have that risks.
No. I care about my cloud bills. Also RPC is fundamentally flawed, and running javascript and react on the backend is a signal that the entire architecture needs to be rethought instead of doubling down on react. I will keep going with the RAD stack (Rust + Axum + Dioxus), which offers both as-fast-as-solid SPA & Liveview modes on the web, is fast enough as a backend that it outperforms nginx for serving static HTML, and runs on more platforms than Javascript for native apps since you have the option of compiling to self-contained-binaries. Also, imho liveview is a better paradigm than SPAs for the majority of interactive websites.
@@invinciblemode That's a really great question. Besides the obvious speed advantage of WASM over JS, Dioxus also does subtree memoization, memory allocation reuse, and some really smart compile-time optimizations.
@@vaisakh_km in my experience most react components are a paper thin wrapper around some existing js library. there's some exceptions but that's been my experience.
i build enteprise web apps proffesionaly and i know that whatever crazy feature i will be asked to implement there will be community and libraries to back me up. In svelte this is not the case so i am afraid to use it proffesionally even if i like it
Legendary point on the backwards compatibility! I am grateful to the Vue and Nuxt teams for the delays during the Vue rewrite to v3. I used to be a die hard Vue fan but when I found myself stuck with Vue 2 and looking at what I'd need to do to upgrade to Vue3, I started looking elsewhere. I had seen react before but jsx really put me off. But I finally gave it a try. Let me just say, I don't even know what version other frameworks and libs are on.
Saw the old comments of people crying about vendor-locking... Kinda disappointed that people who watch Theo think all of Vercel's doing is to get more money...
(at a roulette table)
Dealer: Red, Black, or Green?
Theo: React
Dealer: What?
Theo: React.
Dealer : I said Red, Black, or Green?
Theo : Next
Dealer : Next what?
Theo : Just Next
Dealer : are you deaf? I said Red, Black, or Green????
Theo : Typescript
Dealer : Typescript what?
Theo : Typescript.
Primeagen: Typescript deez nuts
Roulette: "It's React."
Dealer: "WHAT"
Theo: "I'd like to make another bet
"Dealer":
@Dany Camirand it's for a church honey!
Lol for a few post this thread was funny
"Angular 2 made TypeScript the norm." - Theo
It's very very true. They and nativescript were the ones who initially pushed the adoption
Actually this real.
Angular 2 was the place where I first encountered TS.
@@rajatsx Agunlar 1 for me
It's actually true as hell. React community was very late in adopting (& getting familiar with) TypeScript
sveltekit has done a great job of data loading and its easy to see what code will render on the sever via server js file
Agreed
svelte developer experience is unparalleled
One thing you haven't addressed is if you want to to have a different backend language, like Go or C#. If you have different clients like mobile app, or watch making calls its better to have decoupled frontend and backend. Isn't bad practice for server to be in charge of both sending HTML and being an API to multiple clients?
And TRPC isn't language agnostic.
nothing's stopping you from using a different backend language and rendering stuff the "traditional" way in react, these changes are new things you can use and NOT something that gets rid of old things.
With RSCs, if you ever change your mind and want to start supporting a mobile app, then you can abstract bits out to functions and API routes and then decide if you want the website to continue using RSCs for data-dependent things or if you want to fetch from your own api
afaik tRPC wasn't even mentioned in this video and it isn't a thing for RSCs (as of now). the name of it is "TypeScript Remote Procedure Call" so I don't know why you're bringing that up. btw, there are Rust crates that can act as a tRPC server and client, and the API methods are just HTTP requests at heart, so if you needed to you can treat it as language-agnostic, without the other benefits tRPC provides such as cmd/ctrl click to go to the source code of the server function
They can still be used. Now your API calls are going to be much faster since you are doing the fetching on the server. The page will load quickly because there won't be multiple round trips.
@@StingSting844 why are API calls faster when called form server rather than client?
@@samuelgunter it’s just Theo tends to shill TRPC so much and comparing it to language agnostic API paradigms. GraphQL and REST. Not an apples to apples comparison because of that.
@@mr.random8447 Distance.
"The old ways are still best at Los Pollos Hermanos" - Breaking Bad. I just got from a video about Amazon Prime saving 90% after moving to monolith to this video. Tech always flips back to old ways.
Severless was dumb from the gecko. Most smart phones this day are more expensive than a laptop. Internet is getting faster and everything is getting faster, but instead of taking advantage of that compute power. We want to do everything like we did in 2005.
There is a reason every company and language out there are investing in web assemblies.
my main problem with ssr with next (and most front end frameworks, they are all guilty of this) is that html rendering performance is horrible. Just try rendering a simple html structure in a compact html string (express res.send(`string`), for example) and do the same component in next, or fresh, or others.
The difference is 15x or plus in my machine on requests per second.
Yes but:
You can pre-generate static pages (SSG)
If you don't render on the server, the client will
can you please provide resources to dive deeper into this? TIA
this is an interesting point, do you maybe know how would this compare to PHP for rendering html?
"You have the ability to start from the server code that starts fetching from the database, instead of returning JSON, you return HTML..." This is assuming you can integrate React Render phase into your backend. But that only works for the Node backend. What do you think about the backend written in other languages? Also, what about the backend that needs to support iOS / Android?
Maybe use node just as a rendering backend service and in which call apis from the real data/processing service, using REST or gRPC?
Backward compatibility is huge. It's pretty much a given in not-javascript world. Glad to see the value is being recognized. I can compile and run C/C++ that was written before-I-was-born.
Being completely honest, all of what’s happening now around web dev feels like an absolute shitshow
I used to be a PHP dev and enjoyed using Laravel. I’ve recently come back to development to create a couple of apps and wanted to learn new practices. Since then every week something revolutionary came along which completely changed how to develop apps - either new Next version, new library which would have saved me hours if it came along few days before, some feature going out of beta, new infrastructure service, new framework which would be better for my uses etc.
And now after relearning dev patterns we’re going back to full-stack days again and reinventing features, just in JavaScript
It doesn’t feel exciting. Honestly I’m really worried about maintainability of code in server actions and that my code will get instantly obsolete and unmaintainable after I write it. This video made me a bit less worried about at least the React front-end part
Welcome to modern fullstack development...
the reason for this pace of change is because right now there's a lot of money in webdev, wait until money dries up a bit and things will consolidate
Yea lol, server code and client code in the same place is what we were doing 10 years back with PHP. I feel u bro lol
The only benefits I see to moving away from Laravel (Laravel dev of over 10 years here btw) and to something like Next for everything is the benefit of one language across it all. People claim better DX but I would say that’s not even true because you have to re-invent so many things yourself that you get out of the box with other well tested server side frameworks like Laravel, Rails etc. I have struggled with this topic for a few years and I even took a job working primarily in React just because I felt like I didn’t understand it enough simply because I don’t “get” why it’s so big. But my mind is made up, Laravel is still the best tool for building great products with small teams and I’ll continue to use it because it’s the only thing I truly enjoy using that lets me focus on the product and not the code.
Bridging the gap between server and client development also blur the lines between two very different fields that require not only different skills, but also different focus. I still believe a FE/BE split will be necessary, specially for large projects and teams. While it is not mutually exclusive with the new model, I do worry that the market will start pushing too much responsibility on react devs who are not ready or even willing to wear both hats at work.
this has been the case for years. "oh it's just java(type)script"
Are you aware there are developers who do not work for a company and that they have to do everything including UX and SEO? No small or family-owned company will look for "frontend developers". They need a developer. They do not understand the differences.
On another hand: if you're not willing to adapt and continuously learn........... yeah, I don't even have to finish this sentence.
@@MauricioAndrian yes, I’m aware. I’ve been a full stack dev for 17 years. I’ve worked in such small startups you speak of. But I have also worked in enterprise scale. I didn’t say full stack devs are useless. I said the FE/BE split is necessary. Not always. But often, specially at scale. You don’t do a FE/BE split because you lack full stack developers, or because someone is unwilling to learn. You do it to separate concerns and let people handle different parts of the stack with greater focus and expertise.
@@kasper_573 I am full stack too at my own still small business. My backend communicates with very different kind of software and I wouldn't want to have the web front end dictate how the rest is working. Also I personally would rather like to push Rust to the front end rather than Javascript to the backend.
tbh i don't like server components, they couple the server to the client too much and you can't really create alternative front ends for your app
isn't this what sveltekit has been doing with how you can choose granularly the rendering paradigm ?
Man it's been so awesome to see the quality of your videos improve this much! Even though I don't catch the streams, I thoroughly enjoy every video including this one! Great take!
im a big svelte fan but im also very excited about the future of react
i feel like they can both coexist because while they both solve very similar problems, they do so in different ways which i think can be very beneficial depending on the type of app you are building!
it is a blessing that we get to pick between so many different yet very good solutions
wild nasso in the wild
@@Affax wild affax in the wild
I'm still a little confused about the new model. At what point does client-side React come into play? if I ship a server only page, is it zero JS, or is React loaded on page load? I think of other frameworks that tend toward import-then-go models, and I'm wondering if _that_ is what's happening, or if server actions are solely to minimize client-side virtual DOM changes.
You can literally test it yourself in browser tools and inspect requests and responses.
@@vanskunia crazy 🤯I had no idea. Only if I had someone who already knew the answers...
well I think the point is you get to decide what happens on the server and what happens on the client, you need content that needs to be seo friendly you build it on the server and serve html, you need to update something on the page without reloading the page you use the client
I asked the same question. I don't know. If you find out let me know. It's easy to do, create a server component without any states and send to frontend and see in the browser how much javascript is shipped with it. I suspect it ships the entire javascript bundle. Next' bundle size sucks monkey azz. 85 kByte of JS for an empty project...
@@SandraWantsCoke in dev environment?
Uhh Vue as well has a big community+ vite as well was made because vue existed, the tootling and Vue with laravel.... Both Vue and react interchangeably are great and for angular ( I just see Google so it's great as well )
85KByte is too much for a naked NextJS app... 10 Calls on a simple app are already 1MByte of traffic. This is why I am learning Solid Start, which ships I believe around 20kByte. I yet have to watch the video of you porting your app to solid, must find time for it.
I haven't played with server components though yet. How much Javascript is shipped if I have server components ONLY (not states etc)? Is the whole thing still being send to the browser?
I just don't get why would we like to have bigger payload to rerender data, is it possible to send just compressed bits instead of whole html?
Obv, there are bandwidth concerns, sending repeated tw classes will feel like wasting resources for me.
Optimistic UI all the way, but sometimes there is an operation that can't be assumed, so it would make sense to use old model of just calling api and awaiting result.
For that reason I feel like this would cause fragmentation in codebases and community.
I feel like most web frameworks are kind of converging in the same place. Similar stuff is going on with the Rust frameworks and PHP frameworks. I'm looking forward to seeing all of these evolve and hopefully become even greater.
Same reason tons of programming languages look the same fundamentally. Good ideas are good and will be implemented into everything else.
I'm fairly new to React (about 6 months in) and I'm absolutely stunned how much I love it....but I was worried I might be too late to the game. This video really helped allay those concerns and worries entirely!
😂 pls ) it never too late for anything ) COBOL still in use, Ruby On Rails still in use )) do whatever you like )
Is figuring out how to write php aka react server components is challenging the norms???
React's future is currently very unclear, in my opinion, and there seems to be a lack of unified vision within the community, there is a division between those who prefer server-side generation and those who prefer client-side rendering.
The introduction of new concepts has made everything even more confusing, and understanding them requires thinking in a React-specific way that may not come naturally to everyone.
It feels like you have to train your brain to think in the React way to make sense of it all.
Ya I'll learn it but not putting it in projects I care about .. I regret using react for a major one
JS community is always bouncing around rationalizing it which is good sometimes but others it's like who wants to build a business on this
"React's future is currently very unclear"
I wonder how much time a framework need to have its future considered "clear". 20 years? 30?
@@MauricioAndrian The only reason React is used is because its early adoption rate when it came out (~2023), at the time it offered a new and "better" way of doing things that led to many people using it, but recently React's game is slowing down compared to other frameworks who are constantly innovating, like Vue with Vapor Mode. Adam explains it better: th-cam.com/video/Zt8mO_Aqzw8/w-d-xo.html
As promising as Svelte, Solid, and especially Qwik looks my company isn’t leaving React anytime soon. Why? Two words: UI libraries. To make me consider a new framework for my company’s web app I’d have to see solid Tailwind support and a good high quality stable headless/unstyled ui library.
1. Tailwind is framework agnostic.
2. Qwik team has made an adapter for React. This means that you can use React component libraries like Material UI in a Qwik project.
@@aiciz9 huh… definitely got some prototyping to do in the next year then. Thank you!
I'm glad react is continually trying to improve itself but the virtual Dom and rendering problem is a deal breaker for me. I definitely prefer some of the newer frameworks like Solid
Which framework do you use them?
@@sidaz22 he literally mentioned solid
Could you please briefly describe what exactly is the problem with virtual dom and rendering in React? I certainly have seen a lot of benchmarks where React is behind frameworks like Solid and etc, but does it actually matter that much in production? From my personal experience, most of the issues with slow websites usually come from poor image optimization, JS animations and other similar stuff which are not issues related to the framework at all. Will be glad to hear more on this
@@bthero03the virtual Dom is unnecessary and manipulating the Dom directly is more efficient and costs less in terms of memory as well. As for the rerendering issue, anyone who has worked with react will tell you their issues. Everyone has them and this video by Jack Harrington displays it well th-cam.com/users/shortssQKTv4ulj_0?feature=share
. Finally, I don't have professional experience with anything but React but shipping less JavaScript is always a good choice when trying to get the user to interact with the page ASAP and Reacts clientside JavaScript file is quite large when compared to other more modern frameworks
@@bryson2662 the React team have been talking about this problem, and why that's not the problem when sites feels slow. The network server-client waterfalls, that's the priority and that is something that neither Solid or Qwik (both amazing frameworks btw) addresses (you have some primities for doing $server or $loader, but is not the same level of power and introduce some problems to use it wrong (client-server waterfalls)). Also SC arquitcture reduce some JS by doing some in the server, not the level that you want but is something. But yeah, new frameworks like Solidjs or Qwik are amazing, and soon they'll have SC arquitcture too, so is matter of time.
No you can't take old cold and run it now. And you know why? Because to build anything functional you need a lot of other libraries or a separate framework like NextJS because React isn't a framework it's VDom UI library.
I just can't get to grips with React. It always feels heavy and clunky to use. I started working with Vue and things just clicked much more quickly.
I really enjoyed this video. 👏 Theo
I saw some people on Twitter talk crap about server components (actions particularly) because you would need to rewrite endpoints for your phone apps etc, not compatible... would be curious to see your take on this
If you learn your programming chops and abstract that logic out and just reference it within the component / api routes then this problem is mitigated. Essentially the API route or action just becomes something that passes the request details to your business logic. Not that I code in JS / TS regularly, I still believe PHP / Laravel is the most effective solution for small teams building products.
So I’m going to be learning Django and expect to use it as a backend. Does this new feature in React work in the same way with a non-node backend?
Next has its own node server which generates code on the "server". Your django backend is another server. The next server can call your django server for data, then build html and send it to the browser. I'm not 100% sure about this, but I'm like 99% am :D So you end up having 2 servers.
I gotta say, it definately beats the IE5 vbscript + jscript + active X objects in IE5 compatability mode I still have to support sometimes.
That code was written before i was born
Please google "How to remove mouth noise from audio" 🙏 🙏 🙏
Good points here. At this point people should understand the API changes for react RSC. There's none. Your app will continue working.
The only disruptive workflow is for the library authors who will now have to add "use client" and export every client component as a file. There will obviously be some footguns with the new pattern but im quite happy that its not as bad as an infinite loop like with hooks.
Facebook definitely needed this feature, so as always, react devs need it automatically. PHP? Really?
Great video. One point though, is that I don't feel like react is leading the way on this one. At least not like they have paved the way in the past. I feel other technologies and frameworks have been leading the way. When React initially launched hooks, although somewhat similar to other frameworks, was leading the way. I know react has had react server components planned forever, and it was on their roadmap many years ago, but at this point I feel like they are a bit late to the party. I do agree though that them embracing it really does shift the entire ecosystem.
Do you see the T3 stack adopting this soon?
Regardless of whether or not you use React / Next, I think it's worth learning.
The ecosystem, innovation, and best practices change, and I think it's a good insight into how that compares with your framework of choice.
I use Qwik, and by playing around with current ideas in the React space it's helped me reason about my applications in a way I never would've thought possible.
It's also made me realize how similar Qwik and React Server Components are similar in some ways, and also the tradeoffs that both have made.
Really enjoyed this Theo. Thanks for sharing!
I love React, but my biggest problem is it's learning curve. The one way binding, changing the state of an array, depending on your task can become a pain sometimes...
But it works so good with Typescript and other tools, it is really good that React is still being taken care and being a better framework day by day 🎉
On the thing about changing arrays... Have you tried using "immer" ?
I my opinion SvelteKit approach is much more understandable. But I get your point
I'm curious to see where this is going, but I find it a bit funny that after all these years we're back at the Laravel/Django/Ruby on Rails "model" :P
Except we're not. Php and Rails were server rendering. Then came client rendering with Angular and React. These new frameworks mix server and client rendering.
Probably a dumb question because I haven’t actually looked too closely into how RSC actually works, but from a development perspective, what is different about writing server components vs a regular next app with getServerSideProps?
on one hand, its exciting and new technology, on the other, its the fear of change... spot on. keen to see where we end up in a few years time
We're just hostages of React,
you can accept the fact
but you should not defend it.
What do you think of qwik and their architectural decisions?
how will affect create-t3-app ?
How many times should I tell you kits?, THERE IS NO SILVER BULLET, there are a lot of cases where next is not the ideal tool, some times is better to use client side render
Theo, this is a great video that addresses what a lot of us devs have been wondering about. Will Next take over Solid and Svelte? Are server actions colocated with the client code a good idea? What problem does server components solve? You explained these concerns very well. Thank you for your valuable input.
but when will Next get signals?
I refreshed ten times in the beginning thinking my resolution was broken
Hi Theo, thank you for your take. A completely different view is here: th-cam.com/video/Zt8mO_Aqzw8/w-d-xo.html. What's your take on this?
How do you think of Qwik?
What do you think of vuejs?
Where can I find that Next shirt?
First rule of fanboy world: We dont talk about Qwik.
Really wish the backward compatibility would get credit to Ember. The react ecosystem creators give (and have) a lot of ex Ember devs CRA was originally inspired by Ember’s cli. React router was referenced from Ember router. It’s long overdue we really understand where this SPA history comes from and how we can understand how we got here and where we’re going
Great vid! Thanks! One of my main worries with the new model is that it is to complex and to much magic. But you saying that it’s straightforward and great to work with really alleviates that! Looking forward to digging into this as well!
what about vue?
Vuejs will be big soon as well
What does the future of the T3 stack look like?
Trpc is not dead yet, they're doing some experiment
It is becoming obsolete.
informative good video, great optimistic view with a bright future
I read this book a decade ago lol
time passes by so fast.
I still don't get why React Server Components isn't just worse Astro 👀
this. astro has less marketing money i guess
Lets gooo React. I am very excite!!
(Borat voice)
Nice t-shrit btw, where i can get it?
The huge promotion of SSR is happening to increase cloud costs. CSR is so much faster with many more capabilities it aint even funny. I like that SSR is there just in case you need it but making it the default direction and main focus is stupid or a ploy to increase the bills, there is really no other explanation.
can you make t3 app use app router?
People are saying that its php again and we are stupid. I'm sure thay dont understand neither php or react.But what they dont understand is its not a circle but a spiral that goes up due to increased DX as you said in a previous video.
One of the features that made me start using React is its freedom.
And I am most afraid that at some point for the average developer react == next, one of the more restrictive metaframeworks
Yeah, because you have millons of frameworks in Svelte, Solid, Qwik, even in Vue. React have the most number of frameworks by far. There's nothing that the React team is doing for Nextjs specific.
@@oscarljimenez5717 i mean:
SolidStart and Nuxt are flexable. Both use external libraries under the hood (e.g. routing). Next has its own solutions with its own API. You should do thinks Next-way
@@untlsn what? Nextjs have a fetch library called SWC (you have to install it), i never use it, i use React Query Instead. Nextjs have the API routes, i use tRPC instead. I don't know what your talking about. Nextjs don't try to make you do the thinks in a Nextjs way at all. You clearly are using Nextjs the wrong way. Every nextjs package is optional, the framework core is very clean, probably the cleanest of all, you have to install a lot of things to make it complete and DX friendly.
@@untlsn and also, how is that SolidStart and Nuxt use external libraries under the hood for routing? What? Every framework own his routing because routing is the base of the framework.
@@oscarljimenez5717
I mean SolidStart and Nuxt are more of a bundle of external packages. Most of their functions, e.g. routing or meta tags, come from external packages that I can use in a clean project. In theory, you can build a metaframework yourself from the same building blocks. Next, on the other hand, is practically standalone, even its tooling is unique, because instead of using Vite like most metaframeworks (I'm not saying it's good), it (will) uses tools like SWC or TurboPack
For example, in Solid Start, I can use the built-in files based routing, or build my own based on @solid/router. Both will work. In Next, creating subpages without using pages or app directory is not very pleasant
It's not my intention to attack Next, because I use it myself and find it really nice, especially for typical large sites. I'm just afraid that at some point Next-way will be the only "right way" and the niche in which I work will be neglected
For most devs does this stuff even matter - why isn't it just pick something and get your project done
Lot of this stuff blinds you from what's going on so if something breaks ... better hope your learned the mechanics behind all his magic
Also impressive: Ink (React-based CLI)
As a back end dev that used to hate front end, im increasingly excited by the way the industry is moving and your videos make it less intimidating to get into it, thank you ❤
ikr~
i am intimidated by backend.
Actually, If you see the git history, Most react core Devs had left when all the inconsistency with hooks were introduced.
Am really so happy that I chose react over vue 4 years back, am now in good company, a toss for react!
And I am happy I chose Vue. V3 with Nuxt 3 are amazing and I'm not looking back.
It is a good thing that the web develops. But we also need security in investements into code. A customer of mine invested USD 4 Mio into an application in angular 1.x. The customer didn’t want to throw away everything. The developers didn’t want to invest time into an obsolete framework. So the developers ran away. A financial desaster.
How can we get some safety into the investments. We need customers that are willing to invest into modern web apps.
I wish angular 1.x would not have died but develop in an compatible way. And angular 2 should have been named angoola or any other different name to show that they are different frameworks. Using the same name many customers understood that angular 1.x is dead and JS frameworks are dangerous to invest in. C# and Java look old but don’t have that risks.
So basically you are thrying to say that React is Java?
still want to move away from react/next
I think you did a topic like this proud(with all that twitter discourse). Great job, Theo.
The future of the web is exciting. React and Svelte for the winnnn
I need more Theo vids! So much is happening and changing!
No. I care about my cloud bills. Also RPC is fundamentally flawed, and running javascript and react on the backend is a signal that the entire architecture needs to be rethought instead of doubling down on react.
I will keep going with the RAD stack (Rust + Axum + Dioxus), which offers both as-fast-as-solid SPA & Liveview modes on the web, is fast enough as a backend that it outperforms nginx for serving static HTML, and runs on more platforms than Javascript for native apps since you have the option of compiling to self-contained-binaries.
Also, imho liveview is a better paradigm than SPAs for the majority of interactive websites.
How is dioxus faster than solid when it still follows the react model which uses a virtual DOM?
@@invinciblemode the virtual DOM is not the reason of why React is slow on rendering, you need to ear more Ryan Carniato 😂
How do you fix client-server waterfalls in a SPA?
@@invinciblemode That's a really great question. Besides the obvious speed advantage of WASM over JS, Dioxus also does subtree memoization, memory allocation reuse, and some really smart compile-time optimizations.
@@oscarljimenez5717 use something like graphql?
I'm glad React is there because the rivals can learn from each other.However, I do not see any reason to use it over SvelteKit😅
I see a lot of reason, atleast for now
There are a lot of properly implimented production ready components there in react, but not for svelte
@@vaisakh_km Can you elaborate more? What are you missing?
@@vaisakh_km in my experience most react components are a paper thin wrapper around some existing js library. there's some exceptions but that's been my experience.
i build enteprise web apps proffesionaly and i know that whatever crazy feature i will be asked to implement there will be community and libraries to back me up. In svelte this is not the case so i am afraid to use it proffesionally even if i like it
I am betting on qwik.
nextjs is looking better, when facebook falls react will be gonezo
React involution to PHP, Evan You must be laughing his ass off.
just lost $10k because i thought you meant reaction channels
omfg
2012 PHP and JQuery or raw JS 'just works'. Why does 'just works' matter? Web is fucked beyond repair.
Web is going to get automated anyway.
Great insights!
Legendary point on the backwards compatibility!
I am grateful to the Vue and Nuxt teams for the delays during the Vue rewrite to v3. I used to be a die hard Vue fan but when I found myself stuck with Vue 2 and looking at what I'd need to do to upgrade to Vue3, I started looking elsewhere.
I had seen react before but jsx really put me off. But I finally gave it a try.
Let me just say, I don't even know what version other frameworks and libs are on.
You deserve my like after all am already a subscriber.
Great talk!
VueJs ftw 🙃🙃
Vue! is the future.
laravel livewire.
Are people scared of react ?
So basically we go back to how PHP was and why everyone hated it.
RGB js frameworks
Always bet on vue
no more tRPC
So after all the running around and years of development we ended up going back to php?
Figures 😂
Saw the old comments of people crying about vendor-locking...
Kinda disappointed that people who watch Theo think all of Vercel's doing is to get more money...