I was going to title this video “why next.js is still king”, but as I was recording I was reminded about the annoying caching behaviors the developers need to wrap their mind around and decided to change the title 😂.
I create my own project structure. I will not change even nextjs change. Because i need consistency across my projects i use src/app/dashboard /src/app/frontend
but isnt if u developed enough static website/SPA, u put cache function to api layer or cloudflare (proxy or gateway level). Why you guy put so many stuff for reinvent the wheel...if u want to replace the wheel and move to Front end layer (to secure your job or increase your job workload)....might as well to architecture the solution well
Definitely think we can make caching easier (working on it actively!). A couple thoughts here: - When using Server Components, you don't need to have the Route Handler. You can call that function/Promise directly. Route Handlers are kind of the escape hatch if you're using RSC, only really needed for one off things like listening for webhooks for example. - Route Handlers are unique, and not 1:1 with API Routes from Pages Router, so the mental model has to change a bit. Notably you could also make it a POST, or read anything from the request, and it's dynamic. The use case of trying to return things with a GET is largely replaced by calling that logic directly from the RSC. And if you are like "ah I hate this, I preferred API Routes" - you can still use those! - You said "I think this is the dumbest thing ever [caching Route Handlers], why would they do that?" - the main opportunity here, and a large request from Next.js users of API Routes, was the ability to be able to generate static files programatically, and incrementally update those files. For example, you could have a Route Handler that generates a txt, json, xml file, or similar. And you could generate this during the build process, which means it works when you use a static export which can be hosted anywhere. This is huge for some people!
I guess in regard to many of your points, I’d always expect opt in to caching, but I’ve said my peace 😂 thanks for responding and leaving your suggestions!
The fact that guys like Lee put so much effort into engaging with the community and addressing peoples' concerns directly is just one reason I'll keep using Next.js as my framework of choice. I don't see any other team, let alone any other CEO, doing anything like this.
Well that 1% maybe brings them the most money, who knows. I'm quite sure they use telemetry heavily and talk to customers to see what they need to implement. They probably don't go and implement stuff randomly. I of course don't agree with everything they do, but cannot deny that next.js does serve me really well.
@@rand0mtv660 I mean the whole caching and ISR stuff for public pages is just a Vercel scam anyway. Just put cache-control headers on the pages you want to publicly cache and a stale-while-revalidate header. Why would I need ISR when a proper CDN can do that for me? Whole thing just feels off. This has been a solved problem for some time. Again Vercel is inventing new ways to solve a problem that doesn't exist so you pay for storage.
The more i look into the general developer space, I can safely say that their two kinds of devs, those who prefer "freedom(optionality)" and those who prefer "opinion" and this widly affects their DX. this has strongly helped me with picking a stack im more comfortable with because once im able to classify a said technology, I can then already predict my DX with it. It is a spectrum obviously on what is "opinionated" and what is "freedom" but generally, I've grown to appreciate technologies that have a clear way this should be handled but if you do choose to deviate from the norm, we can still somewhat accommodate you.
I like frameworks that lean more towards the opinionated side as long as it doesn't make the DX tedious. An example of this is with Laravel which is very opinionated, but the DX is quite nice. An example of the opposite is Angular. Still very opinionated but the DX is very tedious.
The more experience I have, the more I lean towards "built in opinion", but up to a certain point. Angular might be a bit too opinionated for me, but React might be not opinionated enough. I dislike "everything is opinionated" approach because that usually means going outside of the prescribed patterns is hard and frustrating. I guess I would like something in the middle. I like when some things are built in so that they just work better with the framework and are prescribed by the framework. For example, I would love if React had an official styling solution instead of all the css in js abominations we had in the last 10 years. I would also love if it had animation primitives for easy animations so that we don't have to rely on 3rd party solutions most of the time.
Yes and there is a learning curve, albeit of a different kind, with each approach. I disliked angular because I hated learning writing something 'the angular way' and was initially attracted to react for that reason. But after so many years, there is definitely a react way to do things now. So react has swung closer to the middle of that spectrum. You still get to chose your meta framework, router, etc and there is a different kind of learning curve there but I prefer this type of learning curve because it feels like I have more control and optionality.
@@alastairtheduke Here is how I see it though. An example of a very flexible api would be to just use express. You can then organize the code however you want, however, at some point you will create your own rules about how you will organize everything. So the difference just comes down to whos opinion it is. Some frameworks come with their own opinions, and others require you to make up your own. But sooner or later there will always be an opinion because it helps to make the code either readable, maintainable or both.
For me personally Nextjs 13 has been a godsend. It was so hard to build full stack apps managing and connecting my own server and deploying both parts.
It soo hard to deploy it, recently i just trying to deploy my project to azure its soooo complecated while in vercel is just a click of a button and hate it
@@WebDevCody i use a postgressql for my database and prisma orm, idk what exactly the problem is, but in vercel wether our app is just a static website or dynamic when we deploy it it just work, but on azure there is some kind of like azure function and azure static web app(Image optimization won't work), and i should configured it differently. Recently i found a framework called nitro, that promising zero config on deployment, i think it will solve al the deployment complexity, m considering to contribute to this project, maybe a video for it?
@@WebDevCody I'm also working on a next.js site deployed to Azure, and it has been a huge chore learning how to deploy to Azure. AWS and GCP are the same, but my problem with these cloud platforms from giant companies is that they have a million different services and it's so hard to find the right ones. You have to wade through all the marketing material that is often misleading, and most of the time I have to actually try a service before I know how it works(who has time to try all of them?). Then I also had to learn docker, because Azure's Web Apps for Linux with direct code deployment is either incredibly slow to deploy or deploys to a read-only folder which breaks next.js caching. Yes if you already use all these things then maybe you can make it look easy, but I don't know how you make sense of it all when you don't know anything about it and don't have other people to tell you... other than just painfully spending a whole lot of time on it. Even after deciding to use a docker container deployment, Azure has a bunch of different services to deploy containers: Web Apps for Linux (container deployment), Web Apps for Containers, Container Instances, Container Apps, and Kubernetes... not to mention when you google this stuff you often find articles references services that Microsoft has renamed or changed significantly. And then there are a bunch of different ways to set up CI/CD... Github Actions, Azure DevOps/pipelines, azure cli... and some of their docs use one CI/CD method and don't show other methods. It's been such a pain to just figure out what all these different services are.
Don't forget Next.js is primarily a static pages generator, not an API builder, so everything is made to save processing, that is why static and caching is always the default.
9 หลายเดือนก่อน +1
You have a nice and concise style of educating. Seems like you didn't know for sure where the video was going until you finished, which is very genuine. - I think the App router was not only published for incremental adoption, but also published incrementally, at the beginning the feature seemed almost experimental, so I think incremental adoption was the only sane move from the team to make. - It's a good thing that you mentioned that Next.js doesn't know handlers in app/api are handlers like any other, unlike in the Pages router, I wasn't aware of the caching issues! - Regarding exporting the revalidate variable from the page, I think that's healthier to achieve with a Cache-Control header because the exported variable is a Next.js feature, while headers are a transferrable web development feature. I've been following and trying out Remix for quite a while, and I'm looking forward to trying it out on a serious project, because I tried like 4-5 different major versions of Next.js and the framework just isn't for me. I feel like Next.js is making decisions for me and telling me not to worry about it, and when something isn't working, I don't know enough to solve it. I'll still work in Next.js projects if I have to, it's the industry standard, after all, but Lee popping up every time someone dislikes Next.js communicates to me a certain insecurity from the team.
I feel like criticism is often responded with a “you just don’t get it” or “just read the docs”, instead of a “hmm maybe this isn’t intuitive”. Every great tool is intuitive. If I need to read tons of docs to use it properly it’s poorly made imo.
I like how similar to tailwind, third parties often give examples of how to work with next or even provide adapters. It’s such a big part of the ecosystem. I can’t say the same of other frameworks. It’s pushing the boundaries and taking feedback from the community.
Those concepts makes Next.js currently really hard to dive into. I also find no good documentation about all this weird stuff. That's why I switched to vite for SPAs. Thanks for your video, cleared up a lot of things, great as always! Best React/Next.js YT channel out there 👍
I am interested in how Remix pissed you off to switch back to Next, because everything that you showed in the first part of the video is doable in remix as well!
Yeah, this! Since the page is async and can await any promise, you can just call whatever async logic you put in your Route Handler directly inside the Server Component. You don't need the extra network hop.
@@WebDevCody it's a mistake regardless, I stumbled upon it once, there's a nextjs' GitHub issue about this common mistake where they explain in detail why this should never be done. If it's a RSC just call the function directly, the api route should only act as a controller not the whole function
This is where I have used TRPC to get around some of these thoughts between server and client calls. It makes it easy to swap between a client and server component. It is minimal changes most of the time
@@WebDevCody You can't have both. Just pick the one you want to use and design your app around that. Make a regular javascript API client class to handle your requests and use that in your RSC. Or, if you want client side components, the api route handlers are a great implementation to standardize things that you would normally need a dedicated package like useSWR or react query to do well at a professional level.
I would have to agree with you on this. It has always been my concern with Next. It sort of is a big machinery with built in magic. You need much time to see why it works a certain way and is a pain if you want to deviate from their idea of how a website should work. It is also one of the main reason I consider more and more using Astro for production project as it have more of an opt-in paradigm. My only concern is with the "lack" of real world project in the space.
Don’t get me wrong, I appreciate the hard work they or into this; caching isn’t easy, but I’d also appreciate if they let me opt into the complexity when I want it and not always use it by default. A simple next.config setting to default to no caching for anything would be appreciated, then I can add caching to fetch requests, components, or pages as needed. Every app I’ve worked on involves highly dynamic data, so caching isn’t my first go to
@@WebDevCody yea I would agree opting in would be better as a whole for everyone. I just like how they make things as performant as possible. Bc I bet there’s a really small percentage of non professional next devs that have fully read through the caching docs.
I guess since Vercel knows they are gonna do most of the hosting, they would prefer some heavier caching by default. If it was purely opt-in devs would forget it in a lot of places with big consequences for their compute capacity.
I’m not sure why that is an issue if vercel charges per usage anyway. I think no matter which way you do caching, people are going to mess it up. Opt out and people accidentally ship bugs that break real users experience because stuff is cached and users don’t see the latest version of data; opt in and websites will be slower and people will complain nextjs is slow (bad for marketing). I personally would rather it be slow and show the right data every single time. One approach is obvious why the website is slow, the other is not obvious why stuff isn’t refreshing until you read their giant documentation about caching and their diagram about how it works.
I too use nextjs and sprinkle "use client" everywhere. My favorite features are the app router and the ability to nest the folder tree to accommodate different layouts using "()"in the name of different layout groups. The dynamic tag and image tags are also nice features.
Okay let me give you a little context here. This video is actually giving the most important warning ever about NextJS. The other day I was playing around with Supabase and since I didn’t want to send my key over the browser, I created a server component to fetch the data from a table and then deployed. After few days I’ve deleted the database but my app was still displaying data from the table! WTF?! I was almost blaming Supabase for leaving a zombie database and instead the problem was the caching system of NodeJS!! So that’s why this video is gold and should be mentioned as a warning on EVERY tutorial about NextJS.
I hate both react and next.js with a passion. Whoever thought of porting JS to the back end seriously did not consider how complicated projects can get and how easily you can mess them up when they get really big even if you are using TS.
@@WebDevCody The way you explained optionality in depth really hit the point home how it doesn't belong. I'd love to hear what made you go back to nextjs from remix. Still deciding which one to spend my time in with hobby projects 😅
@@Snoodelz I have nothing against remix. I’m just so invested in next right now that jumping between remix and next projects slows me down. I know I talk bad about caching in next but I do think next has more features you can opt into compared to remix, and I don’t like remix approach to server actions.
after react server actions and long nights of thinkering i decided to leave react/next world unless there is a good reason to use it. i started web dev with django 1.x and after a decade i am returning back to python and django with htmx or equivalent django packages which are very cool. included orm of django, authantication and authorization is much simpler and much powerful, further more admin panel is included in django which is higly customizable by only writing 15-30 lines of code (i don't wanna even mention packages that make it super cool). I'll continue developments in node.js but i don't see any reason to use next.js/react anymore (unless there is a reason).
Django was nice, but I'm not a fan of dynamic languages anymore. I find typed languages provide a MUCH better developer experience and let you move much faster. But I won't lie, I've seen some django developers code and they can crank out features pretty fast
@@WebDevCody i agree typed langs provide better tooling however in django you actually dont need them as much as you need them in typescript. just created a new vs code profile for python / django and it actually works like as i was used to. i don't wanna sound like trying to digress people from their path but i am pretty ok with python auto completions and suggestions in vs code. (btw as you know python has optional types which makes tooling alot better than before.)
The opt out caching was a horrible decision but otherwise all the new stuff is great. The biggest issue they have now is not so much how it works but how they make it easier (for inexperienced devs especially) to understand. I'm intergrating next as work currently and I dread the day I have to explain this stuff to them. Maybe I'll just send them a link yo your channel instead 😅
@@WebDevCody haha i need to start thinking about its inner workings of whats going on instead of going to chatgpt and posting all my code only to ask it to rewrite it to make it work.
So to clarify if I was using nextjs with apollo client and graphql for example, puting fetch policy to "no-cache" I would still get it cached by default in nextjs? I feel for the case of projects using graphql fetch policy shouldn't nextjs caching have a way of following the fetch policy in the graphql resolver hook? The edge case for verifying user email with it being cached by nextjs by default if you were doing your own verification does have some concerns for me even if you have graphql fetch policy as "no-cache". From the Vercel company perspective it makes sense to have it default as your potentially saving to make multiple calls from the server at the start of a project's inception. Maybe there will be iterations to incorporate this perhaps
got something for you: export const dynamic = 'force-dynamic' just figured if you want to cache within those dynamic pages you have to force store them with this: export const fetchCache = 'force-cache' check out the nextjs docs force-dynamic and force-cache, espeically it not caching on force-dynamic is a rather hidden infromation...
Mantine should work with SSR without any special configuration. The mantine components should have built-in "use client" so you can use them in server components.
What jonny555333 said, but also in general anytime you're having an issue with needing client functionality in a server component, just wrap the client-side code in its own component and set 'use client' at the top.
Would you be open to doing a video on visiting more modern angular? I wasn't aware you had been in angular before. I'm very curious how you would feel about the direction they've been going.
just wanted to quickly give a feedback regarding your new thumbnail style... i don't really enjoy them, they feel really clickbaity now. but i really enjoy your content and hope you'll continue! and if that's what it takes to grow so be it ;)
The problem with the React/JS community, it's so opinionated there isn't true best practice and everyone wants to be right, then change their minds every hour of the day lol.
Nice thumbnail! And yeah, agreed. I keep coming back to React. I'm now trying out Go and it kinda feels the same, I think. Or at least the community seems to be like that.
This came at a time when I am already frustrated with React after 1 year of learning I still couldnt finish learning the whole ecosystem... then I looked at svelte bcz of all the hype but am now stuck again. I might as well just go full python and ai like this. I hate front end lol
LEARN Go, switch to backend/systems. Felt like I became an "engineer" once I learned and used it, it scratched the itch of my curiousity. I was in the same boat but pivoted to remix after learning nextjs for good months, I mean remix was actually good (will continue to use it along with Vite React for UI with Go backend) but seeing how simple and exquisite Go is and its capabilities, my man I was HOOKED. Been playing around cloud/tooling/devops/cli/backend servers with Go for some time now, I think I finally found my niche.
Particular Next.js behaviors might seem annoying, but long as one goes through the docs (their "Learn" course is very thorough) you'll be fine and won't fall into one of their annoying behaviors :p
Because I already have too many projects in next and I see little benefit to switching. I can just add export dynamic = force-dynamic on all my pages and all my problems would go away 😂
Problem with Angular's "batteries included" approach is just that, low optionality, one bad apple spoils the bunch. I deliberately do not use *ANY* Angular features that returns observables because RxJS is just a nightmare and it's almost inescapable. Hopefully Angular will see a new day with signals but idk.
Rxjs is not a nightmare. It can be hard to understand at first, but once you understand the fundamentals it’s a powerful tool that lets you get fine grained control of your data flow.
@@colinb8332RxJS is overkill for 99% of applications. It has very specific use cases, but defaulting to RxJS for the most mundane tasks is just insane.
@WebDevCody - You forgot to mention most frustrating thing about caching. About SOFT navigation, the noStore() and none of the other options actually work either...(For the first 30 seconds after entering the page.) they have set RSC payload to be be cached by default for 30 seconds and we as developers doesnt have a change to opt-out of it...
@@WebDevCody But you r kinda big now on youtube for them to respond to your opinions. Evn LeeRob are commenting your video :) You have the pover to bitch about things till they fix ;)
@@iPankBMW 😂 at the very least they can watch someone else struggle with something they might find intuitive. If I’m struggling with it, I’d bet money others are as well
Been playing around with v14 and having a mish mash of server and client components seems like it's going to be a nightmare in a big project. Data fetching happening deep down in the component hierarchy in order to get suspensed components... React just by itself is hard to debug and prone to spaghetti since they introduced hooks, now this... I don't know, foreseeing a big industry migration away from this. I'm not the only one tired of having to relearn the framework every 6 months because the new version solves problems that don't exist in 99.9% of apps.
Hi Cody, I am kinda newby about using next. I have a problem with state management on next. Assume that we have a server component and fetch some data in it. How can we store that data for the using all other pages even if these are server or client comps. Server and client components can store same data with state management libs but its feels tricky What do u think about that?
Am I misunderstanding it but don't you achieve the same result by just typing export const revalidate = 0 ? to make the page not store cache but run dynamically.
Yes that gave multiple ways to make the endpoint dynamic, include export const dynamic = “force-dynamic” or using noStore. Their docs recommend using noStore over exporting the dynamic const. Revalidate = 0 will also work from what I understand.
I've tried starting my projects in Nuxt3 many times, but I always end up going back to React and Next, primarily because their ecosystem is so robust. In every project, there seems to be at least one essential package for which only a React SDK is available :(
I remember you said a few videos ago that creating thumbnails for the videos takes time so you don't do it, and I was thinking "it can probably be done quickly enough and would probably get the channel more clicks". But then I thought "who the f am I to say anything, I can barely call myself a programmer, let alone tell someone anything about how he runs his successful TH-cam channel". So I'm genuinely curious: what made you decide to create one for this video? Is it an experiment? Did you find a quick way to do it and thought it's worth a shot?
i've been making projects in react for 5 years and i was so excited to try out nextjs in my current project and after we were at the halfway of the project nextjs is so irritating that it has lots of downsides so i had to convert all the project to reactjs again. i've never use nextjs again. just use a backend framework for the backend. never try to make a whole project in a single app.
I've been thinking about the best way to handle this. Thinking server side for the main landing pages. Server actions for the login. And then reacts query for everything else
Next js a weird mvc pattern i call CBA, content based arch, its a mess in my opinion, eventhough i like it a lot and im still discovering next js, i wish it was better
it's totally tiring to debug code for two hours to see it's cached and you are not insane. I wish there was an easy indicator that shows something like "this content is cached"
That argument can be made for anything that feels complicated. “Skills issue” isn’t the right response when valid criticism is given for a library or framework; maybe the framework is just a bit too complex?
I think the app router it is kind of a mess, I don't really like it, it causes packages error. etc, I've tried many times, but sitll end up using pages router. Please Nextjs if you see this focus on the pages router add more features to it just like App router has. I love using nextjs I don't want to move to other framework😥😥
Great and informative video, like always. I do have to say I'm less than impressed by the thumbnail. It feels a bit clickbaity and reminds me of the ones from another tech youtuber that seems to only do that.
Sad you have such a nialistic mide set about next js. I understand your sentiment however next js is the tip of the spear among all javascript frameworks. If you are weary about learning and staying up todate with new tech and practices then just use html css and javascript
20 minutes Just to say that you dont like the cache by default. Well, i agree that this needs to need off by default, but dont use NextJs jus because of it? Makes no sense to me. And some things there you just don't understand how to use.
I mean the video was more to explain how next does things pretty nice for the most part and it is a walkthrough explaining some main concepts. If you wanted me to say I don’t like caching on by default my video could have been a tweet, but that’s not how TH-cam works 😉 also I never said don’t use next. I literally said I keep coming back to next because it’s the best option imo. Absolutely there are things I don’t 100% understand about next, but that’s also the point. Nothing is very straight forward and that leads to a bad DX.
@@WebDevCody Maybe the title of the video and the purpose of it don't match with what you are trying to pass. But it's like you said, it's how youtube works. Thanks for the attention.
I was developing a dashboard for a project and never found the problem of why invoices dind't refresh with new data, after some time I discover the default caching by a video, but what a pain to be hours staring at my screen with no reason of why that happend when in development worked just fine
This is unfortunate. I was looking forward to experimenting with RSC with Next but opt-out caching is a HUGE footgun. I guess I'll have to wait for other RSC implementations
I feel like you're overstating your point by saying that it's not a good framework when the only things that you dont like are the default caching settings.
I have to say that criticizing all the default caches is understandable because they have a decent learn curve and you have to read through the docs thoroughly to understand them all. Having said that it is my opinion that it's better to force devs to "fix the cache bug" (not a bug, just your skill issue), than letting thousands of unoptimized NextJS projects all exist without any caching solution. If this was a library, I am 100% for cache being "opt-in", but since this is supposed to be a complete framework which is highly opinionated, I think that caching by default is reasonable. So I will pull a Primeagen here and call this a "skill issue" for anyone that refuses to learn the framework properly and opt out of the 3 different caches implemented by the framework when necessary. I know it is a controversial opinion, so flame me.
I would agree if it were not for the fact that these caching issues WILL affect your users. But yes, learn how to use Next.js and it won't be an issue; that argument can literally be applied to anything, but it doesn't negate the fact that it's still a real issue for many. I literally have code deployed right now using next that never updates because I set the cache to 24 hours and for some reason Vercel just doesn't update the page. I had to change the cache down to 1 hour to get vercel to actually re-compute the page. These are reall issues that real devs struggle understanding, and if the hosting company who made next.js can't get it right, why would we?
@@WebDevCody that case is inexcusable indeed, they should get it right before advertising it as a product. I know it's not your case, but I feel like way too many people want to make value judgements about frameworks and libraries without fully understanding them, and that sometimes frustrates me. The day I made this comment was of them. I apologize if I came across too harsh.
@@luizgrocco I just like to complain when I’ve wasted an hour developing because of simple mistakes, and my complaining generates views. 😂 no worries thanks for the comment.
I was going to title this video “why next.js is still king”, but as I was recording I was reminded about the annoying caching behaviors the developers need to wrap their mind around and decided to change the title 😂.
I create my own project structure. I will not change even nextjs change. Because i need consistency across my projects
i use src/app/dashboard /src/app/frontend
Still great video.
but isnt if u developed enough static website/SPA, u put cache function to api layer or cloudflare (proxy or gateway level). Why you guy put so many stuff for reinvent the wheel...if u want to replace the wheel and move to Front end layer (to secure your job or increase your job workload)....might as well to architecture the solution well
@@2dstencil847 I've worked enough to know that there is no silver bullet and no wrong solution. Only tradeoffs. There is no black or white.
Definitely think we can make caching easier (working on it actively!). A couple thoughts here:
- When using Server Components, you don't need to have the Route Handler. You can call that function/Promise directly. Route Handlers are kind of the escape hatch if you're using RSC, only really needed for one off things like listening for webhooks for example.
- Route Handlers are unique, and not 1:1 with API Routes from Pages Router, so the mental model has to change a bit. Notably you could also make it a POST, or read anything from the request, and it's dynamic. The use case of trying to return things with a GET is largely replaced by calling that logic directly from the RSC. And if you are like "ah I hate this, I preferred API Routes" - you can still use those!
- You said "I think this is the dumbest thing ever [caching Route Handlers], why would they do that?" - the main opportunity here, and a large request from Next.js users of API Routes, was the ability to be able to generate static files programatically, and incrementally update those files. For example, you could have a Route Handler that generates a txt, json, xml file, or similar. And you could generate this during the build process, which means it works when you use a static export which can be hosted anywhere. This is huge for some people!
This is something that I love about the Vercel team is that your team responds back. Keep up the good work Lee
I guess in regard to many of your points, I’d always expect opt in to caching, but I’ve said my peace 😂 thanks for responding and leaving your suggestions!
@@itsyourboyt4683 fr my man is one man army, you can see him in almost every nextjs post :D
The fact that guys like Lee put so much effort into engaging with the community and addressing peoples' concerns directly is just one reason I'll keep using Next.js as my framework of choice. I don't see any other team, let alone any other CEO, doing anything like this.
@@neilmerchant2796 well that is Lee's job after all and he is doing a good job!
SvelteKit. It's all I ever need. No weird pseudo-functionnal programming conventions. No bullshit. Straightforward code.
Next is too focused on the 1% use case. Most people are using this to do dynamic sites.
Well that 1% maybe brings them the most money, who knows. I'm quite sure they use telemetry heavily and talk to customers to see what they need to implement. They probably don't go and implement stuff randomly. I of course don't agree with everything they do, but cannot deny that next.js does serve me really well.
@@rand0mtv660 I mean the whole caching and ISR stuff for public pages is just a Vercel scam anyway. Just put cache-control headers on the pages you want to publicly cache and a stale-while-revalidate header. Why would I need ISR when a proper CDN can do that for me? Whole thing just feels off. This has been a solved problem for some time. Again Vercel is inventing new ways to solve a problem that doesn't exist so you pay for storage.
The more i look into the general developer space, I can safely say that their two kinds of devs, those who prefer "freedom(optionality)" and those who prefer "opinion" and this widly affects their DX. this has strongly helped me with picking a stack im more comfortable with because once im able to classify a said technology, I can then already predict my DX with it. It is a spectrum obviously on what is "opinionated" and what is "freedom" but generally, I've grown to appreciate technologies that have a clear way this should be handled but if you do choose to deviate from the norm, we can still somewhat accommodate you.
I like frameworks that lean more towards the opinionated side as long as it doesn't make the DX tedious. An example of this is with Laravel which is very opinionated, but the DX is quite nice. An example of the opposite is Angular. Still very opinionated but the DX is very tedious.
Exactly my thoughts and why I learnt Flutter
The more experience I have, the more I lean towards "built in opinion", but up to a certain point. Angular might be a bit too opinionated for me, but React might be not opinionated enough. I dislike "everything is opinionated" approach because that usually means going outside of the prescribed patterns is hard and frustrating. I guess I would like something in the middle.
I like when some things are built in so that they just work better with the framework and are prescribed by the framework. For example, I would love if React had an official styling solution instead of all the css in js abominations we had in the last 10 years. I would also love if it had animation primitives for easy animations so that we don't have to rely on 3rd party solutions most of the time.
Yes and there is a learning curve, albeit of a different kind, with each approach. I disliked angular because I hated learning writing something 'the angular way' and was initially attracted to react for that reason. But after so many years, there is definitely a react way to do things now. So react has swung closer to the middle of that spectrum. You still get to chose your meta framework, router, etc and there is a different kind of learning curve there but I prefer this type of learning curve because it feels like I have more control and optionality.
@@alastairtheduke Here is how I see it though. An example of a very flexible api would be to just use express. You can then organize the code however you want, however, at some point you will create your own rules about how you will organize everything. So the difference just comes down to whos opinion it is. Some frameworks come with their own opinions, and others require you to make up your own. But sooner or later there will always be an opinion because it helps to make the code either readable, maintainable or both.
For me personally Nextjs 13 has been a godsend. It was so hard to build full stack apps managing and connecting my own server and deploying both parts.
It soo hard to deploy it, recently i just trying to deploy my project to azure its soooo complecated while in vercel is just a click of a button and hate it
What’s hard about deploying it? Just run npm run start and you have a next app working on a vm. Now… if you’re trying to get feature parity, good luck
@@WebDevCody i use a postgressql for my database and prisma orm, idk what exactly the problem is, but in vercel wether our app is just a static website or dynamic when we deploy it it just work, but on azure there is some kind of like azure function and azure static web app(Image optimization won't work), and i should configured it differently. Recently i found a framework called nitro, that promising zero config on deployment, i think it will solve al the deployment complexity, m considering to contribute to this project, maybe a video for it?
Exactly, combine that with nginx and pm2 and you don't have to worry about it anymore@@WebDevCody
@@WebDevCody I'm also working on a next.js site deployed to Azure, and it has been a huge chore learning how to deploy to Azure. AWS and GCP are the same, but my problem with these cloud platforms from giant companies is that they have a million different services and it's so hard to find the right ones. You have to wade through all the marketing material that is often misleading, and most of the time I have to actually try a service before I know how it works(who has time to try all of them?). Then I also had to learn docker, because Azure's Web Apps for Linux with direct code deployment is either incredibly slow to deploy or deploys to a read-only folder which breaks next.js caching. Yes if you already use all these things then maybe you can make it look easy, but I don't know how you make sense of it all when you don't know anything about it and don't have other people to tell you... other than just painfully spending a whole lot of time on it. Even after deciding to use a docker container deployment, Azure has a bunch of different services to deploy containers: Web Apps for Linux (container deployment), Web Apps for Containers, Container Instances, Container Apps, and Kubernetes... not to mention when you google this stuff you often find articles references services that Microsoft has renamed or changed significantly. And then there are a bunch of different ways to set up CI/CD... Github Actions, Azure DevOps/pipelines, azure cli... and some of their docs use one CI/CD method and don't show other methods. It's been such a pain to just figure out what all these different services are.
*src path doesnt exist for some reason*
normal image: ok im good
NextImage: IMA BROKE YOUR BUILD AND GIVE RED ERROR FULLSCREEN
exactly you piece of hotdog, how dare you providing unexisting src
Don't forget Next.js is primarily a static pages generator, not an API builder, so everything is made to save processing, that is why static and caching is always the default.
You have a nice and concise style of educating. Seems like you didn't know for sure where the video was going until you finished, which is very genuine.
- I think the App router was not only published for incremental adoption, but also published incrementally, at the beginning the feature seemed almost experimental, so I think incremental adoption was the only sane move from the team to make.
- It's a good thing that you mentioned that Next.js doesn't know handlers in app/api are handlers like any other, unlike in the Pages router, I wasn't aware of the caching issues!
- Regarding exporting the revalidate variable from the page, I think that's healthier to achieve with a Cache-Control header because the exported variable is a Next.js feature, while headers are a transferrable web development feature.
I've been following and trying out Remix for quite a while, and I'm looking forward to trying it out on a serious project, because I tried like 4-5 different major versions of Next.js and the framework just isn't for me. I feel like Next.js is making decisions for me and telling me not to worry about it, and when something isn't working, I don't know enough to solve it.
I'll still work in Next.js projects if I have to, it's the industry standard, after all, but Lee popping up every time someone dislikes Next.js communicates to me a certain insecurity from the team.
I feel like criticism is often responded with a “you just don’t get it” or “just read the docs”, instead of a “hmm maybe this isn’t intuitive”. Every great tool is intuitive. If I need to read tons of docs to use it properly it’s poorly made imo.
I like how similar to tailwind, third parties often give examples of how to work with next or even provide adapters. It’s such a big part of the ecosystem. I can’t say the same of other frameworks. It’s pushing the boundaries and taking feedback from the community.
I have to agree that building with react-query is a joy
Those concepts makes Next.js currently really hard to dive into. I also find no good documentation about all this weird stuff. That's why I switched to vite for SPAs. Thanks for your video, cleared up a lot of things, great as always! Best React/Next.js YT channel out there 👍
I agree, I heard about all these things before, but not until this video did all the options in nextjs make sense finally
Now with Remix 2.5 version we have SPA mode :D and it's work on Vite.
I am interested in how Remix pissed you off to switch back to Next, because everything that you showed in the first part of the video is doable in remix as well!
Thank you for explaining that in great details! We need more vids like this ❤
As an VueJS developer, I just came here to read the comments 😂
You can't call an api route from a server component, it's the server calling itself
Yeah, this! Since the page is async and can await any promise, you can just call whatever async logic you put in your Route Handler directly inside the Server Component. You don't need the extra network hop.
But maybe I want a traditional rest api but also want to use RSC?
@@WebDevCody it's a mistake regardless, I stumbled upon it once, there's a nextjs' GitHub issue about this common mistake where they explain in detail why this should never be done.
If it's a RSC just call the function directly, the api route should only act as a controller not the whole function
This is where I have used TRPC to get around some of these thoughts between server and client calls. It makes it easy to swap between a client and server component. It is minimal changes most of the time
@@WebDevCody You can't have both. Just pick the one you want to use and design your app around that. Make a regular javascript API client class to handle your requests and use that in your RSC. Or, if you want client side components, the api route handlers are a great implementation to standardize things that you would normally need a dedicated package like useSWR or react query to do well at a professional level.
These were great examples to show all of these features. Good thumbnail btw
Tbh I really think they built the cache sh1t by default to save theirs resources as much as they can (even tho we are paying for this)
they're the ones paying for the free tier
Going through a lot of use cases, pros and cons. Thanks, quite useful!
Almost didnt notice new video due to custom thumbnail :)
👀
I would have to agree with you on this. It has always been my concern with Next. It sort of is a big machinery with built in magic. You need much time to see why it works a certain way and is a pain if you want to deviate from their idea of how a website should work.
It is also one of the main reason I consider more and more using Astro for production project as it have more of an opt-in paradigm. My only concern is with the "lack" of real world project in the space.
Yeah, Next.js is a lot more like angular in that way but that's the whole idea behind a metaframework
Use Remix instead is awesome!
Astro is for static websites, not webapps I believe
@@skyhappy Not really, it does also supports complex patterns
SolidJS is a game changer, I hope everyone ditches Next for it.
Does it do ssr?
I did after seeing next 14 blocking css styles from external components while it was ok in 13
Reading through the caching mechanisms fully and thoroughly you’ll get to appreciate the way they’ve done things.
Don’t get me wrong, I appreciate the hard work they or into this; caching isn’t easy, but I’d also appreciate if they let me opt into the complexity when I want it and not always use it by default. A simple next.config setting to default to no caching for anything would be appreciated, then I can add caching to fetch requests, components, or pages as needed. Every app I’ve worked on involves highly dynamic data, so caching isn’t my first go to
@@WebDevCody yea I would agree opting in would be better as a whole for everyone. I just like how they make things as performant as possible. Bc I bet there’s a really small percentage of non professional next devs that have fully read through the caching docs.
I guess since Vercel knows they are gonna do most of the hosting, they would prefer some heavier caching by default. If it was purely opt-in devs would forget it in a lot of places with big consequences for their compute capacity.
I’m not sure why that is an issue if vercel charges per usage anyway. I think no matter which way you do caching, people are going to mess it up. Opt out and people accidentally ship bugs that break real users experience because stuff is cached and users don’t see the latest version of data; opt in and websites will be slower and people will complain nextjs is slow (bad for marketing). I personally would rather it be slow and show the right data every single time.
One approach is obvious why the website is slow, the other is not obvious why stuff isn’t refreshing until you read their giant documentation about caching and their diagram about how it works.
Don't they change for this? I don't see how less caching would be bad for them 😅
I too use nextjs and sprinkle "use client" everywhere. My favorite features are the app router and the ability to nest the folder tree to accommodate different layouts using "()"in the name of different layout groups. The dynamic tag and image tags are also nice features.
O shit we getting thumbnails now? 😁
I decided to stop being lazy
@@WebDevCody at least you have a design eye lol, they already look better then my bro!
Really great walkthrough and explanation. It looks like NextJS has a lot of magic built in
This video is gold ❤
Okay let me give you a little context here. This video is actually giving the most important warning ever about NextJS. The other day I was playing around with Supabase and since I didn’t want to send my key over the browser, I created a server component to fetch the data from a table and then deployed. After few days I’ve deleted the database but my app was still displaying data from the table! WTF?! I was almost blaming Supabase for leaving a zombie database and instead the problem was the caching system of NodeJS!! So that’s why this video is gold and should be mentioned as a warning on EVERY tutorial about NextJS.
I hate both react and next.js with a passion. Whoever thought of porting JS to the back end seriously did not consider how complicated projects can get and how easily you can mess them up when they get really big even if you are using TS.
what do you recommend over next.js for a react project?
I think that generating your pages as static is a good thing that will save you requests to your db toll.
Great video, opt out caching clearly was a mistake. Hope Vercel listen to this criticism and do something about it.
I doubt it, but we’ll see.
@@WebDevCody The way you explained optionality in depth really hit the point home how it doesn't belong.
I'd love to hear what made you go back to nextjs from remix. Still deciding which one to spend my time in with hobby projects 😅
@@Snoodelz I have nothing against remix. I’m just so invested in next right now that jumping between remix and next projects slows me down. I know I talk bad about caching in next but I do think next has more features you can opt into compared to remix, and I don’t like remix approach to server actions.
after react server actions and long nights of thinkering i decided to leave react/next world unless there is a good reason to use it.
i started web dev with django 1.x and after a decade i am returning back to python and django with htmx or equivalent django packages which are very cool.
included orm of django, authantication and authorization is much simpler and much powerful, further more admin panel is included in django which is higly customizable by only writing 15-30 lines of code (i don't wanna even mention packages that make it super cool). I'll continue developments in node.js but i don't see any reason to use next.js/react anymore (unless there is a reason).
Django was nice, but I'm not a fan of dynamic languages anymore. I find typed languages provide a MUCH better developer experience and let you move much faster. But I won't lie, I've seen some django developers code and they can crank out features pretty fast
@@WebDevCody i agree typed langs provide better tooling however in django you actually dont need them as much as you need them in typescript.
just created a new vs code profile for python / django and it actually works like as i was used to. i don't wanna sound like trying to digress people from their path but i am pretty ok with python auto completions and suggestions in vs code. (btw as you know python has optional types which makes tooling alot better than before.)
I doubt there's a perfect framework, as long as nextjs can take feedback and keeps improving, it's still the best option for me.
I would assume next js caches by default to save on compute time for vercel
lol, “if you’re a masochist and don’t want to use react query” 😂 🏆
very coo video!
Once you understand NextJS by default caches everything, it is a lot easier to understand
The opt out caching was a horrible decision but otherwise all the new stuff is great. The biggest issue they have now is not so much how it works but how they make it easier (for inexperienced devs especially) to understand. I'm intergrating next as work currently and I dread the day I have to explain this stuff to them. Maybe I'll just send them a link yo your channel instead 😅
But have you tried Nuxt? Would love to see you build with it something you already built with Next.
I am 100% sure you will be amazed!
A lot of great tidbits here! were all these info in the docs? or were they all from your experience of "why this is happening?" type of thing?
I think most of it is documented but it doesn't really click until you hit that first "wtf is going on" moment
@@WebDevCody haha i need to start thinking about its inner workings of whats going on instead of going to chatgpt and posting all my code only to ask it to rewrite it to make it work.
So to clarify if I was using nextjs with apollo client and graphql for example, puting fetch policy to "no-cache" I would still get it cached by default in nextjs?
I feel for the case of projects using graphql fetch policy shouldn't nextjs caching have a way of following the fetch policy in the graphql resolver hook?
The edge case for verifying user email with it being cached by nextjs by default if you were doing your own verification does have some concerns for me even if you have graphql fetch policy as "no-cache".
From the Vercel company perspective it makes sense to have it default as your potentially saving to make multiple calls from the server at the start of a project's inception. Maybe there will be iterations to incorporate this perhaps
They choose that because nextjs was supposed to be a static website genrator the it evolved to kinda fullstack. What o u think?
got something for you:
export const dynamic = 'force-dynamic'
just figured if you want to cache within those dynamic pages you have to force store them with this:
export const fetchCache = 'force-cache'
check out the nextjs docs force-dynamic and force-cache, espeically it not caching on force-dynamic is a rather hidden infromation...
You just have to tickle nextjs in juuuuust the right way that it likes
Love the video as always. I have a question that has popped up many times:
- how do you deal with NextJS’s SSR and UI library like Mantine?
Mantine should work with SSR without any special configuration. The mantine components should have built-in "use client" so you can use them in server components.
What jonny555333 said, but also in general anytime you're having an issue with needing client functionality in a server component, just wrap the client-side code in its own component and set 'use client' at the top.
Good job babe! 🥰
Would you be open to doing a video on visiting more modern angular? I wasn't aware you had been in angular before. I'm very curious how you would feel about the direction they've been going.
Maybe one day
just wanted to quickly give a feedback regarding your new thumbnail style... i don't really enjoy them, they feel really clickbaity now.
but i really enjoy your content and hope you'll continue! and if that's what it takes to grow so be it ;)
Thanks for being a fan!
The problem with the React/JS community, it's so opinionated there isn't true best practice and everyone wants to be right, then change their minds every hour of the day lol.
So, ti;dw;
- The overwriting of standard stuff like fetch()
- Auto-caching which is hard to predict (if im not wrong?)
What is the theme name in Vscode?
Nice thumbnail! And yeah, agreed. I keep coming back to React. I'm now trying out Go and it kinda feels the same, I think. Or at least the community seems to be like that.
This came at a time when I am already frustrated with React after 1 year of learning I still couldnt finish learning the whole ecosystem... then I looked at svelte bcz of all the hype but am now stuck again. I might as well just go full python and ai like this. I hate front end lol
python with HTMX can’t go wrong
LEARN Go, switch to backend/systems. Felt like I became an "engineer" once I learned and used it, it scratched the itch of my curiousity.
I was in the same boat but pivoted to remix after learning nextjs for good months, I mean remix was actually good (will continue to use it along with Vite React for UI with Go backend) but seeing how simple and exquisite Go is and its capabilities, my man I was HOOKED. Been playing around cloud/tooling/devops/cli/backend servers with Go for some time now, I think I finally found my niche.
what colour scheme is this please?
Also very, interesting points, will have to consider a fe things
Particular Next.js behaviors might seem annoying, but long as one goes through the docs (their "Learn" course is very thorough) you'll be fine and won't fall into one of their annoying behaviors :p
The video preview (thumbnail) looks cool! How long did it take you to make it?
20 minute maybe. I’m trying to get better at gimp and design. And I also just copied the format of another TH-camr which helped
It is second video about it on your channel. You test Remix and enjoy it, why not stick to that? Because it's not fancy or not that magic?
Because I already have too many projects in next and I see little benefit to switching. I can just add export dynamic = force-dynamic on all my pages and all my problems would go away 😂
so next.js has many options and we need to read the documents carefully? btw,do u use react native for web?
Problem with Angular's "batteries included" approach is just that, low optionality, one bad apple spoils the bunch. I deliberately do not use *ANY* Angular features that returns observables because RxJS is just a nightmare and it's almost inescapable. Hopefully Angular will see a new day with signals but idk.
Rxjs is not a nightmare. It can be hard to understand at first, but once you understand the fundamentals it’s a powerful tool that lets you get fine grained control of your data flow.
@@colinb8332 exactly.. RxJS is the biggest advantage if you can use it properly
I have angular because of rsjx. Over engineering at its finest.
@@colinb8332RxJS is overkill for 99% of applications.
It has very specific use cases, but defaulting to RxJS for the most mundane tasks is just insane.
@WebDevCody - You forgot to mention most frustrating thing about caching. About SOFT navigation, the noStore() and none of the other options actually work either...(For the first 30 seconds after entering the page.) they have set RSC payload to be be cached by default for 30 seconds and we as developers doesnt have a change to opt-out of it...
I decided to ignore that one; I’ve made videos bitching about that already on my channel 😂
@@WebDevCody But you r kinda big now on youtube for them to respond to your opinions. Evn LeeRob are commenting your video :) You have the pover to bitch about things till they fix ;)
@@iPankBMW 😂 at the very least they can watch someone else struggle with something they might find intuitive. If I’m struggling with it, I’d bet money others are as well
what extension is your block highlighter?
Rainbow indent i thing
Been playing around with v14 and having a mish mash of server and client components seems like it's going to be a nightmare in a big project. Data fetching happening deep down in the component hierarchy in order to get suspensed components... React just by itself is hard to debug and prone to spaghetti since they introduced hooks, now this... I don't know, foreseeing a big industry migration away from this. I'm not the only one tired of having to relearn the framework every 6 months because the new version solves problems that don't exist in 99.9% of apps.
You should have titled this video "You'll learn more about nextjs than any other video"
🤣
**Pun Intended**
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
Bjarne Stroustrup, The C++ Creator
Iove how nextjs use cached
Hi Cody, I am kinda newby about using next. I have a problem with state management on next.
Assume that we have a server component and fetch some data in it.
How can we store that data for the using all other pages even if these are server or client comps.
Server and client components can store same data with state management libs but its feels tricky
What do u think about that?
Not sure, probably include a custom component which fetches the data if it’s not set and store it in context or localstorage
advice : ditch nextjs
Am I misunderstanding it but don't you achieve the same result by just typing export const revalidate = 0 ? to make the page not store cache but run dynamically.
Yes that gave multiple ways to make the endpoint dynamic, include export const dynamic = “force-dynamic” or using noStore. Their docs recommend using noStore over exporting the dynamic const. Revalidate = 0 will also work from what I understand.
I've tried starting my projects in Nuxt3 many times, but I always end up going back to React and Next, primarily because their ecosystem is so robust. In every project, there seems to be at least one essential package for which only a React SDK is available :(
Is there any function that NEXT can accomplish that NUXT can't?
I remember you said a few videos ago that creating thumbnails for the videos takes time so you don't do it, and I was thinking "it can probably be done quickly enough and would probably get the channel more clicks".
But then I thought "who the f am I to say anything, I can barely call myself a programmer, let alone tell someone anything about how he runs his successful TH-cam channel".
So I'm genuinely curious: what made you decide to create one for this video? Is it an experiment? Did you find a quick way to do it and thought it's worth a shot?
I’m experimenting for a bit to see how it does
@webdevcody what glasses frames do you have?
calvin klein
Hey, Cody, what theme are you using?
which icon extension are you using? i've been searching for something like what you have but can't find it :(
bearded icons
thanks
Question Cody what software is in your thumbnail for VFX
what is VFX? that background image? that comes directly from the next.js docs
@@WebDevCody ah then they probably used Figma
i've been making projects in react for 5 years and i was so excited to try out nextjs in my current project and after we were at the halfway of the project nextjs is so irritating that it has lots of downsides so i had to convert all the project to reactjs again. i've never use nextjs again. just use a backend framework for the backend. never try to make a whole project in a single app.
the DX of using react-query is just pure joy when compard to this
I've been thinking about the best way to handle this. Thinking server side for the main landing pages. Server actions for the login. And then reacts query for everything else
I gave up with nextjs. I switched to rails to power up my startup.
Actually at 8:34 you kind of made an error i think you can just do "/api/todos" and next will just figure it out. If I'm not wrong
Hmm I can try again later but I was getting errors and needed to provide a full path
Next js a weird mvc pattern i call CBA, content based arch, its a mess in my opinion, eventhough i like it a lot and im still discovering next js, i wish it was better
it's totally tiring to debug code for two hours to see it's cached and you are not insane. I wish there was an easy indicator that shows something like "this content is cached"
Having too many options is as bad as having NONE.
You have some valid points, but frankly, to me, your issues looks mostly like knowledge gaps
That argument can be made for anything that feels complicated. “Skills issue” isn’t the right response when valid criticism is given for a library or framework; maybe the framework is just a bit too complex?
sometimes this unstable_* functions have weird behaviors on production, I guess that's why they're unstable
How does laravel + react.js sound ? Wanna give it shot ?
I like my typescript
New thumbnail, who dis
Trying to play the yt game a bit more 😂
Page router is still the king
The forced caching problem looks like they defaulted to SSG instead of SSR.
I think the app router it is kind of a mess, I don't really like it, it causes packages error. etc, I've tried many times, but sitll end up using pages router. Please Nextjs if you see this focus on the pages router add more features to it just like App router has. I love using nextjs I don't want to move to other framework😥😥
why are you using fetch inside your rsc to call your own server?
I was making a point not showing you how next could should be written
can you export force dynamic vs noStore
Yes that works as well
Remix >
All the way!
Switch to Nuxt and enjoy life.
Great and informative video, like always. I do have to say I'm less than impressed by the thumbnail. It feels a bit clickbaity and reminds me of the ones from another tech youtuber that seems to only do that.
I copied Josh tried coding and asked him for feedback
I wish it was more like qwick
I love nextjs but the complexity they adding in every new update is pretty confusing to me
did he go over why he doesnt like sveltekit?
Sveltekit is good, I just use next because it’s what I already know and all my projects are already in it
Sad you have such a nialistic mide set about next js. I understand your sentiment however next js is the tip of the spear among all javascript frameworks. If you are weary about learning and staying up todate with new tech and practices then just use html css and javascript
if people don’t complain, how will stuff improve?
@@WebDevCody makes sense. Your video is very informative
20 minutes Just to say that you dont like the cache by default. Well, i agree that this needs to need off by default, but dont use NextJs jus because of it? Makes no sense to me. And some things there you just don't understand how to use.
I mean the video was more to explain how next does things pretty nice for the most part and it is a walkthrough explaining some main concepts. If you wanted me to say I don’t like caching on by default my video could have been a tweet, but that’s not how TH-cam works 😉 also I never said don’t use next. I literally said I keep coming back to next because it’s the best option imo.
Absolutely there are things I don’t 100% understand about next, but that’s also the point. Nothing is very straight forward and that leads to a bad DX.
@@WebDevCody Maybe the title of the video and the purpose of it don't match with what you are trying to pass. But it's like you said, it's how youtube works.
Thanks for the attention.
I was developing a dashboard for a project and never found the problem of why invoices dind't refresh with new data, after some time I discover the default caching by a video, but what a pain to be hours staring at my screen with no reason of why that happend when in development worked just fine
This is unfortunate. I was looking forward to experimenting with RSC with Next but opt-out caching is a HUGE footgun. I guess I'll have to wait for other RSC implementations
I feel like you're overstating your point by saying that it's not a good framework when the only things that you dont like are the default caching settings.
And that’s the beautiful thing about opinions
Vike has even more optionality than Next.
Yes I’d agree with that, but vite is just the plugin and build tool, not the framework. You’d have to compare next to nuxt
@@WebDevCodynot Vite, but Vike which is a Vite plugin that replicates NextJS.
@@magne6049 oh interesting I’ll have to look into it
I have to say that criticizing all the default caches is understandable because they have a decent learn curve and you have to read through the docs thoroughly to understand them all.
Having said that it is my opinion that it's better to force devs to "fix the cache bug" (not a bug, just your skill issue), than letting thousands of unoptimized NextJS projects all exist without any caching solution.
If this was a library, I am 100% for cache being "opt-in", but since this is supposed to be a complete framework which is highly opinionated, I think that caching by default is reasonable.
So I will pull a Primeagen here and call this a "skill issue" for anyone that refuses to learn the framework properly and opt out of the 3 different caches implemented by the framework when necessary.
I know it is a controversial opinion, so flame me.
I would agree if it were not for the fact that these caching issues WILL affect your users. But yes, learn how to use Next.js and it won't be an issue; that argument can literally be applied to anything, but it doesn't negate the fact that it's still a real issue for many. I literally have code deployed right now using next that never updates because I set the cache to 24 hours and for some reason Vercel just doesn't update the page. I had to change the cache down to 1 hour to get vercel to actually re-compute the page. These are reall issues that real devs struggle understanding, and if the hosting company who made next.js can't get it right, why would we?
@@WebDevCody that case is inexcusable indeed, they should get it right before advertising it as a product.
I know it's not your case, but I feel like way too many people want to make value judgements about frameworks and libraries without fully understanding them, and that sometimes frustrates me. The day I made this comment was of them. I apologize if I came across too harsh.
@@luizgrocco I just like to complain when I’ve wasted an hour developing because of simple mistakes, and my complaining generates views. 😂 no worries thanks for the comment.