Next.js, Just Why? (2023) | Hacker News Reader

Next.js, Just Why? (2023)

pilcrowonpaper.com

69 pointsswyx38 comments

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

Our team did the same.

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.

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

- Layouts answer: https://github.com/vercel/next.js/issues/43704#issuecomment-...

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

Regarding layout, there is NO REASON you need to use a request response model. That's just bad design.

Other frameworks manage completely fine to expose location data without implying dynamic rendering.

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

> If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import

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!

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.

Thank you, Next

>bad for the world

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.

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.

>Next.js 12 and the Pages Router were fine.

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

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

Needs (2023). This is likely resurfacing because of this book by the same author that's currently on the front page:

The Copenhagen Book: general guideline on implementing auth in web applications (199 points, 52 comments) https://news.ycombinator.com/item?id=41801883

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

It's worth noting this post is a year old. I can't remember exactly if this was mentioned in the docs at that time, but it is now: https://nextjs.org/docs/app#how-can-i-set-cookies.

It's possible this post influenced us making the docs better last year.

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

There have been quite a few 'Everything frameworks' over the years and some of them have had impressive adoption curves but, ultimately, they tend to fall out of favor sooner or later because what makes them highly productive to develop with at the beginning also makes them rigid and inflexible; this tends to become a problem later on after the project which uses them has matured.

Some guardrails/constraints are good and should remain, but sometimes you want to do away with certain constraints as the project grows and requirements change. 'Everything frameworks' tend to fall short in the long run.

Personally, I didn't get into Next.js because I didn't see the value in server-side rendering (SSR). IMO, if you want good SEO, you should make a plain HTML landing page (avoid single page JS app)... Single page apps are good for applications like dashboards and control panels; but note that these applications are usually private and require log in... So you don't want those to be indexed by search engines anyway.

It seems like Next.js serves a relatively narrow set of use cases. I've come across many cases of people wanting to use Next.js for their next project because they want to get on the hype bandwagon and they have a vague sense that it will help their career prospects... But in almost all cases, the benefit of Next.js boils down to SSR and after some questioning "Why do we need SSR for this?" it turns out that we don't.

I have come across several projects which used Next.js but didn't use SSR and in one case, the founder openly stated that they didn't like using this aspect of it... The attempt by Next.js to blur the boundary between client and server is often ill-informed and a potential source of security vulnerabilities. So really, the only thing which Next.js brought to the table in that case was the file/folder structure... Not sure that's a good reason to add such a substantial dependency.

from the outside looking in the time and space vercel have dedicated to their v0 product feels like a leadership team bored (or worse) with their main product offering.

it seems as if a company enthralled by AI fever at the very top of leadership, preferring hacking into some new dubious tangential product offerings than circling the wagons and fortifying their core proposition.

(I work at Vercel) Next.js is definitely still top of mind and a company priority. It's what I personally spend most of my time on.

My biggest fear is they deprecate a standalone build mode which allows you to host app on your own server, and you will be left with running in Vercel or just build a static app.

It is already very complicated to build app with many dependencies, and to manually manage the dependencies included in the build is nearly impossible.

For example, if you want to update the production db after you deployed the app, including the prisma ORM cli not very straightforward.

I used to really like NextJS. For "webapps" I would reach for the "vite + react-ts" starter and for "websites" I would always reach for NextJS. But over time it went from "this is a great framework" to constantly going "nobody asked for this, why is this like this".

It went from a solid react framework for generating websites to one that clearly had use cases in mind and was always pushing you in a particular direction. Whether that would be with Next Image and the inability to statically optimize images at build time to an obsession with react server components.

And with Next Image for example, there was a clear motive to kneecap it and make it so it only really worked inside Vercel (until OpenNext came along). Gatsby could optimize images at build time and there's even an excellent plugin for NextJS that does just that. The devs had almple time to implement this feature however even today it's not available.

I've since switched all my "website" development to Astro and haven't been happier.

With frontend frameworks, I can't define what I'd really want from them. I recognize many features as "great to have DX wise, not great UX wise," like SSG, and others yet as "great to have UX wise, terrible DX wise," like different mobile vs. desktop layout that isn't easily doable w/ media queries.

Frontend is in a really awkward place right now.

>My final gripe is with middleware. Why does it always run on the Edge? Why limit it from running database queries or using Node.js modules?

A lot of the answers to these questions are plain as day to see as an outsider:

VC dollars demand VC returns.

NextJS will continue to shepard react in a direction that benefits Vercel and pay big bucks to tech influencers like the mustache dude.

Walk away, there are better ways to build web apps today.

Middleware will soon support using the Node.js runtime, if you want. However, you still shouldn't run blocking database queries there. There's where the framework is currently trying to push you towards, but not doing so well enough to understand that tradeoff. That's why there is a supplemental API being added: https://github.com/vercel/next.js/pull/70961

Good to hear. Even with edge you can have a request that blocks or does something silly so IMO it should have had node from the beginning. A common use case is verifying a session or authorization for an entire area.

Unfortunately, that's an anti-pattern here if you are making a request. If you're just checking cookies, then yes that makes sense. The documentation on auth for Next.js tries to make this clear, but my feeling is that "middleware" was a bad name and it came off like we were trying to do Express middleware 1:1.

I always use pure React for my projects. (Simpler, cleaner, faster)

The only time I go to Next.js is when it has to be SEO friendly. For me that is the only advantage of next.Js

Excellent write up man! These things frustrates me and I am hesitant to use Next.js for more dynamic apps.

Agree, this is a strange framework decision and I also hit this recently.

I think the TLDR is that you can't mutate cookies in server components so that they can fully support HTML streaming. The workaround is doing a second request from the client to update the cookie. Kind of fuel for the conspiracy theories around app router being about driving vercel revenue.

FWIW I'd gladly opt-out of streaming to eliminate the cost and complexity of making a second request.

Since HTTP does not allow setting cookies after streaming starts, you can't set cookies from a page or layout directly. Next.js believes response streaming is a tradeoff worth making, so if you don't want or need streaming, then Next.js might not be the right choice for your app.

If you're wondering "why streaming?": https://vercel.com/blog/how-streaming-helps-build-faster-web...

thanks for the link!

i hear you on not having to build for everyone and it's good to take a stance and not be for everyone / every use case. dhh talked about this at railsworld recently [0].

i think i've got it working ok with the second request to update the session (as suggested here [1]).

[0]: https://www.youtube.com/watch?v=zPBbHu-BKpQ [1]: https://github.com/nextauthjs/next-auth/discussions/9715

If you're looking for an auth example: https://github.com/leerob/next-saas-starter

this is useful, thanks. looks like I can probably do what I'm trying to do (update cookie, return html in one request) with middleware.

> if you don't want or need streaming, then Next.js might not be the right choice for your app.

I'm glad to see this stated so clearly. It's important for frameworks to be upfront about the use cases being served and the trade-offs that are being made. I think a lot of the negativity that I see on the web is because Next.js was the right choice [for them] in the past, but once it moved towards streaming as the primary paradigm, those same people probably are feeling left in the dust. I think it would be good for the Next.js team to reiterate this and/or make it more clear in the docs so that new devs can make informed decisions when evaluating Next.js for their next project.

agree, this statement should be in the docs. didn’t realize app router wasn’t intended for my use case

Reply on news.ycombinator.com