Yep my thoughts exactly. I have encountered the exact same issues. I don't know why but there is a tonn of backlash when I say I hate next.js and think it is an objectively bad implementation of React. I am moving to Astro for my future projects. There is no reason for the pain.
I also hate how the moment I use headers and cookies to get something like I might get from the request object I am forced to render dynamically this kills SsG for me.
I honestly thought I was the problem. Glad to here someone else is struggling
Started on Next.js 12. The DX was overall "janky" and we ran into many issues with integrating third party components. Next.js 13 didn't make things better.
We switched to Astro.js and generally happy with it.
Internal discussion is that we'd give Nuxt.js (Vue SSR meta-framework) a try at some point for future projects as well. But no Next.js.
It's interesting to note that both Walmart.com and Target.com (as well as numerous other large e-commerce properties are Next.js). I think that should be telling who the audience for Next.js and, by proxy, who isn't.
I have ranted countless times in Next.js issues, and most of them have not been resolved even after 2 to 3 years. Here, I'll just list some of them in case anyone is interested.
One thing Next.js likes to do is provide a lengthy and well-formatted post explaining their philosophy and reasons why a particular issue cannot be resolved. It appears convincing at first glance, but if you take a closer look, you'll find that they are just elaborations using their own terms and logic. In other words, they explain the efforts they make to justify their decisions, which stem from poor design choices they made. They like doing things look correct but not necessarily useful, similar to the feelings I have when dealing with accountants.
I truly feel like the focus on PPR, streaming, etc. is forcing most developers to jump through unnecessary hoops and relearn the basics of Next.js every couple of months. Imo, the interceptors idea is just more evidence for that. On the surface, Next.js may try to keep all parts independent and allow PPR, streaming, static and dynamic living right next to each other, etc. but at what cost? Losing the request and the response object makes life unnecessarily harder. Artificially limiting certain pages to run in an "edge environment" is non-sensical when hosting Next.js on Node.js in the same data center as your database. And personally, I do not trust Next.js anymore with new "special" files and features. head.tsx was deprecated before our migration was even complete. Route interception with parallel routes is deeply broken to this day with hundreds of non-obvious caveats of how they can be used. Server actions are an anti-pattern, since they tie all manipulations to Next.js and make it impossible to use your data manipulation endpoints across multiple applications. Meanwhile, using REST-APIs with Next.js is incredibly challenging thanks to the client side cache and is not fully solved by router.refresh, tag invalidation or stale time.
I believe that there are many like me who would just want to use a simple server-side rendering solution with the route-based layout structure of the app directory, which was a great improvement. Please just allow users to render everything at once and synchroneously in Next.js, expose the request and response at every point and allow database access from any point. I would be very happy to trade 2ms of time and lose PPR, etc. if that meant that I could build features for my customers faster. The introduction of the app directory had me exited and I moved the first project on the day it was announced, but recently I find myself fighting the framework rather than it supporting what I need to do.
Another example of Next.js completely breaking existing code seemingly for no reason was suddenly disallowing exporting functions from page.tsx files. It worked before, so there should not be any inherent reason that it could not work anymore. Now, if I want to reuse a getData method in two pages or a page and a layout, I have to create an additional getData.ts file. Is this was the Next.js team wants users to do? Perhaps. Should they force them to do this? Absolutely not, we are all adults and requiring millions of devs to refactor their code because something could not be figured out internally or they suddenly deemed some usage unacceptable is ridiculous and user hostile.
For our new project, we decided to try Next.js for the first time and the entire experience has been hell.
- Fighting hydration mismatch errors has been extremely annoying
- (related to hydration errors) react server component is a misnomer - "use client" still does a server side render
- Compile time is around 10s+ for dev mode because if you happen to import from modules that have tons of exports, it will compile the entire thing even if you're not using them
- next-auth has nonsensical APIs (eg the jwt and session callbacks); if you want to do federated sign out, it's also a hacked solution you have to come up with on your own
- app router middleware is difficult to extend. want to have multiple pieces of middleware like express? you'll have to hack your own solution since they only support a single piece of middleware
- caching problems. next 14 cached nearly everything, and 15 now disables some of it by default to help with the issues around stale data being rendered
- no way to specify that next.js runs in node.js mode and not edge mode. have to use annoying comparisons to run node.js specific code
developing a modern JS app shouldn't be this difficult and annoying that I totally regret using it
1. The Next.js team acknowledged that the hydration errors are hard to debug and in the Next.js 15 RC they improved on that (the only reason why Next 15 isn't out is that React 19 hasn't released yet because they want to polish things with Suspense up)
2. If you had read the docs, you would have seen that “use client” still does SSR (as it worked in the Next versions before (nothing has changed)). If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import (as it worked before in the pages router).
3. Next.js still uses Webpack because they bet on Turbopack and to be fair the release of Turbopack is a bit slow. But with it, we get a massive speed boost. Already, 100% of the tests for dev mode are passing, so you really should try it out.
4. next-auth is an entirely different thing from next. next is not responsible for the next-auth APIs
5. AFAIK, everything runs in node except the middleware if you don't specify the export runtime = "edge";
Next.js is awful, and bad for the world. Bad for young developers who have to learn it and all its quirks, some whom end up believing that all software is like that. People who have to learn JSX and have it drilled into them that _this is good for you_. Its bad for abstractions about what happens where and why. And its bad for openness, because who should we trust to operate Next.js effectively but Vercel, the company with a deep, personal, existential reason to make Next both complicated and server side dependent.
It's interesting watching how history rhymes. When I started learning to code in 2004, a lot of software tools started to abstract away from underlying fundamentals, but they were very careful about the abstractions they introduced... Fast forward to around 2010 to maybe 2015, there was an explosion of abstractions (in terms of adoption); MVC, MVVC, MVP, ORM, design patterns, functional programming, dependency injection, etc... And a lot of frameworks just built on top of these concepts and were promoted as silver bullets.
Fast forward to today, frameworks are built on top of a massive amount of abstractions and philosophies, some of which don't really make sense together. There is so much stuff to learn at the top layer that, in the long run, you'd be more efficient just learning the fundamentals and working from first principles.
Even though I started coding in 2004, I started with Flash/ActionScript on Windows and I was wondering why anyone would need to use the console/terminal in this day and age... What happens is; over time, you will repeatedly get into situations which will force you to peak under the bonnet and the more you do that, the more you realize that actually a lot of these abstractions are unnecessary... Then you inevitably end up becoming a Linux nut who uses bash for everything.
I think the clearest illustration of how needlessly complicated a lot of frameworks/abstractions are, from back in 2004, was the Windows API in C++... Back then, you needed to write like 100+ lines of code just to create an empty Window! At the time, I felt so clever for memorizing over a hundred lines. I now realize how ridiculous that was. It invented a lot of abstractions, but those abstractions didn't make things simpler nor more flexible. Incorrect abstractions like this are everywhere nowadays though they moved away from the Desktop and to the web instead.
I liked NextJS up to version 12. Sometime after that I fully checked out. I currently feel a general vibe of instability from Next/React which pushes me to other things.
Also, I have no idea if I'm even in Vercel's ICP anymore. I figure that folks with feelings similar to Pilcrow or myself here are no longer ideal Next users and that's ok!
It could even be for the best. Seems that Vercel's biggest customers are happier than ever which is what really matters.
Edit: there's an adamdotdev youtube video which I strongly identified with on a similar wavelength[1].
> I have no idea if I'm even in Vercel's ICP anymore
You never were.
Walmart and Target's dotcoms are on Next.js. Are you building an application that needs SSR to optimize for SEO? Do you have deep React expertise? Dedicated teams for tooling and devops (CI/CD/test automation)?
It works for Walmart and Target because it precisely addresses their needs and they have enough resources to support manage the complexity.
I think the author didn’t really read about RSC in NextJS, which is what they’re mostly confused about. There’s a ton of documentation about it as well. However it’s immature.
To the authors credit, the community is way too excited about RSC and the documentation on NextJS suggests you should really be using it but it’s absolutely half baked. Use the Pages router for now.
RSC is a new paradigm that you would probably be better off to ignore until its a few years old. Just like many things in frontend and tech in general. Don’t use the shiny new thing unless you wanna be cut on the bleeding edge.
Where is the documentation? The vercel docs don't cover the things op is mentioning very well if at all.
RSC isn't a problem it is next implementation of it that is.
Understanding SSR,SSG,CSR etc is obvs where people get unstuck and that's fine but the api (use client, use server) and the arbitrary limitations on whatcan and cant be done serverside make this framework he'll to deal with
I think next.js is in danger of not existing. Openai moved to remix. I am moving to Astro many people I know are considering moving
> React still tries to be a library when it’s definitely a framework at this point.
There, someone said it. I’ve never seen a single project that uses React just as a library, it’s always at the core of the project and the code is built around its life cycle and abstractions.
I’ve seen Vue used as a library at times (to make just a part of a larger site dynamic) but in like 95% of cases it’s also used as a framework, even if you end up with other libraries that integrate with it (e.g. Vue Router, something for i18n and Pinia for stores) to make it seem as one unified whole.
Maybe the whole separation into libraries and frameworks in unhelpful on some level.
Readit News
I also hate how the moment I use headers and cookies to get something like I might get from the request object I am forced to render dynamically this kills SsG for me.
I honestly thought I was the problem. Glad to here someone else is struggling
Started on Next.js 12. The DX was overall "janky" and we ran into many issues with integrating third party components. Next.js 13 didn't make things better.
We switched to Astro.js and generally happy with it.
Internal discussion is that we'd give Nuxt.js (Vue SSR meta-framework) a try at some point for future projects as well. But no Next.js.
It's interesting to note that both Walmart.com and Target.com (as well as numerous other large e-commerce properties are Next.js). I think that should be telling who the audience for Next.js and, by proxy, who isn't.
- layout cannot access pathname of the current URL: https://github.com/vercel/next.js/issues/43704#issuecomment-...
- App Router cannot pass data to layout: https://github.com/vercel/next.js/discussions/44506
- router.push does not revalidate server cache: https://github.com/vercel/next.js/discussions/54075#discussi...
- stylesheet order is not guaranteed and persist accross environments: https://github.com/vercel/next.js/issues/16630
- script tag with strategy=beforeInteractive does not work in root layout: https://github.com/vercel/next.js/issues/51242
Some other thoughts:
One thing Next.js likes to do is provide a lengthy and well-formatted post explaining their philosophy and reasons why a particular issue cannot be resolved. It appears convincing at first glance, but if you take a closer look, you'll find that they are just elaborations using their own terms and logic. In other words, they explain the efforts they make to justify their decisions, which stem from poor design choices they made. They like doing things look correct but not necessarily useful, similar to the feelings I have when dealing with accountants.
- Pass data to layout answer: https://github.com/vercel/next.js/discussions/44506#discussi...
- For router.push one, I believe you're looking for this: https://nextjs.org/docs/app/api-reference/next-config-js/sta...
- Stylesheet ordering: https://github.com/vercel/next.js/pull/63157
- Script tag: https://github.com/vercel/next.js/issues/51242#issuecomment-...
I believe that there are many like me who would just want to use a simple server-side rendering solution with the route-based layout structure of the app directory, which was a great improvement. Please just allow users to render everything at once and synchroneously in Next.js, expose the request and response at every point and allow database access from any point. I would be very happy to trade 2ms of time and lose PPR, etc. if that meant that I could build features for my customers faster. The introduction of the app directory had me exited and I moved the first project on the day it was announced, but recently I find myself fighting the framework rather than it supporting what I need to do.
Another example of Next.js completely breaking existing code seemingly for no reason was suddenly disallowing exporting functions from page.tsx files. It worked before, so there should not be any inherent reason that it could not work anymore. Now, if I want to reuse a getData method in two pages or a page and a layout, I have to create an additional getData.ts file. Is this was the Next.js team wants users to do? Perhaps. Should they force them to do this? Absolutely not, we are all adults and requiring millions of devs to refactor their code because something could not be figured out internally or they suddenly deemed some usage unacceptable is ridiculous and user hostile.
Other frameworks manage completely fine to expose location data without implying dynamic rendering.
- Fighting hydration mismatch errors has been extremely annoying
- (related to hydration errors) react server component is a misnomer - "use client" still does a server side render
- Compile time is around 10s+ for dev mode because if you happen to import from modules that have tons of exports, it will compile the entire thing even if you're not using them
- next-auth has nonsensical APIs (eg the jwt and session callbacks); if you want to do federated sign out, it's also a hacked solution you have to come up with on your own
- app router middleware is difficult to extend. want to have multiple pieces of middleware like express? you'll have to hack your own solution since they only support a single piece of middleware
- caching problems. next 14 cached nearly everything, and 15 now disables some of it by default to help with the issues around stale data being rendered
- no way to specify that next.js runs in node.js mode and not edge mode. have to use annoying comparisons to run node.js specific code
developing a modern JS app shouldn't be this difficult and annoying that I totally regret using it
Of course! Duh! The concepts of “server side rendering” and “dynamic imports” are very naturally, obviously and intrinsically linked.
Using “use client” is obviously totally stupid when you want to render on the client!
Thank you, Next
Fast forward to today, frameworks are built on top of a massive amount of abstractions and philosophies, some of which don't really make sense together. There is so much stuff to learn at the top layer that, in the long run, you'd be more efficient just learning the fundamentals and working from first principles.
Even though I started coding in 2004, I started with Flash/ActionScript on Windows and I was wondering why anyone would need to use the console/terminal in this day and age... What happens is; over time, you will repeatedly get into situations which will force you to peak under the bonnet and the more you do that, the more you realize that actually a lot of these abstractions are unnecessary... Then you inevitably end up becoming a Linux nut who uses bash for everything.
I think the clearest illustration of how needlessly complicated a lot of frameworks/abstractions are, from back in 2004, was the Windows API in C++... Back then, you needed to write like 100+ lines of code just to create an empty Window! At the time, I felt so clever for memorizing over a hundred lines. I now realize how ridiculous that was. It invented a lot of abstractions, but those abstractions didn't make things simpler nor more flexible. Incorrect abstractions like this are everywhere nowadays though they moved away from the Desktop and to the web instead.
I wouldn't go this far. More realistically, Vercel's early fit was with devs just starting in their journey and Vercel has since moved beyond.
However, they haven't told anyone that they are no longer prioritizing the beginner devs and that's the problem.
I liked NextJS up to version 12. Sometime after that I fully checked out. I currently feel a general vibe of instability from Next/React which pushes me to other things.
Also, I have no idea if I'm even in Vercel's ICP anymore. I figure that folks with feelings similar to Pilcrow or myself here are no longer ideal Next users and that's ok!
It could even be for the best. Seems that Vercel's biggest customers are happier than ever which is what really matters.
Edit: there's an adamdotdev youtube video which I strongly identified with on a similar wavelength[1].
[1]: https://www.youtube.com/watch?v=Zt8mO_Aqzw8
Walmart and Target's dotcoms are on Next.js. Are you building an application that needs SSR to optimize for SEO? Do you have deep React expertise? Dedicated teams for tooling and devops (CI/CD/test automation)?
It works for Walmart and Target because it precisely addresses their needs and they have enough resources to support manage the complexity.
The Copenhagen Book: general guideline on implementing auth in web applications (199 points, 52 comments) https://news.ycombinator.com/item?id=41801883
To the authors credit, the community is way too excited about RSC and the documentation on NextJS suggests you should really be using it but it’s absolutely half baked. Use the Pages router for now.
RSC is a new paradigm that you would probably be better off to ignore until its a few years old. Just like many things in frontend and tech in general. Don’t use the shiny new thing unless you wanna be cut on the bleeding edge.
RSC isn't a problem it is next implementation of it that is.
Understanding SSR,SSG,CSR etc is obvs where people get unstuck and that's fine but the api (use client, use server) and the arbitrary limitations on whatcan and cant be done serverside make this framework he'll to deal with
I think next.js is in danger of not existing. Openai moved to remix. I am moving to Astro many people I know are considering moving
It's possible this post influenced us making the docs better last year.
There, someone said it. I’ve never seen a single project that uses React just as a library, it’s always at the core of the project and the code is built around its life cycle and abstractions.
I’ve seen Vue used as a library at times (to make just a part of a larger site dynamic) but in like 95% of cases it’s also used as a framework, even if you end up with other libraries that integrate with it (e.g. Vue Router, something for i18n and Pinia for stores) to make it seem as one unified whole.
Maybe the whole separation into libraries and frameworks in unhelpful on some level.