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

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.

Great video Jack! I always love how you break things down.

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

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

The way of explaining things with practical examples is very intuitive and easy to grasp. Thanks for the awesome lessons.

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.

Imagine using this instead of proper backend in prod.

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.

So informative in such a simple way.

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.

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?

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...)?

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.

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.

Awesome video! Thanks for this.

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.

Thank you! I see so many negative comments about RSC and server actions on Reddit and Twitter.

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?

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

When your next js course will be available, Jack?) I'm waiting for it so much!😊

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.

"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.

I can tell you some example where page router wins: Handling refresh tokens. Have you tryed that in app router?

@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

Also, RSC components look very clean until you need to handle some errors in some custom way lol 😂

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 ?

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.

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.

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!

Great video like always!!!

when we use the React suspense with the App router, should we use the loading.tsx page as well? Looks like it is unnecessary.

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 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.

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 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'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.

So how does auth work. Like jwt tokens in this scenario? How does this hybrid server/client make handling auth easier?

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…

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.

What about Remix or Rakkas instead of pages router?

passing data one level to one component isn't prop drilling

"It's Bonkers"

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.

Me watching this while still developing using Nest.js and CRA :D :D :D

Thank you 🙏

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.

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 😅

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.

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.

Pretty good content I must say 🎉

Is it okay if i use react-router-dom in nextjs instead of using builtin nextjs routing

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.

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

What about those who wanna use capacitor to make it into an native app with nextJS? Is it a good/bad idea?

I really want to see you next video about Nextjs and coming module federation

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.

Can you please make a video on how to properly set up a repo using turbo repo and nextjs?

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

"Lets give the average frontend dev a server" they said.

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

This is the first time am beginning to like the app router

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?

🫡

Fine Jack am sold

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!

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

"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!

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.

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.

Nextjs isso perfect

Somebody call the firefighters because that is one HOT take 🥵🚒🚒🚒🚒🚒🚒🚒🚒🚒

What is vecode theme name please?

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.

I dont understand why not do all fetching in Comments component without any prop drilling?

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.

How about something more complex like using Apollo Client with the app router?

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 wonder what you'd say about the middleware.js feature which is behind vercels paywall. You literally need to pay to use it

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

"Destroy react", isn't react just a library, and Next.js just a framwork that utlize a package, in this example, react?

"I'm not going to get into that, that's a bunch of politics" 😂Wise man

what about traditional SPAs?

I’m not a big react guy. But the app router is so much better in my opinion.

we want to be independent when we are selecting a js framework; content is great though. thanks a lot.

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?

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.

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.

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.

I'm sold, and im a .Net developer

NextJS is awesome but somehow the modern PHP kind of :))

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.

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.

This is all well and good in an exemplary app, but in actual development you hit on a bunch of issues. You can spend hours trying to figure out why something is or isn't cached, then just give up.

pure lab experience

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.

huh, the fetching part is easier, but the mutations are a pain

Try remix, you will be pleasantly surprised