Forgot to mention VERCEL SPONSORS ME SOMETIMES BUT THEY HAVEN'T SPONSORED A NEW VID IN A BIT. THEY DID NOT KNOW I WAS MAKING THIS VIDEO. TBH THEY PROLLY WON'T LIKE IT
I love file-based routing because you can very quickly find the exact file you need to edit by just looking at the path in the URL bar. The larger the app becomes the more useful this becomes.
one simple way to improve this would be able to name the page component {anything}.page.tsx, that would solve my same issue with file-based routing continue to find any page.tsx component but let me prepend a name to that for instance: apps/login/Login.page.tsx instead of apps/login/page.tsx
Can't wait to see how the T3 stack evolves to include server components. The type-safety and easy hydration that TRPC gives is too good to give up IMO, but I'm sure we'll have something that matches in a few months
My thoughts are that tRPC’s place in the new model is completely on the server. Using a extended version of the vanilla client that would provide the next specific caching tags to provide router and procedure invalidation. I fully agree that the type safety and router->procedure structure are too nice to ever give up, but I think now there is less of a need for the react query part.
Coming from the vite ecosystem, using Next has been a major pain when developing on a 2019 Intel MacBook pro. The amount of times I have to restart the dev server because webpack straight up doesn't detect changes is baffling. I would try turbo pack but I'm using server actions so my bad I guess.
I use vite instead of next js whenever possible because of next's very slow compiling speed. The little black triangle on the bottom right is killing me.
That's fine, but these are very different things. I am not willing to give up server for faster hot reloads period. I don't see Vite as a professional tool, only as a mockup tool. I also see Vercel right now as completely undependable. I'm not going to bet on 100 new alpa/beta products after so many broken promises. So that leaves everything in a bit of a shit position. Personally I'm going to try out Astro and cross my fingers for a more sensible product.
@@Thorax232 it's a vague word to be fair, I was more intrigued by you calling Vite a "mockup" tool. What I'm understanding from that is using Vite for prototyping but not for production, which I think is absurd. Please correct me if that's not what you meant
Been using app router in multilingual CMS driven sites now for some months and it's definitely half baked for this use case. Seems like Vercel forgot the world speaks languages other than english, localized paths are a thing and the same people also use CMSs. Creating a bunch of folders and files for each locale is a mess which is mandatory if you want to actually use all the nice things that app router provides out of the box. At least Gatsby got it right by providing programmatic routing in gatsby-node.
Build times on Next 13 also got terribly slower, I literally had to downgrade a website that I just upgraded because builds were taking longer than 45 minutes and getting canceled. The time it takes to generate pages is way slower than 12 and this is really bad for websites with tons of pages.
Hurray! I was really hoping that was going to be your intro! :D It's very informative to get your POV on this, so thank you for that. Also, I like your shirt!
You talked about slow dev server experience, especially on Windows. I also worked on several App Router projects by now. For some I'm using an Intel MacBook, for others my WSL2 desktop. While the speed itself may be slower, from my experience the memory leak ffecting all my App Router projects is much severe. Working on my WSL2 desktop with 64GB memory is much more pleasant than on my Intel MacBook with 32GB memory. The dev server is constantly restarting because it's out of memory.
For me the app router development expirience is the first experience that actually feels like "full-stack" and not like doing back-end and front-end with workarounds to make them run from one single folder and ssr.
Looks like the app router is awesome for creating dashboards, but what if i need SEO? Is the page fully hydraded even when using client components? Or just the server components are hydraded before the page renders on the client? I know client components are rendered once on the server, but I'm not sure if it will be hydraded in the first load. Is there a way of caching an entire page ultil the next build? Something like getStaticProps, where I can schedule the page revalidation or not. I can also set an api route that revalidates a page programmatically. Can I get these kinds of fearures with the app router?
Yes. SEO is handled w/ , which will always be server rendered. There's also a metadata.ts file type. Revalidation is simpler than ever, set a revalidation time on a route and you can call `revalidatePath()` whenever
Coming from someone who used many frameworks in many, many languages over the years, AND had a prod app with the new router - app router is great. It is simpler and very reminiscent of Phoenix and Symfony. It is the first time I've felt a genuine effort to resolve the client/server conflict. But i agree with the drawbacks 100%... It took me ages to figure out the stupid client async thing. Its insane that no warnings exist, spent hours debugging weird app behaviour with it wrecking my CMS API quotas for no reason. I've also seen some bothersome patterns with client animations and transitions, having to pass whole pages as props to client based wrappers, just to do a simple animation is not great. At all. In fact nobody knows how to do it properly - here is an idea for a video Theo :D The file router is ok, I think that many developers misunderstand it fundamentally. I guess that comes with not ever working on an enterprise app. A large app in Ruby or Symfony would have the same pattern, but you'd see it used VERY rarely and exclusively for layouting pruposes or splitting concerns, for example admin vs lobby. Absolutely most of the time everything goes through a single app entrypoint, don't try to fight it. Regardless, Theo is correct - as the app gets larger, the intellisense does get wonky, and at one point, unusable. I blame Next - It's actually unclear how you should set up your code. Should i keep all the components near the routes? Should I keep them all in components? How do i do loading states on components then? Super confusing. It is very much unclear which libraries support and don't support the caching features. For example Sanity has not used fetch, and not exposed the actual http client, so you can't do caching. An alternative being that we do manual http calls, which we did. Screw them. Same thing about "use client". Some libraries bundle their functions into the same export, and even tho you are importing a simple zeroIQ function from them, for example to calculate URL for an OG image within metadata (server only) you'd get yelled by next about how you are importing a client component, which you definitely aren't. We need better tooling for inspecting bundle sizes. When I do yarn build, I want to know, for each page, exactly how much goes into the client and why. While something is better than nothing, currently its still a guessing game. Netlify is not behaving properly and while they do support next 13 they have all sorts of weird side effects where you have to add env variables to control the build process. So, Vercel it is.
Love nextjs but there is definitely some things that need to be tinkered with. Better errors would be the start. Spent all day just to remove from the layout file which cause all sorts of issues.
You mentioned ct3a will support app router soon, but with which libraries? Does trpc have a place here? Or now that is as easy as having an async component it's just a drizzle call inside it. What about auth?
I'm really excited for the app router but until now I don't think it's fully supported by TRPC. I'm pretty sure that Next.js 13 App Router based TRPC integration is still experimental. Continue the great job!
Really appreciate this expert view. app has been a disaster for me, with errors galore in 13.4.x, had to revert back to pages for now. from an uber beginner/intermediate noob
"Takes 5 to 10 seconds" Oh but Theo, I used to wait 2 minutes on CRA to see if I liked how my 5px change to margin looks. 10 seconds is BLAZINGLY fast for me, lol.
Even Expo now has a filed based routing. Although, with all the performance upgrades in something like Ionic/Capacitor, I’m still not sure if I should use RN or go through a web view for my mobile app project.
Mostly agree with this. Ive had to jump in head first to learn App Router for a new client, and it's mostly been a great experience. However, it absolutely wrecks my old 2017 MB Pro's memory. It's ancient so maybe I shouldn't complain, but I recently built an React app with Vite and my geriatric machine didn't miss a beat, but Next and webpack is just.so.freaking.slow.
I'm still convinced that astro's client directives make more sense than a component-level "use client" pragma. Of course that isn't possible with RSC since they decided that components that are only rendered on server are banned from even trying to use hooks. But a "use client" component is still rendering on server just like it always used to, hooks and all. Of course those hooks barely do anything on the server as state doesn't change.
Dev mode is really tired. Everytime i saved the file, the changes is taking so long. My highest time i got is 30 seconds. The turbopack break the hydration. Still recommend pages router. Maybe until turbopack is stable.
On the point of saying its misleading to call them "use client" components, misleading maybe but what's wrongs with calling them that. They run on the server during SSR what's the problem with that? Am l missing something ?? "use interactive" is a worse name.
Been using app router for 3 projects over the last few months and I haven't noticed any performance issues on just regular windows. Not WSL, just windows. Are you sure the M2 isn't your problem, being such a widely new and different architect?
Theo, you really didn’t need to shout the acdc “Highway to Hell” lyrics the whole review, just to prove some obscure point about programming that started to interest you all of the sudden
App Router has great features, hopefully they would improve performance soon, but GOD please someone made something about Typescript Server I think that would increase DX even more. I know is not a Next/React only thing, but using cool packages like DrizzleORM, Zod, ts-pattern and so on is becoming imposible, you have to restart TS server at least each 20 min.
Cache invalidation and naming things two hardest things 😆 Agree not a huge fan of "use client" but not sure about "use interactive". Being lazy I'd probably still prefer client since its a few less keystrokes (yeah, yeah horrible reason I know). I think the React team working on the RFC wasn't too happy with it either, but couldn't come up with a better one.
Also think "client" might just be a carry over from the original "*.client.js" proposal before they switched to the directive statement. I think whatever you call it still requires wrapping your head around the whole new boundary model RSC brings.
What amazes me is many of these features are in Nuxt 3 / Vue 3. We've had them for some time, like layouts/folders routing, server components, fetching inside components etc. Even React Query now looks a lot like useAsyncData in Nuxt. Well, I'm glad React users are finally seeing the light.
i've had a very weird issue with app router that forced me to go back to pages. there's loading.tsx fallback file which displays while page.tsx is being loaded and sent back to the client. i was writing client side filters which are synchronised with url query parameters so i used useRouter and .push method to change those parameters. but app's useRouter.push doesn't have {shallow: true} so every time a query parameter is changed, it requests page.tsx to load data again. and it's actually fine, no need to fetch data from client side with react-query or useSWR. but the problem is that it does not trigger loading.tsx so every time i selected new filters, the page was stuck for like 2 seconds while the new data is being rendered. i ended up rewriting that logic with pages router, react-query and getServerSide props for initial load of the content
I've been stressed out throughout the video that one speck of hair was going to get in your eye. couldn't understand what the video was. glad if it works for you sorry if it doesn't.
Why u didnt mentioned the BIGGEST problem - server cache! Nothing is working there. Gives us old data even tho we want it to refetch on server on each request…
On the subject of cold starts: what's the deal with the "cold boot duration" in the logs being ~150ms and the actual execution time being ~3s!? Surely I'm not the only one experiencing this?
Trying to use app router in new project but stucked at cache problem. How do you solve the cache problem when use next/link. The soft navigation always use client side cache and no way to disable this behavior except ugly router.refresh()
The performance thing is rough, but that issue is more attributed to usage overtime. I get near instant updates on webpack but the more I use it, the slower it gets so I need to restart the server and it's fine again until it isn't. Very annoying but I wouldn't say it's a big deal as long as I can restart to fix it. Definitely would rather not have to do that though but e already got the Typescript server restarts in rotation, what's one more? lol FYI, I don't use turbo, but was planning on giving it a try but from the sounds of it, probably better not for now.
Typing “use client” in most components isn’t a good dev experience. Wouldn’t it be better to let the developer define the default behavior in the config? I would rather write “‘use server” in 10 server components than “use client” in 100 client components.
Is there really any issue with dev server performance? Windows user here with okeish CPU and despite some random undetected changes from time to time I haven't experienced any issues
Well as a developer using t3 stack a lot, I still haven't used the app routing and I don't think I will start using it in prod soon, just have this bad feeling about it, as when it was presented I started testing it and all I got was errors, errors, infinite loops because of useEffect in 'use client' and so on. So Theo, give me an advice, should I start using it, would it affect the t3 stack usability. Anyways, amazing video as always, but where is the kitty?
Forgot to mention VERCEL SPONSORS ME SOMETIMES BUT THEY HAVEN'T SPONSORED A NEW VID IN A BIT. THEY DID NOT KNOW I WAS MAKING THIS VIDEO. TBH THEY PROLLY WON'T LIKE IT
Good. They need to stop flushing the VC money and fix shit.
I love file-based routing because you can very quickly find the exact file you need to edit by just looking at the path in the URL bar. The larger the app becomes the more useful this becomes.
I have a medium sized app and this already isn’t the case lmao
Eh, I remember what it was like for me in an old Vue app with all the routing in JSON. Was hard to deal with.
one simple way to improve this would be able to name the page component {anything}.page.tsx, that would solve my same issue with file-based routing
continue to find any page.tsx component but let me prepend a name to that for instance:
apps/login/Login.page.tsx instead of
apps/login/page.tsx
just a bit annoying to keep making folders and folders for a single route where react does by just creating a route
I give this video a light 9/10
Hey I'll take it
Can't wait to see how the T3 stack evolves to include server components. The type-safety and easy hydration that TRPC gives is too good to give up IMO, but I'm sure we'll have something that matches in a few months
My thoughts are that tRPC’s place in the new model is completely on the server. Using a extended version of the vanilla client that would provide the next specific caching tags to provide router and procedure invalidation. I fully agree that the type safety and router->procedure structure are too nice to ever give up, but I think now there is less of a need for the react query part.
@@whatplan4335 agree 100%
Coming from the vite ecosystem, using Next has been a major pain when developing on a 2019 Intel MacBook pro. The amount of times I have to restart the dev server because webpack straight up doesn't detect changes is baffling. I would try turbo pack but I'm using server actions so my bad I guess.
I use vite instead of next js whenever possible because of next's very slow compiling speed. The little black triangle on the bottom right is killing me.
That's fine, but these are very different things. I am not willing to give up server for faster hot reloads period. I don't see Vite as a professional tool, only as a mockup tool.
I also see Vercel right now as completely undependable. I'm not going to bet on 100 new alpa/beta products after so many broken promises.
So that leaves everything in a bit of a shit position. Personally I'm going to try out Astro and cross my fingers for a more sensible product.
@@Thorax232 it's funny you call vite a mockup tool then 5 lines later say you wanna switch to Astro, framework built on top of vite
@@CapitaineToinon I don't think you understand what the tools are.
@@Thorax232 it's a vague word to be fair, I was more intrigued by you calling Vite a "mockup" tool. What I'm understanding from that is using Vite for prototyping but not for production, which I think is absurd. Please correct me if that's not what you meant
Loved the Anthony Fantano reference, you killed it!
My favourite issue with app router is that the scrollbar does not resets after navigating to a new page
Yeah. Having the layout UI persitent is why I use it too. I'm using App Router with only client side components.
Mmm in fact, is a setting in Link component scroll={false}, it’s not something related to app or page directory
Enjoying the evolution of this channel. Reminds me of fun fun function
Been using app router in multilingual CMS driven sites now for some months and it's definitely half baked for this use case. Seems like Vercel forgot the world speaks languages other than english, localized paths are a thing and the same people also use CMSs. Creating a bunch of folders and files for each locale is a mess which is mandatory if you want to actually use all the nice things that app router provides out of the box. At least Gatsby got it right by providing programmatic routing in gatsby-node.
100% agree! The world does not only speak English. It’s so bad for this usecase. I have to handle locales clientside.
You could code in English?
As a newer developer App Directory is so much easier than when I tried to learn React..
I’m building things in hours instead of days now
Build times on Next 13 also got terribly slower, I literally had to downgrade a website that I just upgraded because builds were taking longer than 45 minutes and getting canceled. The time it takes to generate pages is way slower than 12 and this is really bad for websites with tons of pages.
45 min to build? Wow, big app?
bro is using a ps3 as a build server 💀
@@PanosPitsi KDJHASKKJASJSAJJASJASJASJASJASJAJSAJSJAS
@@vittoopugliese Big in terms of page quantity for sure. Generating thousands of static pages on build...
@@PanosPitsi Its building on vercel
Great review, exactly my concern dev performance is the issue. Rest are all valid points. Subscribed!
Content aside (awesome as usual) the colour grading is top notch 👌
Having way too much fun with luts lately
THE CROSSOVER EPISODE I DIDNT KNOW I NEEDED
Thank you for this. You answered questions i had about the new app router.
+1 for “use interactive”, way clearer!
Hurray! I was really hoping that was going to be your intro! :D
It's very informative to get your POV on this, so thank you for that.
Also, I like your shirt!
next app router is really great until you wake up one day and your entire IDE is just page.tsx, page.tsx, page.tsx...
already suffering from this
You talked about slow dev server experience, especially on Windows. I also worked on several App Router projects by now. For some I'm using an Intel MacBook, for others my WSL2 desktop. While the speed itself may be slower, from my experience the memory leak ffecting all my App Router projects is much severe. Working on my WSL2 desktop with 64GB memory is much more pleasant than on my Intel MacBook with 32GB memory. The dev server is constantly restarting because it's out of memory.
this is the most insane, niche crossover I've ever encountered on this app I swear to god.
Definitely agree with the dev mode slow experience…
Do you have a video on server actions ?
at 1:35 is probably the most effective and concise sales pitch I've heard for App Router
But the real question is, what do you give MBDTF?
Light 8
the people need to know
I think I can live with that
For me the app router development expirience is the first experience that actually feels like "full-stack" and not like doing back-end and front-end with workarounds to make them run from one single folder and ssr.
Wow, Fantano reference was sick! :D
Thanks for this review! I’d love to hear a comparison with Remix, they seem very similar
Me too
Same here. Shopify's betting their future on Remix that should say a lot
Good take on file based routing. File based routing sucks and continues to suck more as it becomes more and more complex.
Yes a perfect channel indeed ❤
Would be nice if u made a tutorial like u made for t3stack, where u build fullstack app using app router.
So updated to the official T3 dev walkthrough? Using the app router? Yes? Just say yes. Ok it's yes.
Watching 6 months later, this theo is so much nicer than current theo
Good video Theo. Thnx for sharing your insights.
holly molly, sveltte "+page" stuff is godsend, nextjs should adopt it asap
or at least make router filenames resolution customizable
Looks like the app router is awesome for creating dashboards, but what if i need SEO?
Is the page fully hydraded even when using client components? Or just the server components are hydraded before the page renders on the client?
I know client components are rendered once on the server, but I'm not sure if it will be hydraded in the first load.
Is there a way of caching an entire page ultil the next build?
Something like getStaticProps, where I can schedule the page revalidation or not. I can also set an api route that revalidates a page programmatically.
Can I get these kinds of fearures with the app router?
Yes. SEO is handled w/ , which will always be server rendered. There's also a metadata.ts file type.
Revalidation is simpler than ever, set a revalidation time on a route and you can call `revalidatePath()` whenever
Theo, would love a video on Geospatial queries in prisma, or how to get around it!
Great overview of the app router :)
Coming from someone who used many frameworks in many, many languages over the years, AND had a prod app with the new router - app router is great. It is simpler and very reminiscent of Phoenix and Symfony. It is the first time I've felt a genuine effort to resolve the client/server conflict. But i agree with the drawbacks 100%...
It took me ages to figure out the stupid client async thing. Its insane that no warnings exist, spent hours debugging weird app behaviour with it wrecking my CMS API quotas for no reason.
I've also seen some bothersome patterns with client animations and transitions, having to pass whole pages as props to client based wrappers, just to do a simple animation is not great. At all. In fact nobody knows how to do it properly - here is an idea for a video Theo :D
The file router is ok, I think that many developers misunderstand it fundamentally. I guess that comes with not ever working on an enterprise app. A large app in Ruby or Symfony would have the same pattern, but you'd see it used VERY rarely and exclusively for layouting pruposes or splitting concerns, for example admin vs lobby. Absolutely most of the time everything goes through a single app entrypoint, don't try to fight it. Regardless, Theo is correct - as the app gets larger, the intellisense does get wonky, and at one point, unusable.
I blame Next - It's actually unclear how you should set up your code. Should i keep all the components near the routes? Should I keep them all in components? How do i do loading states on components then? Super confusing.
It is very much unclear which libraries support and don't support the caching features. For example Sanity has not used fetch, and not exposed the actual http client, so you can't do caching. An alternative being that we do manual http calls, which we did. Screw them.
Same thing about "use client". Some libraries bundle their functions into the same export, and even tho you are importing a simple zeroIQ function from them, for example to calculate URL for an OG image within metadata (server only) you'd get yelled by next about how you are importing a client component, which you definitely aren't.
We need better tooling for inspecting bundle sizes. When I do yarn build, I want to know, for each page, exactly how much goes into the client and why. While something is better than nothing, currently its still a guessing game.
Netlify is not behaving properly and while they do support next 13 they have all sorts of weird side effects where you have to add env variables to control the build process. So, Vercel it is.
Love nextjs but there is definitely some things that need to be tinkered with. Better errors would be the start. Spent all day just to remove from the layout file which cause all sorts of issues.
Would love to see vercel offer “serverful” deploys to make cold starts disappear. One of the biggest negatives of serverless world
You mentioned ct3a will support app router soon, but with which libraries? Does trpc have a place here? Or now that is as easy as having an async component it's just a drizzle call inside it. What about auth?
nUxt file routing is absolutely top notch, very recommend giving that a try ;3
I'm really excited for the app router but until now I don't think it's fully supported by TRPC. I'm pretty sure that Next.js 13 App Router based TRPC integration is still experimental. Continue the great job!
intro was fire
Really appreciate this expert view. app has been a disaster for me, with errors galore in 13.4.x, had to revert back to pages for now. from an uber beginner/intermediate noob
As an early adopter trying to use next 13 and leaflet was a pain, use client is not a great name for what it is.
that Anthony Fantano shoutout was crazy
ong
After 5 years of using NextJS, it's time to give Astro a try.
BEST THUMBNAIL EVER
instalike for the video idea despite being unconvinced about app router
"Takes 5 to 10 seconds"
Oh but Theo, I used to wait 2 minutes on CRA to see if I liked how my 5px change to margin looks. 10 seconds is BLAZINGLY fast for me, lol.
Even Expo now has a filed based routing. Although, with all the performance upgrades in something like Ionic/Capacitor, I’m still not sure if I should use RN or go through a web view for my mobile app project.
I'm beginning to think that I'm the only person who actually loves file based routing.
Ask yourselves this question:
Why do I need SSR?
Why not SSG + hydration?
And choose wisely.
Mostly agree with this. Ive had to jump in head first to learn App Router for a new client, and it's mostly been a great experience. However, it absolutely wrecks my old 2017 MB Pro's memory. It's ancient so maybe I shouldn't complain, but I recently built an React app with Vite and my geriatric machine didn't miss a beat, but Next and webpack is just.so.freaking.slow.
I'm still convinced that astro's client directives make more sense than a component-level "use client" pragma. Of course that isn't possible with RSC since they decided that components that are only rendered on server are banned from even trying to use hooks. But a "use client" component is still rendering on server just like it always used to, hooks and all. Of course those hooks barely do anything on the server as state doesn't change.
Dev mode is really tired. Everytime i saved the file, the changes is taking so long. My highest time i got is 30 seconds. The turbopack break the hydration. Still recommend pages router. Maybe until turbopack is stable.
The issue: next-1143
Perhaps it will close very soon. Like the experience, just don't like the dev mode
Thanks!
fuckin lold at the fantano intro, thank you
On the point of saying its misleading to call them "use client" components, misleading maybe but what's wrongs with calling them that. They run on the server during SSR what's the problem with that? Am l missing something ?? "use interactive" is a worse name.
Noooo theo where's the rating?! 😢
(Edit: using this vid to promote your stream today is actually genius)
The only problem I have, is with Server Actions. Sounds like magic for me. Somehow I prefer Remix approach with sending data to server.
Loved the intro lol
Server component has issues. Let's say we have hero section and bottom we have some data fetching with filters. Applying filters reset page view.
Been using app router for 3 projects over the last few months and I haven't noticed any performance issues on just regular windows. Not WSL, just windows. Are you sure the M2 isn't your problem, being such a widely new and different architect?
Theo, you really didn’t need to shout the acdc “Highway to Hell” lyrics the whole review, just to prove some obscure point about programming that started to interest you all of the sudden
Agreeing on all points. It’s a mess. Started to look into alternatives since I don’t wanna go back to pages router.
App Router has great features, hopefully they would improve performance soon, but GOD please someone made something about Typescript Server I think that would increase DX even more. I know is not a Next/React only thing, but using cool packages like DrizzleORM, Zod, ts-pattern and so on is becoming imposible, you have to restart TS server at least each 20 min.
I just don't get the point of app router, any minimum amount of interactivity will make you do a "use client", for example, reacting on hover
Cache invalidation and naming things two hardest things 😆 Agree not a huge fan of "use client" but not sure about "use interactive". Being lazy I'd probably still prefer client since its a few less keystrokes (yeah, yeah horrible reason I know). I think the React team working on the RFC wasn't too happy with it either, but couldn't come up with a better one.
Also think "client" might just be a carry over from the original "*.client.js" proposal before they switched to the directive statement. I think whatever you call it still requires wrapping your head around the whole new boundary model RSC brings.
Nerd YT coming full circle - i'm here for it.
Love the intro LOL
They made is so simple they complicated everything, I think I hate it and love it.
first time i pressed thumbs up 2 seconds into the video (at the moment u said webthony devtano)
I use useTransition or rather startTransition to execute server actions in callbacks rather than in forms.
What amazes me is many of these features are in Nuxt 3 / Vue 3. We've had them for some time, like layouts/folders routing, server components, fetching inside components etc. Even React Query now looks a lot like useAsyncData in Nuxt. Well, I'm glad React users are finally seeing the light.
I liked dimished bright, it's a dark-mode-video like
i've had a very weird issue with app router that forced me to go back to pages. there's loading.tsx fallback file which displays while page.tsx is being loaded and sent back to the client. i was writing client side filters which are synchronised with url query parameters so i used useRouter and .push method to change those parameters. but app's useRouter.push doesn't have {shallow: true} so every time a query parameter is changed, it requests page.tsx to load data again. and it's actually fine, no need to fetch data from client side with react-query or useSWR. but the problem is that it does not trigger loading.tsx so every time i selected new filters, the page was stuck for like 2 seconds while the new data is being rendered. i ended up rewriting that logic with pages router, react-query and getServerSide props for initial load of the content
Will you do a classic review?
I've been stressed out throughout the video that one speck of hair was going to get in your eye. couldn't understand what the video was. glad if it works for you sorry if it doesn't.
WOOO, a check shirt!!! WTF Theo
Oh excellent. Yet another way to do the same thing but differently.
WEBTHONY MOTHA FLACKIN DEVTANO!!!! 😂❤ I love this so much.
S Tier thumbnail
I give this video Light 8.5/9
Why u didnt mentioned the BIGGEST problem - server cache! Nothing is working there. Gives us old data even tho we want it to refetch on server on each request…
👏👏👏👏
My windows machine is way faster than my M2, so that point about it being slow on intel/Windows machines kinda struck a nerve 🙃
M2's also get super hot on random operations.
On the subject of cold starts: what's the deal with the "cold boot duration" in the logs being ~150ms and the actual execution time being ~3s!? Surely I'm not the only one experiencing this?
Trying to use app router in new project but stucked at cache problem. How do you solve the cache problem when use next/link. The soft navigation always use client side cache and no way to disable this behavior except ugly router.refresh()
i've been so used to t3-app that i don't even want to switch to the app dir
The performance thing is rough, but that issue is more attributed to usage overtime. I get near instant updates on webpack but the more I use it, the slower it gets so I need to restart the server and it's fine again until it isn't. Very annoying but I wouldn't say it's a big deal as long as I can restart to fix it. Definitely would rather not have to do that though but e already got the Typescript server restarts in rotation, what's one more? lol
FYI, I don't use turbo, but was planning on giving it a try but from the sounds of it, probably better not for now.
I dont even see the change when using page router. Hell my ’next dev’ doesnt even compile the pages, it just freezes
Typing “use client” in most components isn’t a good dev experience. Wouldn’t it be better to let the developer define the default behavior in the config? I would rather write “‘use server” in 10 server components than “use client” in 100 client components.
…I’m thinking I’ll just stick with a good old React SPA and API for now..
Hahah great intro reference
Now I wanna know what your favorite albums are
Maybe I do my bachelor thesis about server components. But I am still a bit unsure.
Is there really any issue with dev server performance? Windows user here with okeish CPU and despite some random undetected changes from time to time I haven't experienced any issues
HAHA loved the fantano intro
Well as a developer using t3 stack a lot, I still haven't used the app routing and I don't think I will start using it in prod soon, just have this bad feeling about it, as when it was presented I started testing it and all I got was errors, errors, infinite loops because of useEffect in 'use client' and so on. So Theo, give me an advice, should I start using it, would it affect the t3 stack usability. Anyways, amazing video as always, but where is the kitty?