Responding to Reddit on the Next.js App Router

Trying to provide a more helpful, thoughtful response to one developer's bad experience with the Next.js App Router. Hopefully this format is helpful!
◆ Reddit post: / the_nextjs_13_app_rout...
◆ Client components: • Are React client compo...
◆ Incrementally adopt: • Incrementally adopt th...
◆ Why do Client Components get SSR'd to HTML? github.com/rea...

[@chairlovawitabat]

Regular check ins like these are incredibly useful. I give you enormous props for addressing the critics in such a productive and insightful way.

[@edwardshturman]

heh. props

[@leerob]

@@edwardshturman He tried to give me `useState`, but it only works in client components

[@benchilcott6908]

Honestly the biggest mistake here has been calling the app router stable, before server actions are stable. That has really added to the frustration for me, where the app router is being recommended as the default option, but half of the whole paradigm is still in alpha.

[@dota2-plays-shorts]

ageed 100%

[@null_spacex]

That's interesting. How are server actions half of the whole paradigm? Did you have server actions when using getServerSideProps?

[@method_actor]

Exactly. The data fetching with Next 13 is clearly an improvement in DX from getServerSideProps. Data mutation though, and optimistic mutation which is pretty much essential in any web app, being an experimental feature is just really not well thought-out. It's either all or nothing

[@wolfinhooo]

server actions still (imho) feels like a bug they somehow turned into a feature. I wish I knew qwik city before building a whole bunch of shit with this next.js version. I usually live on the edge with stuff, but it's the first time ever it was actually a mistake. It still is clearly unfinished.

[@benchilcott6908]

@@null_spacexIf I’m building a Twitter clone app and I’ve fetched some list of ‘tweets’ in a server component, how am I supposed to handle likes or replies to those tweets without using experimental features? And without writing client components that I’ll just need to refactor when server actions become stable?

[@miro-hristov]

The app router's biggest issue is its inability to disable cache, making it practically useless for fetching new data from the server without page refresh. This flaw has been present since v13's release, and despite a video by Josh (?v=25yjSzl6PsQ), it remains unaddressed by most Next 13 fanboys. How v13 was released as stable is beyond me. A demo showcasing the problem using and fetching non-stale data from the server would be eye-opening.

[@iPankBMW]

EXACTLY! Vercel PLEASE fix caching! export const dynamic = "force-dynamic" doesnt work!

[@kain1638]

yeah, that needs addressing

[@leerob]

We're working on further explaining how caching works, I'll make a follow up video on this. It's going to take more education!

[@miro-hristov]

@@leerob Amazing! 🙏🏻 Can't wait...

[@snivels]

​@@leerobI think it would go a long way if you could just use the example video commented above (Josh's), and show us how to get it working properly in a server component without it being cached indefinitely. My tests with revalidateTag and revalidatePath didn't yield a solution.

[@Avalk]

The problem with next13 is that RSC doesn’t work too well yet and random errors are far too common

[@fahmi2978]

yeah when error happen, kinda hard to debug

[@leerob]

Could you share any of the errors you're seeing?

[@Avalk]

@@leerob I had a problem where a built application in standalone mode wouldn’t start and it was only solved in the very last minor release, other than that it seems to have problems when switching from and to draftMode, “unsupported server component type: {…}” is one I’ve been getting a lot when using next/image in certain conditions which I’m still trying to repro outside of my project ( and using an image tag instead totally solves ). Some errors would trigger in my CI pipeline and not when running test locally or running the application and so on… that’s why I call them “random”

[@leerob]

@@Avalk Do you have any GitHub issues I can look into?

[@lachlanjcampbell]

It’s true, there’s still many errors that are tough to debug. Running a server component from inside a client component, for example, my site loads fine for one second then crashes, and the error doesn’t say the name of the server component you need to remove; if it’s deeply nested in a component tree, when you’re new to RSC (as we basically all are), that can take hours to figure out. Showing an error that says “You’ve imported Footer, a server component, from inside PageLayout, a client component” would be incredibly smoother instead of React internal errors.

[@devagr]

Great video, and big props on handling the criticisms like you did. I hope the messaging and education around server components gets less confusing, it's an amazing breakthrough in javascript app development and I really hope more people recognize the benefits

[@masnwilliams]

Love to see engagement from Vercel and yourself on topics like this. I do think that Server Actions play a large role in the adoption rate of App Router. Gotta make sure you get it right but I think the sooner that's GA, the more adoption of App Router we will see. I've found myself running into situations where Server Actions are the best option so I'm looking forward to seeing it fully released.

[@leerob]

Server Actions will definitely help us write less code. Looking forward to them.

[@Assoehosselaar]

I really admire how calm you respond to all these reactions seeing that nobody thats complaining has an actual clue of what the intention behind server only components is.

[@AugusDogus]

Please definitely make more videos like this one! Thank you for this one and great job Lee!

[@0mn10us0wl]

What still pisses me off the most is that server-components are the defacto default rather than client-components. Really hate this, and it makes both the migration of your own code as well as the migration of library-code a lot more painful. Really unnecessary. SvelteKit seems to be the way to go for me atm, sane APIs, no rushed concepts, maturity (even though it's way younger). It just works.

[@username4794]

I appreciate the time you took for making this video. It's a step forward and I think you should continue making these kind of videos. I'm currently working on a new project using Nextjs app router, after spending 3 years developing web apps with React. Since you're already heavily promoting the new app router. It would be wise to create a video or a video series where NextJS experts from Vercel would explain the best practices when working with the app router. Here are a few topics that I think would be really helpful. 1. RSC vs RCC - when to use what - pros vs cons of each. Add examples for use cases of each of them 2. Best practices when working with interactive data with RSC. Data invalidation - in the video the developers go through an example project. 3. Best practices on SEO - how to efficiently use Nextjs Metadata to achieve the most out of the new API (focus on generateMetadata) 4. Videos based on community responses - it would be cool if you'd open a Github discussion were developers could suggest video ideas. You'd record videos based on the amount of up votes/ reactions. For the readers: If you think my comment makes sense and would want from Lee or the Vercel team to create videos on these topics, please give this comment a thumbs up.

[@mhddngs]

I appreciate you taking the time to break this down. Community opinion aside, hearing the team’s goals and intended uses of these changes really (really really) helps people like me who are earlier in the react journey understand how to approach and think about the changes.

[@leerob]

Thank you!

[@DaveMacpherson]

Hi Lee....thanks for the engagement in addressing comments from the community. Since you asked if there was anything else along these lines you could do, could you address the caching issue that many Tuber's have been talking about?

[@leerob]

Absolutely, working on better docs right now and will make a video

[@AmodeusR]

As someone that experienced the old Next paradigm and only really started learning Next with the current paradigm, I felt the old one was much more complex and confusing. The new NextJS just feels natural. I'm not necessarily talking about "react-wise natural", but programming-wise it feels natural. Though there are things I don't like, like the many files that will happen to have the same name, some paradigms that otherwise would be really bad like multiple fetches and likely some other stuff I don't remember right now, but It's quite a good experience overall.

[@jeffyangmusic]

I just started using the app router last week, and saw this post on Reddit this morning. I didn't really agree with the premise, but wasn't well-versed enough to have a strong opinion. So far the experience has been fine, and I found the documentation easy to follow. Thanks for clearing things up, Lee!

[@samu350]

Win VP for sure, love your tone on these and it does help alleviate many concerns developers (including myself) had about the app directory.

[@mma93067]

I’ve for no problem with server-components. My issue is with the fact that server components are the default. Given that in professional environments, you need separate backend service, most next projects I’ve seen are static builds. Lots of the new features besides server components in 13.4 like nested layout and named methods in api routes could’ve been used with pages router as well. The only one profiting out of default server components are vercel who can charge more increased server load due to default server components

[@abdulachik]

i have been using app router since it came in all my pet projects and other one small professional site, its just great, I feel people who arent loving it are not understanding the power yet but at some point will and will understand how much you can get done with very little code

[@codinginflow]

The only thing that really bothers me about the app router is the soft navigation that caches even dynamic SSR pages when you navigate between them. We can revalidate them using server actions but for one, revalidations cost money and secondly, I might not want to build my backend in Next.js.

[@leerob]

Working on a video about caching!

[@JohnMcclaned]

Vercel needs a planetscale-like course that helps everyone grasp the concepts.

[@IQUBE]

Yeah, that would be great

[@leerob]

Working on it!

[@sck3570]

I have a problem with newer version of Nextjs(every version after 13.1.2), it messes the dynamically loaded components in /pages directory to the point that its take 2-8 seconds to load the component while in version 13.1.2 it loads them instantly

[@sandrinjoy]

13.1.2 has bugs in loading lazy components. update!!!

[@sck3570]

@@sandrinjoy can you be more specific, cause as I told every version above 13.1.2 make every component loaded via "dynamic" take 2-8 second the first time they load, which is not acceptable

[@JakubGaniaSoftware]

More explanations always useful. Greetings to you Lee.

[@atc7675]

I really do not understand the answer at 8:16 for which the question gets to the heart of the discussion. What exactly are the main benefits of server components? Avoiding authentication and databases? It doesn't make sense to me.

[@Dev-Siri]

Honestly, the new paradigm with the app dir and actions is actually better Server-Side than before. In the pages dir, all next.js did is take the react code and run it on the server before running in the browser, that was it. In the app dir, the app is truly taking advantage of the server. The RSCs components are not hydrated so less client overhead and adding the option to do setver stuff in them, server actions allowing code on the server from even a client component etc etc. This also allows for better HTML. Because now you have two choices, make it a client component and useState or use some html attribute that works without JS and can be more accessible. The biggest misconception that people have about the app dir is that it doesn't let you build highly interactive, which is not true. "use client" is not needed everywhere, at the top level makes everything down a client component.

[@TheTmLev]

Honestly, it's amusing how much developers complain about the complexity of the App Router when in reality it makes it so much easier to build applications. I've had a great experience with RSC, and while there are some patterns left to figure out (like infinite scroll), the amount of flexibility and easiness the App Router has given our team is really impressive. Thanks, NextJS team!

[@seansixsixsix]

1 year ago, my team decided that we would wait out entire version 13, so we just freezed at v12.4.3. Seeing all those comments below, I think we should give v14 sometime to mature, when v14.2 or v14.3 come out in the future, then revaluate our options.

[@sck3570]

you guys can update to 13.1.2, we currently are running in /pages directory with version 13.1.2, That version is like version 12(nothing changes). But every version above that kinda messes up the dynamically loaded components. and we haven't figured out why yet.

[@seansixsixsix]

@@sck3570 thanks mate

[@EthanStandel]

This makes little to no sense. 13 doesn't force you to use the app directory. If you want continued security and stability updates, you should stay on the latest version.

[@JeffBarron1]

im conflicted, i want to love nextjs but i dont. its like a lounge that converts to bed its neither a good bed or a good couch ie its trying to be too many things, it makes my back hurt

[@devdanio]

Great video Lee thanks for you insights. IMO there is a lot of confusion around RSC for two reasons. 1) The naming kind of sucks - calling them server and client components, but yet they both get rendered server side. 2) The mental model is actually very similar to how Rails and PHP apps have been built for years. Simply render everything server side and then ship some javascript to enhance the experience. I'd imagine a lot of the devs using react and nextjs have been around for less than 10 years so building web apps any other way is a completely foreign concept. The idea that you don't actually need to make API requests on the client side is vastly different than how we've been building apps as a community for a while.

[@jeffnhorner]

This is really helpful and good insight. Love this type of response video and I think it's super helpful as engineers attempt to push the things they're working on further with new technologies/apis. Thanks Lee!

[@FreeWebToolkit]

One feature that I like about Next13 app router is the possiblity to make multiple requests with both static and dynamic fetching in the same RSC. With the old Next (page directory) we couldn't do that ( we had to use either getStaticProps or getServerSideProps).

[@leerob]

Yeah, I'm a big fan of this myself.

[@josephcobbinah5412]

I like that you were empathetic and objective in responding to the reddits. Coming from strictly client-side React background, I tried it and it does take some time to actually appreciate the benefits Server Components brings to the table. Thanks for this insightful video.

[@developerpranav]

Love the positive take on the criticism and the inconsistent reception of the new app router model. Absolutely loving the app router, though I miss my favourite flow of tRPC + React query from the pages directory. For now, I'm passing server actions as react query/mutations functions, which bring me 100% feature parity with pages directory, and I still get to enjoy the benefits of RSC. Hoping for server actions and turbo repo to be stable in Next 14!

[@richarddunn6505]

Hang in there, Lee. Not everyone is a anti-Next13 app router shill. I started my transition from pure back-end dev (and that is coming back from a 4 year failed hiatus at semi-retirement as a truck driver), to attempting to become a full-stack developer. That is starting with little javascript experience, going straight to a do-or-die project with a new company as the only developer. So, I had to pickup React/NextJS, while doing my old-school spring boot backend. I started in October of 2022 with React, transitioned to NextJS in Dec 2022, and got everything to production usable by June. I am not a fast learner, and being a sole developer out in the middle of nowhere in the desert SouthWest, I didn't have any help other than online videos (thanks Dave Gray!) and the online resources. So I hit the worst of the transition pain, all while trying to learn everything at the same time. It all works fantastic, it's fast, stable (running almost 2 months without even a reboot so far), so I figure if an old geezer (eligible for Social Security) can learn new tricks and make a great website with NextJS, Java, Rust (learning that at same time), Redis, Neo4j, REST, etc., all fronted by NextJS (on the app dir setup, no less), it can't all be the Doom and Gloom I see online. Many thanks from me!

[@codinginflow]

Just don't let the critcism discourage you. When we complain about frameworks it's easy to forget that there are actual human beings behind it. I love working with the app router even tho it still has some rough edges.

[@therealdevopsintern]

What i have learnt over the years is not to jump real quick using early stable versions for production ready app, I'm still using pages directory. Until all errors are handled completely- i don't see myself using app router. One of the fustrations i have encountered trying out the app router is the use of state management like context or redux toolkit.

[@kbitgood]

I love this format! Make more responses like this. Just please make the text bigger for those of us who watch KZbin on our phones 🙏🙏🙏

[@runonce]

It's great that you engage with the community in this way, great vid! Thank you.

[@papadavis47]

Well done, Lee. Some of those comments would be difficult for me to stay positive and productive - if I were doing your job. But you pulled it off 😀 You spoke with good clarity and professionalism 💯

[@LC12345]

I came into Next when the app router was out, but I have 20 years of web-dev experience. What I see in the Next-community on this topic is a classical “I don’t like how Facebook looks now, I want the old look back!”. The changes in paradigm and mindset has not been communicated well enough by the Next-team.

[@RolandAyala]

Very impressed to see the customer outreach here to address questions. Kudos!! I agree w/ some of the other posters that Nextjs 13 is half-baked and it puts devs in a tough position of needing to get onboard w/ the unfinished new or stay on pages and incur more tech debt, or worse, split your app between the two (supported, but no thanks) -- really need to finish actions, and knowing new bundler is on the way is also unsettling. Final straw for me was caching which seem optimized for static site generation -- whatever the case, was source of friction for me and the whole "use client" things needs to go.

[@Shubham-yc6nz]

If devs are provided with a good scaled up project with next 13 app router it would be great learning. Server model definitely messes up the brain on how to structure stuff correctly.

[@vincentjohnflorio]

I am too afraid to use the app router yet (perhaps irrationally) but talking about these things openly is reassuring in the sense that it feels demystified to talk about them in a human way. It's really difficult sometimes to feel like there are official sources of for-sure help when lost, and the documentation could be great but sometimes people need to hear the same things in a particular way, a different way, to finally 'get it.' You also can't spend the rest of your life answering emails about the same 15 questions, where the only details that change are the slightly different circumstances people have with their varying levels of experience, so a video like this is a great middle ground -- especially when it's based off of what a group of people have discussed around a topic. I am really hands on so practical applications of "What can I do with it? Can I see it being done, in practice?" go a long, long way for me because then I can feel comfortable knowing not only what a thing does, but see, tangibly, that I can also probably do what I just saw, and then I get to banging away at it to try it for myself, or trying to tweak it, which means I'll understand it in a more useful way for me because I'm the do-er then, with the confidence of having some understanding of what the heck is going on :) I am not a big KZbin person when it comes to developer material so you are literally the only face I see of Vercel, and I worry that you get hung out to dry like a chess piece when you're just doing your job, and politely at that. It's obvious you care about the platform and educating people. It, and your patience, is appreciated.

[@NZTechArc]

Even though I was super unhappy about the support and my experience was awful, I can actually see that this is one of the best frameworks. I just wish I could get help.

[@mohamed-zhioua]

many pple dont get the fact that next js still pre-renders client components on the server and caches them, only the hydration part happens on the client.

[@friendly__drone9352]

Great idea to make a video update! I have a different kind of question. Is there a way to buy some Nextjs stickers somewhere official?

[@amorto3420]

What frustrated me the most was the bugs really. Bugs with not-found page, loading state and bugs with parallel and intercepting routes. I just wanted to make a website faster but it seems I am constantly on github looking at issues. I followed the exact docs yet it doesn't seem to work. The error is unreadable, I can't even search for it to point out the specific reason why it's not working. I had to downgrade next to make it work but then that introduce other type of bugs. I miss pages directory, It was so stable.

[@JustMack]

I just continued using my Next js 12 I did update to 13 but the issues and bugs were way to much I had to switch back to 12, and continued using my normal pages directory

[@kortes8914]

Great video! It's calming to see a face of vercel talk through these things. For work I'm (we're) using NextJS for ~ 6 different projects. Only one of them so far used the /app-directory. For the few pain points we encountered we either: 1. Stick with the /pages for now or 2. Find a hacky way around the problem for the time being. I agree that most issues however are simply related to the understanding of this paradigm shift. Im grateful that react (and vercel) is pushing innovation agressivly, but also keeping a ”safe and sound” way of building apps. On a personal level I would suggest anyone reading this post to give Svelte + SvelteKit a go. A whole other topic is ”React being the actual pain point”. It just so happens it is the business standard of today. Svelte is a breeze of fresh air and much more ”native” to the css, html and javascript that we all know and love.

[@Trekiros]

I think the question about "why would I want *less* interactivity" is an important one. As you point out, there are certainly use cases for static html being served with react and nextjs, but these are surely not the default use case people have for react nor nextjs. So presenting the app router as the default, I think hurts the message here. I maintain 5 websktes currently, and only one half of one of them is a good candidate for the app router.

[@JohnoScott]

Yes more like this BUT WITH EXAMPLES please 🙏

[@leerob]

What examples do you want to see? Here's one github.com/vercel/commerce

[@shivamsahil3660]

I migrated to NEXT 13 app directory and I am finding it decent. Ofc I do use 'use client' at lots of places but I like the idea of server components and how you can break a complex web app into multiple small chunks which are mixture of client and server side components. Interactivity is always going to be challenge but since React was built to enhance client side interactivity we're used to think that way and we get overwhelmed by server side fetching. I think the more we try it the more creative ways and methods we will utilise to make a app fully functional full stack app utilising the best of both worlds!

[@gmzi]

I'm gradually starting to get the hang of App router and I like it, but it wasn't easy nor fast. At some point in my learning process I felt it was released "too soon". Pages dir has such an excellent documentation, makes it look like App dir docs are behind, but I'm sure they will get there. When Server Actions is ready for prod it will be awesome!!!!

[@leerob]

Anything in particular you want to see documented? We've made a ton of improvements in the last few weeks.

[@obouchari]

@@leerob Maybe e2e testing? Also, I agree with many, we're using NextJs app router to build an intended for pod web-app, and most of the times we debug some errors for hours and error messages are not helpful at all and don't show where the error occurred in stack. Regardless, I really like where the Next project is headed I don't have any confusion over RSC or RCC I think it just requires some planning and analysis of the requirements and what goes where and would it be fetched etc... Another issue (Not NextJs fault obviously, but stating it anyway) I'm seeing is a lot of SDks/Libs adopting it very slowly.

[@gmzi]

thanks @@leerob for your response!! The topic I'm currently not finding is Authentication. I see it on /Pages router but it seems to be missing for /App router

[@arnhazra]

I am experiencing several issues with the App router. When clicking on any link, there's a noticeable delay of 4-5 seconds before the page loads, and then it proceeds to fetch the actual data, including an unnecessary API call "rsc?some random id." This situation is causing inconvenience and could be improved to provide a smoother user experience.

[@Thorax232]

It would be far easier to defend NextJS if this didn't exist, "Would you like to use App Router? (recommended)". As you say, the pieces to make this come together aren't finished. This is setting people up for failure.

[@Jakerandall-h9r]

App router is great. It DID take me a a bit to get a grip on it, but I quite like the new paradigm. Server actions are AMAZING too.

[@rgsquintanilha]

I appreciate you taking the time to answer the question, however you haven't addressed the actual problem, which is, how can we invalidate data after a mutation without using Server Actions? Right now the only solution is to call router.refresh, which seems too aggressive. Also, there is a known issue where a hidden 30s caching takes place and prevent the user from seeing the freshest data with they navigate back and forth quickly, which is very common in some scenarios.

[@iPankBMW]

Almnost one year later i still wonder - when will Vercel fix export const dynamic = 'force-dynamic' and also the revalidate:0?.... the page is SSr on iniital load but all ofther times its cached and displaying old data without loader.tsx ....

[@cmaciasjimenez]

Thank you for the video. I think that a good way to ease the change would be to have better doc explaining the patters and how to use them. Also it would be nice to have examples of full fledge applications and sites using the new model

[@leerob]

Here's one example: github.com/vercel/commerce

[@mertdr]

I’m still having problems understanding client components. For example in php, you build the entire page with html and it’s being generated by server then you add interactivity through js to manipulate dom. In react, entire html is generated by react itself. Are you saying when I add “use client” to the beginning of a component file, nextjs and react is smart enough to render jsx (html part) on server and strip out dom interactivity functions and move them into js? If it’s so, it’s simply great. But it brings the question of what’s the point of server/client seperation then if it’s that smart (except server operations like fetch). Otherwise the frustration comes from using client side rendering just to use a simple state change interaction such as displaying mobile menu on click. The dilemma of “should I turn entire header into a client component just to display a mobile menu by class change on click?”

[@EthanStandel]

When you add a client component to your tree, that component and everything below it become hydrated. There's no magic compiler that's searching for only the dynamic parts. It's just everything below that component acts like an old NextJS app and renders on the server and hydrates on the client. The benefit of the separation is that for every component you do hydrate on the client, you have to send that React component down to the client. So making more server components and less client components means that you'll send less JavaScript to the client. That means the interactive parts become interactive faster because you're not waiting for the whole React app to load on the client.

[@mertdr]

@@EthanStandel thanks for the detailed explanation and clarification. Actually that’s what I also thought. The question came to mind after reading Dan Abramov’s post (beginning of this video) referring that “client doesn’t mean client” part. I thought static html part is rendered on server, even I know it doesn’t seem possible. Apparently Next’s static rendering comes to help that stage. But yeah, apparently we’re in a race of sending as less js as possible to front end. Hope it doesn’t mean react is shooting itself in the foot. A js library tries to use less modern js capabilities to build the content. I’m still getting used to it. But I must say I don’t enjoy that as much as standard react because of constant mental stress of thinking the possibility of making a better and more performant app by sending less js to frontend.

[@EthanStandel]

@@mertdr I think React is going in a correct...ish direction. React could focus on render performance or update performance or a bunch of other stuff. But they realized that the slowest part of any JavaScript app is having to send so much JS over the wire. So improving the performance of React from this direction is the greatest impact they could have on a React application. That being said React isn't really my first choice of a frontend framework anyways. But it's a safe bet, and this work is helping it to remain a safe bet in the future.

[@mertdr]

@@EthanStandel totally agree. In fact, Astro and svelte got this party started. Next and React teams are doing their best to catch up and it is highly appreciated. Only problem is it looks more complicated than it is because there is a lot of baggage when it’s compared to new frameworks. But like you said, it’s good to know that both next and react won’t be left behind thanks to this new approach.

[@kassios]

I'm quite ok switching to a different paradigm. I get all the advantages and I'm eager on using them. My main issue is the development experience. In some app routes I get full page refreshes on code changes instead of hot reloads. This is really hindering production and I'm missing the CRA dev experience. Maybe I'm doing something wrong with mixing server and client side, but debugging this condition is hard.

[@EthanStandel]

I notice that a lot of people are frustrated and acting like you can't write code the exact same way in the app dir as you could in the pages dir. I really think it would be worth addressing how to take a a few pages from the pages dir and do the simplest possible conversion to the app dir. So just take the getServerSideProps/getStaticProps and move the call to the component in the app directory, and then render everything else as a client component. And then clearly explain that the behavior is now exactly the same as before, tada. I really think this is the missing link that most people are missing. The sad thing is that every other complaint seems to be developers who are frustrated that they have the opportunity to make their apps more performant with partial hydration, but they just miss not having to think about it.

[@greendsnow]

Can developers sue Vercel for releasing a product that is so easy to leak credentials with?

[@bestcoders]

for me I don't see app dir as a problem. I only have issue with caching I mean it is a "monster" caches things and seem like it does not need to let go no matter how you try to disable, don't know if there is a way to just disable it totally in the app dir and maybe i can start to enable for things I need to cache. otherwise my experience using it is just better then previous

[@shrayyefformula1]

Do you have a guide on how to test server and client components in nextjs 13 ?

[@khaledsanny4817]

They don’t approach the adoption the right way. I was also super annoyed by the breaking changes and went to focus solely on NuxtJS… But then I tried looking at pro open source code from real polished apps like taxonomy from shadcn or even the apps made in builtwith appwrite hackathon and then it clicked to me. I read NextJS doc thoroughly again and started understanding the benefits and I can just say that it’s sort of a pale imitation of Island Architecture but still react-ish. NextJS 13 is good … just take the time learn it AGAIN 😅

[@FirroLP]

Really not seeing the difference with getServersideProps and RSC. If the upvotes of a post should be updated (and persisted I'm assuming) via a button click f.e. it would require fetching posts in getServersideProps before and also adding those as initialData to f.e. react-query (or any other data fetching library). That's exactly the same now too with RSC. Honestly not seeing any difference between those two. Either you add the data to a clientside fetching library outside of the routing context (even in pages) or you refetch the route which was already done in pages with router.replace(router.asPath). Maybe a video about exactly that pattern and the parallels between pages and app directory would be beneficial to most devs to make it click

[@rockNbrain]

Tks a lot Lee, keep pushing !!

[@shinchima]

A helpful 'defensive' video addressing some common myths/concerns, cheers @leerob

[@尼古拉丝土豆]

On the client side, RSC is just html, like a div span tag. It's wrong to complain about RSC, you should get data, status, etc. in the client component.

[@jayantrohila]

I m geting hard time with Ui library they are stopping me using surver components

[@karangill2065]

I love next 13 no matter what and I used in many different projects and i had a great experience in both pages and app router.

[@hibosco]

Is there any benefit of upgrading to v13 if we keep using the Pages Routers?

[@АлександрГерасимов-с3щ]

I like app router and have been using it in production since release in october. But I have 2 feature requests that really need improvements - make server actions transfer data both ways (like jquery ajax does) - make server components importable into client components. Maybe with restriction of not passing any data, but just let us skip this nasty model of pass-component-from-grandparent

[@predator00071]

Is styled components working in next 13 with app folder?

[@picozzimichele]

I have a question, I could not find answer to. I want my Navbar to live inside my Root Layout Component. However my navbar has a login button (very common usecase), so it needs to be marked as "use client". This has been causing issues since Root Layout cannot be switched to "use client" As a workaround I included a new Layout in every page, but I doubt this is the best solution to proceed, could not find any way to render my Navbar in the Root Layout which would be ideal

[@Jorgejhms]

Why it makes a conflict? You can import client components (navbar) into server components (root layout). In this case I would actually make only the button as client, and most of the navbar as server.

[@picozzimichele]

@@Jorgejhms never worked for me, I tried multiple times, as soon as I import any client components in the root layout it crashes the app. I tried even with just a plain button with an onClick handler. Unsure if its supposed to be like this or a bug, from the docs it says the root layout cannot be "use client", but I supposed it should still handle client components within

[@paakofibamfoquaicoe4193]

Change is difficult, that part of mankind.

[@joohyunglee1815]

Not sure if its been fixed but global error ui would not show up in dev mode. After creating folders to implement parallel route, I would have to close dev mode and restart the dev mode to see my parallel routes ui. Middleware would not trigger at times causing issues like refreshing tokens. Has anyone else experienced these issues?

[@iercan1234]

Still using pages for my new projects, good enough for my needs

[@2801rsands]

How do you make the app router work like a client side single page app now? It still fires on server for layout even with use client?

[@leerob]

Check this out: www.inngest.com/blog/migrating-from-vite-to-nextjs

[@benheidemann3836]

“makes me feel my entire codebase will be deprecated” -> “definitely don’t want the pages router to feel like something that’s deprecated” 🤔 This response makes me feel that it will be deprecated in future because if that wasn’t the plan then Lee Rob would just say “it won’t be deprecated”. For this reason, I probably won’t build anything new with the pages router. I feel similarly uneasy about features that will be deprecated in an unknown amount of time to one’s that have been deprecated already. Not sure if it’s rationale but I suspect others instinctively feel the same.

[@leerob]

It will be deprecated, eventually. But we're on the scale of years, not months. The initial data fetching APIs in Next.js like `getInitialProps` still work, 7 years later.

[@Terrorfiend]

I'm a bit of a dinosaur. I've been creating websites and web apps for 26 years now, and I've always hated the concept of client rendered websites - EmberJS, React, Vue, et cetera. SRC and server actions are where I want to be - building my app's HTML on the server, don't expose my API, and sprinkling interactivity on top of it with client components is my sweet spot. I'm building a huge app now with SRC & Server actions (shhh, don't tell anyone I'm using not production ready features) and while it's clunky, it's getting there. I finally have the best of both worlds (well, close to it) and I dig it.

[@rumble1925]

You would love htmx and the hypermedia approach. Stupid simple and the amount of client side scripting you need becomes minimal.

[@sreekeshiyer]

9:25 That's pretty much what I liked about Next.js. It was not React. It was simpler. It was and still is a lot more comfortable working with additional functions like getServerSideProps albeit the extra little learning curve. I understand working hand in hand with React as it grows but Next does not have to become React. Why mess with something that's working well enough. The support for RSCs is great, people will get to try it, but to make it the norm is a little annoying given how new they are right now. Maybe a year down the line, sure. But certainly not now. You might have a different opinion, and I totally respect that.

[@viniciusrangel544]

the router its so slow, the pre render its terrible slow, my API took 80ms to response, while next took 400ms to load the HTML, that causes some weirds behaviors. after test sveltekit I'm not going back to next, ssr there makes much sense.

[@Skia_]

What happens if i use the app directory and use the "use client" directive inside every component that i implement?

[@leerob]

That's fine! P.S. you only need to add "use client" to the root if you want everything below it to be a client component.

[@MoneyModeUniversity]

My god when did the frontend get so complicated. I tried to use the app router and the dev server experience alone made me want to throw my computer out the window.

[@sck3570]

🤣

[@tom400iq6ft]

move to sveltekit. you'll never look back

[@qwerty-or1yg]

Ikr, I really enjoyed react/nextjs couple years ago, now it's just getting more and more complicated. I'm really glad that we're using Angular at work, doesn't really give that many headaches as React does lol

[@sandrinjoy]

its not for beginners🙃

[@agusterodin]

Thanks for this. I think a lot of people are waiting for fully-fledged data fetching libraries such as Tanstack Query to seamlessly integrate into app directory for things like cache invalidation, polling, refech on window focus, etc. More about this topic here: kzbin.info/www/bejne/e4TRmYmXjK5ob8U

[@ayushgogna9732]

What if i can use App router but client side i like the file routing convention of app router but i love the pages dir for all the client things (i might not be making sense here but sometimes just to make a different component with use client on button click is frustrating) i have also talked to other people who kind of liked this idea. OR (pages dir with app router conventions)

[@philheathslegalteam]

Honestly the app router is fine. It’s the caching behaviour (or lack thereof) that bugs me. In addition to the dev server performance issues. I have moved on to Vite based projects like Svelte, Astro and Solid.

[@kasvith]

Funny part is people still complaining in the comment section of the video too, so there should be something terribly wrong with it

[@البراءبنمالك-ر1م]

Well, it would definitely help to have your tutorial in App router and not Pages router!

[@leerob]

Working on it!

[@tzuilee588]

App router is fine.

[@shanemarchan658]

the app dir makes rust look easy

[@DavidWTube]

Hydration error.

[@8koi245]

Oh nvm seems like reddit can't read 💀 anyhow thanks for the work you do!

[@anonymousmangalorean]

Totally agree with you on 9:33

[@mzerone-g6m]

Is that poeple with wrong ideas just trashing on RSC, wht i said wrong idea i mean RSC says okey devs server state like adding post upvote downvote need to handle in the server and client state like open modal work with complex canavas logic need to handle on the client maybe this is not clear for them but i thing it is awesome to work with this things i just drop fetch and all error handling and double the work that i need to do simple thing like CRUD

[@Necessarius]

Please chatgpt summarize this video in 3 lines

[@gmoniava]

For me the frustrating part was the new docs.

[@leerob]

What could we do better?

[@gmoniava]

​@@leerobreact docs have "Thinking in react" section, write similar one for nextjs - for client and server components and common scenarios.

[@nikhil182]

So far the most problamatic one for me caching.

[@VincentFulco]

This was an alpha feature released way too soon and then folks like AWS could not keep up with dev, messing up a bunch of end users with Auth/cookie issues. Really frustrating

[@jairjosafath9693]

⚡⚡🔥🔥

[@ThomasBurleson]

This video provided little value to the community. You perhaps understand the nuances. Yet many are confused by Vercel's adhoc improvement of the API that is not consistent with current practices. I think Vercel could do a better job of providing videos on state management and UI components and routers with client and server components.