Did the NextJS App Router kill the Developer Experience (DX) that we know and love from React? Or did they make it better? Let's compare the App and Pages Router doing identical tasks. We cover data loading, suspenses and server actions.
Code: arc.net/l/quote/sjhqislc
👉 Upcoming NextJS course: pronextjs.dev
👉 Don't forget to subscribe to this channel for more updates: bit.ly/2E7drfJ
👉 Discord server signup: / discord
👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF
00:00 Introductions
00:30 Hitting Backend APIs Is Crazy Easy
02:26 Streaming Responses is Trivial
05:45 Calling The Server Is Just A Function
#reactjs #nextjs14
One thing I've been tackling with nextjs is if you hit the point where you realise, shit we probably needed an SPA because we need some offline features now, making that work in next whilst not throwing away the rest of your app is complex. That said server components don't make this problem worse, the state of service workers and PWA APIs in nextjs sucks
Really hope 15 makes PWA a first-class citizen of App Router.
@@theklryou know they make money when you render on the server right?
@@o_glethorpe I have three containers running Next 13+ and while I do have qualms with how they’ve isolated the work with RSC by being first and fast, vercel has not forced you to buy in. They do the same as all the other for profit companies, make experience better under their system and they’ve finally address that updating their self-hosting docs recently. They have been taking their (well deserved) licks in being eager in implementation, but the remorse is a symptom of the developer hype trap, not vercel pushing an agenda. Page router still gets (and is heavily reminded to us from their faces) and will get support for the long foreseeable future. Shame on us for using bleeding edge and complaining about getting cut
@@o_glethorpe yup, following their track since Next 10 I know they focus on monetizing. but I'm happy they still continues
Even the example with the searchable comments already looks complicated and unclear. Now, you must also remember what is running on the server, what is on the client, what is cached, etc.
Caching, Server, Client... Isn't that a more "complete" mental model to get used to?
Great video Jack! I always love how you break things down.
Great video man! I was working on a next 14 app and this video really helped!
Thanks for adding so much clarity on RSCs. I definitely want to use NextJS for work, I am just still in the transition phase of learning it. For now we have opted to use client side React purely because of so many resources online for my team mates to use as reference.
The way of explaining things with practical examples is very intuitive and easy to grasp. Thanks for the awesome lessons.
Another great video of a great programmer who knows what he is doing and has a great way of teaching
It has gotten worse for me. It's less about the router and more about the overall quality. Apps take longer to compile in dev mode. Next server seems to take 1GB+ memory for no reason! Next has definitely gotten worse. Go back to v12 and see how fast it is
I think that's a fair take but isn't related to RSC but NextJS dev server, I don't really have problems with it, but that's DX depends on the developer
If you mixed use of both page and app router in single application that will cost more
true
Okay, now communicate with an external API, that can have multiple consumers, and make sure to handle cookies and authentication state, then handle caching and cache revalidation, then handle optimistic updates, and then handle everything properly throwing errors, being handled nicely by the error boundaries and not found handlers.
how will the pages router make it easier
Yeah exactly. This example is quit trivial and doesn't really represent a real world scenario I would say, but it does highlight the differences. Also keep in mind that handling all that you mentioned inside Pages Routes was painful as well.
@@nathnaelwondisha6649 It won't if you want server side data fetching
So, if the requirements are more complex building an app will be more complex? Who could have thought that?
How would you do it in another environment and why couldn't you do it in Node?
So informative in such a simple way.
The amount of damage control that Vercel is doing is actually hilarious. No engineer, worth their salt, would ever use app router in its current state in a mission critical app where their job/role depends on it. That, in itself, says all you need to know. That being said, App router seems to be perfectly engineered for todo apps and also for generating top-tier twitter content. I still love you Jack Herrington
I've been away from creating nextjs apps for a while because of my SA work nature. Got back to it a few days ago because I wanted to rework my blog site. Saw all the promotion of app router from NextJS but when I looked at almost all the templates provided by official doc, they were all using page router...
We use app router in production for a fairly large project. Version 14 makes that website much easier to maintain than any of the other attacks we also maintain. We also remade another website with a lot of images using the app router and the speed increase in noticeable. Refusing to use the quality of life improvement provided by next 14 is your choice I guess.
I maintain several sites that include remix, next page router and next 14. And whenever I get the chance I port my projects to next app router just because of how easy it makes my life. The app router is made for devs to make faster better sites faster.
Imagine using this instead of proper backend in prod.
I'm convinced 99% of the framework users are making shopping carts, or resume apps. Real applications need real back ends. React got too into the hobby community, and started to spite the professional community.
@@chrisdaman4179 Same, im like reading the comments and all of these issues are "waaah i dont have a backend". Then make one for gods sake. You can write backend in JS and TS.
@@aexalven it's funny. My issue is that I have a defined backend already, and the new direction react is taking pigeon holes it AWAY from being backend agnostic. The "I don't have a backend" crowd are clearly just in it for the front end, but full stack is a thing.
@@chrisdaman4179I don’t see what backend features you won’t be able to implement with nextjs api routes but can with express. Can you please explain?
@@deshawnman3790 I don't use express... My server isn't even in JS. And if you can't come up with things a REAL backend language can do that next js can't, then you lack imagination.
I started writing react via next.js as it shipped version 13 so a lot of existing documentation made little sense to me, I have extensive experience with other server-side languages/frameworks and App Router wasn't that complex to learn compared maybe to someone that is used to work 100% client side. However most of my personal projects are on hold because next.js is really bugged; can't really go into the details of this in a yt comment but just look at the bug tracker. I was pleasantly surprised with Astro but it gave me the impression that is was more blog-oriented although it has server side stuff now and I'm a bit scared building big things atop of it.
yeah next 13 14 are a mess, especially memory management, there is plenty memory leaks
Amount of changes how stuff is done inbetween next js versions are crazy. To the point of 50% of stackoverflow beild old, deprecated stuff.
React RSC + Next.js default caching behavior - Client side JS = Astro. Or Next.js App dir = Astro +React Island But Astro is better because I it differentiate what runs on server and whats runs on client. I will not use next.js for backend because putting server logic in a component sounds wild. Imagine if next.js compilation have some bug and it leaked that function to client.
God the amount of bugs I've seen in the next 13/14 versions is unbelievable, it's been in beta for years and stable for one year yet it still seems like they rushed the app dir out. It's not even the bugs that bother me, but the lack of the simplest things not yet implemented. The things that currently bothers me the most is that I CANNOT disable client cache, why cannot I disable client cache? This makes no sense, just show forever stale data. The second is the styles being bugged, once you visit a page, a css style file is never removed from the dom, so when you go from page A -> B -> A, the styles of page B are still applied and will break your A styles if you use a component which has a default class and a new class from page A. I made a bug report for this with also reproducible steps and they completely ignored it
@@specy_ I mean they rushed app dir. RSC are in react's canary branch and they are saying its stable in Next.js.
1. It's difficult to migrate if it's a big codebase. Especially if it's a client project as they don't give time. Pages and App Router can exist simultaneously but that results in hard reload if we go from one to another. 2. Streaming is beneficial in SSR format only. SSG experience is the same in both pages and app routers because page is generated at the build time.
Good takes.
Yes, I can confirm that it is very difficult to migrate a codebase with over 500 files entirely to the app router. I finally managed it, on my own, after staring in November. But IMO I like my code so much more now, and I feel like I can adapt to user needs much faster and more elegantly. The 75% reduction in first-load JS also really helps the SEO performance metric. In my case, achieving this required a ground-up rewrite of lots of things, and code-splitting everywhere too.
You can't have both if you work on internationalized app. As long as you have i18n config in next.config.js you are stuck with pages router.
@@tradfluteman how about billing though? since you're now using a lot of server component will it increase the bill? if yes how much of an increase!?
@@tradfluteman I wish I could do that but not in my control in client projects especially when they extremely big global client service 10k customers per hour on average daily. And more features keep coming. I wish we had no hard reload between routers then it would be truly an incremental update.
Do you see in a near feature, some libraries instead of installing dependencies from npm install, it runs a command line that install the dependencie on the packages folder (like ShadCN), so you can own the code (mainly RSC provided by Resend, Stripe...)?
I think ShadCN is an interesting pattern for UI components that require a lot of customization. So sure, companies like Stripe or Clerk might take the ShadCN approach BUT I think they would be wise to have a thin ShadCN style layer that sits on top of a robust library for the logic. The same way that ShadCN sits on top of Radix.
Thank you! I see so many negative comments about RSC and server actions on Reddit and Twitter.
That was very interesting! Thank you. As for your last point regarding packages, where can we learn more on this topic as I would like to manage this well. Thank you for your videos. Cheers.
Can you give me a time reference in the video?
I truly agree. From the get-go I've found app router, lets just say, simpler than pages. But, seriously, my only concern at this point is to wait a year and see if the app router becomes the new pages router. And I would never refactor any project that uses pages to app router. My feeling is that this "framework" is suitable to specific setups and it is being sold as a fit-all
"Hot Take" Herrington in the house. Honestly, I think it's hilarious devs get so up-in-arms about stuff like this. To use the phrase du jour, there are much more important hills worth dying on than your preferred way to do routing.
Amazing video, nice explanations! I have a doubt, what if I want to make a web application with Next.js, but also I want to make a flutter app, can I use the next.js 14 app router as a backend for my app, it is recommended or it is a bad idea? What about using next.js and express.js?
As you point out, I would use Nest.js if I was going to just build an API. There is no advantage to using a Next.js app router app just to serve API endpoints.
@@jherr The next.js app would be also the frontend of the web version, but I want to use the app router as a backend for the web and mobile app, it is worth it?
@@luismario2 Oh, ok. If what your saying is that you want to build a NextJS application for the web, that also includes API endpoints that will be used both by the NextJS app and also by a mobile app, sure, that's fine.
I think the devs complaining are the ones who are no longer willing to learn anything new and just wants to do the same thing as what they did in page router. We started a new project and learnt how to do it in App Router. We made a lot of mistakes along the way but we now understand better how app router is fundamentally different. And it's been a lot of fun figuring it out because it makes things so much easier to do, and the RSC becomes such a cool concept to you once you get your head around it.
When your next js course will be available, Jack?) I'm waiting for it so much!😊
Hi Jack. I've been following your tuts and all. Given that we are in 2024 and for someone with tangible knowledge on most FE framework, what would you suggest for a simple dynamic app that talks to a database via an API layer. Nextjs, Astro or Remix. While I can simply create bunjs or nodejs, express endpoints, and consume via vuejs or svelte, I am looking for a more straightforward approach.
"simple dynamic app that talks to a database via api" - you just described like 99% of the apps nowadays, genius. New next (with server components etc.) seems like the most "straightforward" approach to me, in a sense that it takes the least development time and works the best if you actually use it properly. Whether it is big scale or a simple side project, I think it would be a good fit generally. But for a middle scale project or more specific requirements (like lots of client reactivity, weird use cases), probably better to use something else instead. For example, currently I work on a project that handles a lot of client-side *outside of the framework* reactivity and the react's rendering system is just not well suited for that, at all. If you want(need) to use native dom apis, or anything that is not directly connected to the ui, then it is a whoooooole lot of pain. If your goal is to build web apps that don't do anything out of the ordinary(so basically if you want something like youtube, twitter, dashboard, blog -like functionality), then maybe it is the best choice though.
Awesome video! Thanks for this.
It sounds like the main challenge arises when attempting to migrate a large codebase containing hundreds of page-level and UI components. Despite claims that incremental migration is feasible (which, in my opinion, is not entirely accurate), encountering obstacles is inevitable. Even when attempting to update to versions 13 or 14, the system will continue to prompt the use of 'use client'. Consequently, the migration process can be quite laborious in these scenarios. I hope I will find something easy to tackle this lmk if anyone has any suggestions, thanks for the awesome video 🔥 PS: its hard to explain the exact problem in the comments 😄
I tried Astro, and it has become my go-to base lib. I can still use React components, but if I have a subpage where I want to use something else, I can drop it into an island. Global storage (they recommend nanostore) is like Jotai. It is easy to use, atom-based. I bet signals would work too. I can make part of my app like a SPA, but others SSG/SSR with little to no JS to the browser. I also believe that SSR should only be used if necessary. I start with SSG, which is way cheaper/faster to deploy on a CDN. Most sites update so infrequently that you can totally SSG with a good CI/CD connected to a CMS or a dabtase change trigger. Sure, updates take a few min, but again - save $$$$ at scale and crazy fast.
For me, it's the thought that Vercel will happily make more breaking changes to NextJs at any point, as much as they can, I get the impression that they have stopped caring about their users. I've pivoted to other frameworks for new projects.
Hey Jack! Thank you a ton for addressing this, especially by comparing the two models side-by-side. This was an extremely insightful video for that alone, regardless of the hot topic. I've been using the Next.js pages router for quite some time and was initially reluctant to use the new app router. Additionally, seeing the content around RSCs and Next.js "becoming PHP" didn't help. This video has finally made me realize that this new model, backed by the simplicity and improved developer experience, is worth pursuing in future projects. Superb video as always!
Thanks. Really glad I could give you a nudge to have another look.
Thank you 🙏
@jherr I'm curious as to why you did not make use of the "loading.tsx" file that the app router supports as opposed to wrapping in the Comments in a suspense. But still an informative video as per usual. thank you
If you want a more fine grained control over the loading state to child components, suspense is your best bet.
Could have done that as well. I do appreciate the fine control of the suspenses.
@@prabinshrestha7754 what is "fine grained control"?
Whole page reloads when I just changed some tailwind classes. With me then having to rescroll to the y coordinates in the page for what I was editing is indeed a significantly inferior experience. Sure I can collocate more code.. That is nice. But let's not pretend it's a slam dunk.
Great video like always!!!
I'd likely just use React Query with the pages router tbh; very easy to show a loading state on server render if needed, but the streaming part of the app router is pretty cool, especially as it handles SEO scenarios.
Correct me if I'm wrong - while I agree that the app router is definitely better than the pages router, as a whole I still feel that Next.js is not as good as Remix, and this is even with Remix not having implemented RSCs. Disclaimer, I've used Remix for some projects and I'm currently trying out the app router so I don't know everything about the app router just yet. And of course, there's other people who will keep saying that Astro/Svelte/Alpine etc is better than react 😅
In what ways is it "definitely better"?
Data fetching only works in server component and all their parents has to be server component. The client & sever composition they claim is very limited, as you can't import a server component into a client component. Css-in-js styling only works in client component. Can't get cache re-validation to work. The router doesn't have events. I could go on. My project requirements are never this simple. But they have some cool features like route interceptor, nested layout and grouping.
Client components can contain server components, either as children or as component instance props. Client components cannot _invoke_ RSCs.
@@jherrBut you're prop drilling your component instance instead of data.
@@user-sd1zn7dl8w Ok, sure, but your point was that the parent of a server component had to be a server component, and that's not the case.
@@jherr If the component is rendered above the client component and passed in, the client component is not the parent of the component, it's just rendering data passed to it, no? It's not like the client component can pass any props to the server component to alter how it behaves.
@@coreyward True point about the client component not being able to invoke an RSC. That being said, I think your wrong about the parentage point. If you have a nesting like this in a PageRSC component the parent chain of the ClientContextConsumer definitely contains the ClientContextProvider and it works just fine. Even though all of the components were created in the PageRSC function invocation.
App router you actually only need a loading.tsx file and it acts as the suspense fallback component. I usually use a skeleton in my loading.tsx for example. Has to be in the same directory as the page.tsx.
I can tell you some example where page router wins: Handling refresh tokens. Have you tryed that in app router?
Also, RSC components look very clean until you need to handle some errors in some custom way lol 😂
I really tried to figure out how to authenticate requests to an external api from both the nextjs server and the client rendered components (using a HttpOnly cookie) for a very long time. It seems incredibly inconvenient. Went the "traditional" SPA route instead.
when we use the React suspense with the App router, should we use the loading.tsx page as well? Looks like it is unnecessary.
Both to mostly the same, I prefer Suspense
@@neociber24 Suspense sucks, because on a slow 3g the user will not receive any feedback whether the data is even loading in the background or not for 3-4 secs. Suspense has to hit the server, while the loading.tsx is always instant, even on a slow 3g.
It’s a preference, you can if you wanted too 🎉
I feel like solidjs was a reaction or an iteration on React's API surface area, the hooks. Solid-start isn't out of beta but I feel like React+ is making its own disruption demand. Maybe React will be a mid job-king like Java. "It's fine" but the innovation will be elsewhere? Then this "use client" bare string thing, I don't know, maybe it was rushed in because of Remix or others? It's weird! A bare string? We can't do metadata (hey this needs to run on the server) some other way like Svelte or Solid? It's these little microcuts, they start adding up and I personally start looking around. But the issue is, $job is React. Maybe it becomes mid like Java. I understand legacy problems when the install base is large and innovator's dilemma and of course time will tell. When I say I understand, I mean from a distance, which is to say, not deeply in it like core devs. So yeah, it's difficult. I think lifecycle API in class components made the most sense. I have to explain history to confused interns and juniors. Explaining class component API is easier than hooks in my experience. So, that's not a great story to tell.
The bare string thingy is just terrible. For me, this is a sign that the people that created this had no clue what they should do and were rushed by NextJs to release RSCs…
I'm starting to see that there were more Devs who appreciated the class style and old life cycles before Hooks came along. I was absolutely thrilled when it all changed up and thought many were, as well.
@@boredbytrash They iterated on this for quite a while actually and it wasn't rushed. It's not a Next.js thing, but a React thing so it wasn't definitely done because of Remix as the main comment suggested. Before it was supposed to be ".client.js" and ".server.js", so the filename would signify if it's a client or server component. There are RFCs you can read and see their thought process and see the reasoning behind all this. I seriously don't understand why people are upsed about "use client" directive. That's the least complicated part in all of this lol
@@incarnateTheGreat those people must be looking with very very rose tinted glasses. It's arguable whether it's easier to explain componentDidMount than to explain useEffect, but the over DX is wayyyyy better these days. Not having projects chock full of complicated higher order components, not having to deal with class instances, not having to deal with separating class based and functional components etc are all pains that I'm very very glad are far behind us. The average react code base nowadays is probably orders of magnitude more clean and concise than it was during the class component days. Go look at an angular project to see why 300 line long class components with who knows how many methods and lifecycle methods aren't a great DX.
@@buzz1ebee agreed. I was always in it for a functional experience, not sugary classes that seem abstract from JavaScript. Also, useEffect was a nice touch when it was first released, but with the direction of SSR and RSC, there are fewer instances that require it. Maybe that's something else that we need to be happy about. I never liked class components. I worked on a legacy project where some components were written in classes. I spent time modernizing them into functions and they gave me more programmatic freedom and ability.
As soon as you start even thinking about moving any part of your Frontend framework into the backend as a server side component… you are smack bang into optimising a local minimum It should instead be a strong signal to take a step back and reconsider your whole architecture Like .. is adding even more react the correct solution here ?
IDK, in my experience most of the time I'm working on an internal app or one where most of the app is behind authentication and there is a separate API (usually python) I'm interacting with. Adding a new server to the infrastructure really isn't an option. Since RSC is seems React is going in a direction that really isn't useful unless you're buying into the whole infrastructure which shouldn't be the goal of a library. React is feeling more and more like a NextJS dependency instead of it's own thing.
Yeah. Having different server and building around it with next.js seem super hard problem. Check out my comment I have had similar problem.
Do you have to wrap your server action calls in a useTransition when you are calling them from a client component? I feel like I saw that somewhere…
Have to? No.
@@jherr okay 👌 thanks
I used to hate app router. Turns out, app router is crazy good. Just that the DX is different, AND it totally removes the crazy boilerplate we had to do before for next.js. I am not into politics, so I don't have an opinion on who maintains it. :p
The only thing I found confusing about the latest Next is all the overlapping layers of caching going on: router cache, request cache, optional cache function for non http requests, etc. It made it difficult for me to figure out what was being cached where.
I am sure plenty will disagree but the app router really fixed a lot of my issues with fullstack JS app development. I went deep in JavaScript PL in 2010-12 but really grew to hate the tangled messes of conventions, workflows, frameworks and libraries that followed. Now I enjoy the lack of complexity creep in full JS projects and this is due to mature frameworks like Next, and how much React has improved over the years. The last year almost all of my personal projects have been Node based, whereas before that, they would be only paid projects.
"get out of your comfort zone and start reading" next 14 app router is an epic improvement, for those whining. Thank you Jack once again!
Nextjs died with 13 for me.
@@twitchizleyou are tweaking. NextJS 13 has solved almost every issue we have had with the web development world and you think it died for you? App router is a great addition to think about the way we build our websites. it’s extremely simple and easy to build websites with it. I don’t believe it can get any simpler than this. 😂
@@twitchizlePlenty of folks to keep it alive and thriving though. 😉
“Epic improvement” *nobody likes it* Seems legit That thing is slow and buggy as fuaaark
@@danvilela I'm loving it, and yes, there are plenty of folks that are starting to understand the shift in mindset and how to leverage server-client combo. Summarily, not a fair statement just bashing it from you side.
Next.js 14 is good, server action makes things easier for me, no complain, I build my app fast with Next.js and Vercel, with my server websocket in AWS EC2, everything works fine and smooth, great collaboration, smooth frontend and backend communication
I have about 30 modals in my project and many of them depend of each other. You have to have address to create legal antity etc. Javascript is everywhere in the app. Try to do optimistic updates for table of content which should update from response from 3 places in different requests. Why everybody who's telling about server components showing simplest apps. Do something really difficult
I don't get your point, those are just requeriments, RSC just allow you to access server data and stream the results which is easier to prop drill the data. I don't see what RSC have to do with complex requeriments.
@@neociber24 i need client components everywhere. But i didn't use callbacks with use server directive. Probably it's a good way to handle query params changes
This video is specifically about NextJS which isn't the whole of React. The reason people dislike vercel and next is that they are almost directing all users of React to adopt Server side rendering. Would prefer the react team to fix its rendering engine and make it more performant similar to SolidJS or Preact signals where the control over re-rendering like the old react prior to hooks was excellent.
The app router is miles ahead and better than the pages router. Eg. you can get pretty far making progressive enhancement so the UI actually works without javascript enabled. I have however, struggled with some bugs mainly related to parallel routes. Ifound some workarounds, but it will be nice when they get sorted out. It doesn't change my opinion though: The app router is really awesome!
Tbh, both aproaches look like workarounds on top of workarounds on top of workarounds. The router one is just insanely horrendous, I remember trying nextjs a few years back on a fairly complex project and it was not fun. Theres simply no good pattern for using it and keeping to SOLID principles (eg. the first example from the video). The app router isn't realy much better. It allows for more flexibility, yes, but all of it just feels like something I would've created in a situation where I need to make something cool and complex and have no time to think about the best way to do it because of deadlines, so I just make a solid abstraction into a leaky one (in this case its react) and just jumble it all together in a week. Which is not good and the next step would've been to go back and make a more logical choise and remove the leakiness, but in this case it is too late to do so, 2 teams from different companies agreed on it and there is no way to go back any time soon. Maybe its just me, but all those react server components, which can't be used anywhere except meta frameworks (only nextjs right now) just seem realy dumb. At this point, why not make react itself a framework with ssr capabilities and router?
did an angular dev write this
So how does auth work. Like jwt tokens in this scenario? How does this hybrid server/client make handling auth easier?
All the existing auth mechanisms that I have looked at have always given a server-only option to get the current session since that is needed by getServerSideProps in the Pages router. So just use that directly in your RSC in the App Router.
I don't like this trend of moving out of separation of concerns. I would love to see more tutorials about MVC in the Next.js framework. Yes, this is totally fine for some smaller projects or something that you do not care so much about performance, etc. But it's a total nightmare for new teammates, refactoring, optimization, scaling. Mixing UI with the model is just a bad idea and engeneers know that for years. But now we are repeating the same mistakes that we had in PHP 15 years ago. Sad.
What about Remix or Rakkas instead of pages router?
"It's Bonkers"
Nextjs is ideal for these youtube tutorial type videos I actually feel like that's who it's made for. For anything more complex and not designed by engineers it just becomes a mess and over complicates things that have been possible for many years. Both the pages and the app router. The app router may make certain things cleaner until you want to have rsc and client side reactivity and then you either sift through hundreds of pages of documentation or just use client everywhere. Actually it's more about the fact that there's such a significant change to the way you write nestjs that it just isn't worth investing time into. Some people are doing this as a career and don't always have time to relearn how vercel thinks we should write react. We just want to master our trade. Appreciate the video, just my two cents.
Can you do video on error handling and loading states? Like what if res.json() fails or api returns 4**? You can reply the answer here also.
Regarding the first example, what if you need inside index other components/js code/dom elements to know if comments has been loaded before doing something, or to access a value of comments? you have to create a useState inside index send the setState to the component which most likely will populate a state with the comments data there too and also send the setState back to the index, at that point isn't better to fetch inside index and send the props to the component? more often than not I find myself having most of the logic happening inside the index and then sending props to the various components, especially in a spa
If you fetch from the same URL in two different components during the same render only one fetch will be run and the other will use the cached result form the first. In SPAs you can just use context. You can use context in NextJS too, but you can only provide or consume context in client components.
Good video, but there is one problem with the server component wrapped in Suspense - it has to hit the server to render the skeleton, so it it far away from being instant in production, it makes app clunky.
All of these flows; Pages and App, are hitting the server. The difference between Pages and App in the suspense case is that the Pages router is completely blocked until the request finishes in GSSP (or you do a complex workaround like I did here). Versus the App router example where the SSR first returns the page with the skeleton right away, and then the server holds the connection open until the promise finishes, then the new content is streamed in to replace the skeleton.
Me watching this while still developing using Nest.js and CRA :D :D :D
if you are going to go as far as using nextjs, you may as well use a performant language like go, with htmx and tailwind. Lol
HTMX with Pug templates, is a dream. If you're treating React as a simple renderer, there are more straightforward solutions.
Pretty good content I must say 🎉
I have just one doubt. Let's say I have a page that contains a few server components and a few client components. If I only have a single API to fetch all the data that needs to be rendered on a page. Won't I have to drill all the props down to the components that are rendering them? This might be a wrong API design but still. Also if a component is rending some data and on the client side that same component needs to use a state value(let's say a zustand state that's been updated by socket) how would this be possible in nextjs 13/14. Wouldn't i have to check props as well as state to select a value? Can't we make a single source of truth, like fetching data in server components and somehow update the store on client side while consuming data only from store?
Answer to the first question is easy. Fetch is cached so just fetch wherever you need it and it will reuse any shared responses. Second question seems like one of those endless what if questions, answer the first and it just leads to more and more endless; "ok, but what about..." questions. Once you get to the client NextJS 13/14 is the same as anything else. Use webhooks, have mutable state on the client, do whatever you like. There are some additions to the toolset, like NextJS's SPA navigation support, but no deletions. So if there is an elegant way to do it in a SPA, then do it that way.
@@jherr got it. Thanks
Is it okay if i use react-router-dom in nextjs instead of using builtin nextjs routing
No.
Why not: - Everything is client side rendered (large chuncks can be split up through lazy loading) - Server and Client are aware of the same router / loaders, so server can stream in required data after initial html is send No added complexity or new paradigms, simple and efficient. I'm still not convinced about the hype around RSC / Nextjs SSR. Maybe I should build some more complex Nextjs apps and see how it works out in practise, maybe I'm just getting old...
I think the fact I skipped pages router and learnt next after app router was released now I find next to be really nice to use, but if a massive change turns it all sideways and I need to relearn everything again then ima stay away. I understand in this industry we have to continuously learn but I really don’t wanna be learning a new framework every time an update releases.
I'm all for RSC, and I believe it's a first good step to build apps that are performant and SEO friendly, though I understand why people don't like the new Next.js approach for data fetching. React was always about the client side, it's in its nature, all the patterns that got introduced to React application, specifically data fetching were linked to the client. These patterns held themselves strong throughout the years, now Next.js wants to change this because it's just wrong to rely on the client for everything. The new approach is Server First, as it always should have been. In my opinion, the data state belongs to the server, not the client, maybe it's good to offload work off the server to the client now and then. Correct me if I'm wrong
We have SSR since the beginning of internet. Next provides no new value. It just fixes problems created by react itself. But brings another set of new problems. If you want ssr just use proper tools. Next isn't it.
@@MateuszSorpropWrobelDid you watch the video? It just scratches the surface of the new value from Next. 🤦
@@codefinity I watched and still no new value, but new problems. It's easy to talk about those simple examples when other people need to build very large applications with lot's of loads. I talk with friends who work day to day with NextJS and from their perspective it's also a pain. It's not production ready. Do you want to go out from vercel? Still there are some problems. Not great developer experience. Even worse for business.
I really want to see you next video about Nextjs and coming module federation
That's a tough one because App Router doesn't support Module Federation, and in fact Next is coming out with their own "RSC Federation". Should be interesting. But not cross platform. Not federating code, just RSC output. Cool, but different.
Can you please make a video on how to properly set up a repo using turbo repo and nextjs?
passing data one level to one component isn't prop drilling
What about those who wanna use capacitor to make it into an native app with nextJS? Is it a good/bad idea?
I've put Next into Electron before. It works.
This is the first time am beginning to like the app router
It’s truly amazing to use
Fine Jack am sold
What is vecode theme name please?
🫡
I have no issue with RSC, the standard is great. I just don't like Next.js' implementation, or Vercel in general to be honest. Its so obvious how they are using their position in the React core team to benefit their infrastructure business.
Nextjs is only good when you are not the one paying the bills
How about something more complex like using Apollo Client with the app router?
Thank goodness for Remix, else I'd have no choice but to abandon React before alternative (non-React) frameworks have a chance to mature (features, tooling, ecosystem, etc.). Granted it's been several months since I dumped NextJS (feature incomplete, needing to work around default caching strategy, use client, and overall feels over-engineered IMO). But even if all these issues addressed, NextJS is too tied to Vercel 's business model for my taste, which is the single biggest issue I have with NextJS.
Remix is adding RSCs.
@@jherr thx, and aware . I assume reply is in response to use client mention. will be curios to see how support for rsc manifest in remix, which is a more pragmatic framework imo. was but just one example -- remix dev experience is simply much better on remix for me, and, again, not tied to vercel.
I dont understand why not do all fetching in Comments component without any prop drilling?
The Pages router doens't support that. Unless you are talking about fetching off the client, which doesn't give you Server Side Rendering (SSR).
The biggest issue is assuming you are using a specific server for a UI framework. Say you want to use a different backend language... React is actually driving away from that for no particular reason. It's turning into a bad blogging framework.
What would stop you from using Next.js with an API written in Go or Python for example? You would just fetch from that API instead. There is no requirement that the API is Nodejs as well. Yeah you do need Nodejs to run the Nextjs server, but that's trivial. I use Next.js all the time and I have never ever written a single API handler in it or in Nodejs. I just connect to .NET backend because that's what we use for projects where I work.
@@rand0mtv660 it's frankly ridiculous to say that you MUST have two servers running in the first place. If I have a lightweight API and a sophisticated process running in real language server, hosting a react app on an endpoint should be perfectly reasonable. React is just supposed to be an interface framework, I shouldn't NEED a specific and specialized back end to run it.
@@chrisdaman4179 What other option would you like? That a Python/Go server can render React? I think that's unreasonable to expect since that would require running JavaScript somehow. I don't remember a good templating language that can be rendered by basically any backend language server and compared to React, most templating languages suck anyway. Even if you use something as basic as PHP, you still cannot just render html templated files, but actually require php files to do dynamic stuff. If you require React only for client side and don't need SSR for SEO, you can still use React as a client side only SPA UI library, even with Next.js. If you don't have a use for React or it doesn't fit your requirements, just don't use it. I don't see what's the big deal.
@@chrisdaman4179but how is vercel gonna make their $$? I can see that they are trying to be developer friendly, but imo they are failing on next. Nextjs feels like an experimental framework, a sandbox for them to try new react alpha features. If they make big changes every year, the applications are either running on experimental features ( newer apps) or deprecated code, there is no consistency in the nextjs framework, I hate this approach. It’s not about the app router or the pages router, but rather the pain the whole react/next ecosystem became hard to maintain and follow along . I still remember when react ppl used to mock angular for the migration to v2. Now react adds a hook every 2 weeks and next changes every year. So yeah,no one is saying it’s changing for the worst, but not everyone is a KZheadr doing todo apps to showcase nice new features.
@@chrisdaman4179 That's just because RSC are new the only player is NextJS or at least right now. But for what you are saying I don't see what would you need RSC if you only want the frontend comunicate with a separate backend.
I’m not a big react guy. But the app router is so much better in my opinion.
App router is the most intuitive way to build full stack apps. If it doesn't meet your expectations, you need to check your architecture, design or something because what and how are you building that is so difficult with this simple framework?
Anything bighuge with extremely severely thick clients with very *very* picky specifications on security and a demand for very rich UIs - think triple grids in master detail situations within tabs etc. - e.g. an ERP, or a very thick dashboard-ey application with lots of thick components where you don't have the luxury to implement stuff on your own but instead you have to work with already existing libraries (e.g. PrimeReact and so on). Yes, we are talking intranet, no, the APIs are out of your control and *not* implemented in Next but in another language / environment. You know, your typical internal corporate tool.
@@PhilipAlexanderHassialis what would you rather use then? Because to me it sounds like you want Microsoft SharePoint which is a pain to work with
@@PhilipAlexanderHassialisthanks, feel most react devs are doing internal corp apps
Yeah! God forbid you have something running serverside more complex than js can handle. If you want to use react, just use JS all the way down! Or maybe you shouldn't assume a backend from your front end, and start opinionating things in that direction
@@chrisdaman4179 any examples? Btw I use dotnet daily and I don't know what I couldn't do in Node that I can do in dotnet
"Lets give the average frontend dev a server" they said.
"Destroy react", isn't react just a library, and Next.js just a framwork that utlize a package, in this example, react?
Yes, but React recommends not using React (for real) on their page, they recommend using a framework like Next and there hasn't been an update to React since 2022, all the features seem to go to Next. I like Next, but I would like React to keep being a SPA option.
"Destroy React" in this case is referring to the increasing frustration people are voicing about React and its complexity. React Server Components are a React concept, not a Next.js one. Next.js just implemented them first and people are experiencing all of this new React through Nextjs and so it's kinda implied Nextjs is destroying people's will to use React.
The politics side of it is a legitimate concern though. When a company with a paid service is heavily influencing the direction of the ecosystem towards something that (understandably) brings them more money we must ask if this is the right direction.
we want to be independent when we are selecting a js framework; content is great though. thanks a lot.
i know it is our decision to use nextjs and experimental features, however, developers are human and they want to use it anyway.
I wonder what you'd say about the middleware.js feature which is behind vercels paywall. You literally need to pay to use it
developer expreience is not just how easy to handle a feature. people do not like the fast patches and changes in a year. you have to follow the vercel to deploy a simple app and it is not woking anywhere else (aws).
What I showed here hasn't changed in over a year, at least.
Nextjs isso perfect
Qwik is the future anyway. There is really no comparison in power and performance between the two. Even with the upcoming React Forget buildstep it has no chance to compete. React is finished, and doing stuff it never was supposed to do. Its repo should be archived and link straight to Qwik. RIP React - won't be missed, thank you.
All of these was quite much anti-patterns only a few years ago (expect now they are on the server). Funny nobody really cared for 10 years about exposing APIs, but here we are 😂
Refreshing to see someone making sense rather than just jumping on the RSC bashing bandwagon. Once people are used to RSC's they will all see the benefits of them
sure, but at what cost
@@brokula1312 the cost of having the learn something new. As software developers, learning new things should be second nature to us at this point. Took me a few days max to understand the benefits, it's not difficult
@@tom.watkins Great, now learn DDD because it's cool to learn something new. I'm all against the cycles of reinventing-relearning. It brought nothing but misery in software development. Trust me, RSC will fail eventually...if not very fast then later when someone will "rediscover" how easy is to just act as a "client" and let the server be "server" and not a renderer. Another influencer, another Dan Abramov will "revolutionise" FE yet again. I can't believe people hyped idiotic Redux. Total benefit of RSC is very low. Most of the time web apps don't suffer from things which RSC are trying to solve. But bruuh...what if some user is trying to open a page i Sahara desert with 1G connection on his Nokia 3210??? Never mind we have image files as large as couple of megs or even 4K video stream...we need to address that 30kb bundle size which will be cached by the client anyway.
@@tom.watkinsI guess you are not the one paying those vercel bills
Somebody call the firefighters because that is one HOT take 🥵🚒🚒🚒🚒🚒🚒🚒🚒🚒
what about traditional SPAs?
Use a different framework, like Vite. There isn't one framework that is perfect for all scenarios.
"I'm not going to get into that, that's a bunch of politics" 😂Wise man
fck sakes every fcking time I go to learn something new, it fcking gets drama and people abandon sht. I'll stick with the php boys and just be glad with that.
True I'm with you lol
Hey Jack, wait until you have to incrementally migrate a internationalized pages router nextjs app to app router. Hint: Not currently possible unless you refactor all the pages router into app router. They do not co-exist as much as Vercel would like you to believe otherwise. Which is crazy. I feel like I made the biggest mistake choosing NextJS. They keep breaking stuff.
pure lab experience