Why I Won’t Use Next.js(epicweb.dev)

24 pointsby nirgaanno scorso8 comments

https://www.epicweb.dev/why-i-wont-use-nextjs

6 comments

The original title is Why I won't use NextJs, I agree it sucks but normally one should not editorialize the title on HN.

nirgaanno scorso

Sorry didn’t know that. It’s not my article so didn’t want to attribute the title to myself

CharlieDigitalanno scorso

    > I guess you could say this is a point in favor of Next.js because at least they’re reaping the benefits of closer collaboration with React. But in my experience, a team not being collaborative is a bad sign for their software.

There is something actually kind of unique about React's fundamental design at this point that separates it from every other major framework: it kind of "inverts" the model of reactivity[0] that we typically encounter in UI applications (not just web frameworks, here). I first came across this thought after reading Arek Nawo's[0] comparison of React Hooks to Vue Composition.

It seems to me that this is actually a big source of the issues with React from the complicated state management libraries and models to the need to double render in strict mode (to flush out where developers have put state incorrectly).

I bring this up because in Feb 2023 -- two plus years ago -- a Tweet caught my attention at the time. Andrew Clark had posted (2023FEB18):

    > We might add a signals-like primitive to React but I don’t think it’s a great way to write UI code. It’s great for performance. But I prefer React’s model where you pretend the whole thing is recreated every time. Our plan is to use a compiler to achieve comparable performance.

There's an acknowledgement that "yeah, it's great for performance, but we don't care". Now, two years later, the compiler is still in beta and there's no evidence that it actually improved performance at all. There's just a certain arrogance from this team that makes it very hard to root for.

[0] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...

[1] https://areknawo.com/vue-composition-api-vs-react-hooks-the-...

chrismsimpsonanno scorso

I am very new to Next.js. I came across it first two years ago in a Vercel setup and it was it was a mess. I now attribute that to the code base rather than either Vercel or Next.js itself.

Fast forward to ~9 months ago. I joined a company that self hosts Next.js in GCP (Cloud Run). The set up is so effortless I’ve actually started building a new side project completely with it. I come from C#/Swift ecosystems.

This is to say, my anecdotal experience has been extremely good. Next.js is an amazing framework and has been the catalyst for me retooling my whole career into the TypeScript/JavaScript world after resisting for many years.

medhiranno scorso

Lots of discussion recently around how Next.js is “hard to deploy” without Vercel and don’t quite understand.

I’ve been using Next deployed to a container for years without issue — what are the major challenges here?

nirgaanno scorso

For example - the fact that the FE environment variables are hardcoded at build time makes it hard to just deploy a container

williamsteinanno scorso

Last I checked, I think with nextjs, if you want to build once and deploy with different base paths (without having to rebuild), this is impossible, since the base path is hardcoded all over the build. This makes some forms of deployment of nextjs sites much more difficult than with other frameworks.

[deleted]anno scorso

upmostlyanno scorso

Great article. I 100% agree with the "too much magic" section.

I mean, have you ever tried to self-host Next? Good luck!

We managed to get it working when building Hypership, but it took my co-founder a long time to figure out and then the fantastic work of the devs at OpenNext in order to get it working.

https://hypership.dev