The two best days of a NextJs developer life if the day he starts his project and the day he migrates it to React Router.
Next.js is infuriating
191–200 of 602 posts
Re: Next.js is infuriating
#192I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
> I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here we are.
Re: Next.js is infuriating
#193Earlier quoted context omitted.
Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too. I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way…
>Windows doesn't (didn't?) have ENV vars Nope, windows has had perfectly standard environment variables since the DOS days
What's "missing" is the ability to launch things the "Bash" way: `KEY=value ./myApp`. Where the variable is scoped to the single execution.
Windows' command prompt requires two separate invocations:
set KEY=value
./myApp
$env:KEY='value'
./myApp
[System.Environment]::SetEnvironmentVariable('KEY', 'value')
./myApp
Re: Next.js is infuriating
#194My conclusion is to use nextjs only for very simple projects. Problem is that simple projects grow and become important ones. So, just dont use nextjs at all.
Re: Next.js is infuriating
#195I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity.
I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router).
Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it. My marketing site is entirely static, and my app is entirely client rendered.
Re: Next.js is infuriating
#196Earlier quoted context omitted.
Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way.
Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great.
This is the problem inherent in web dev I suspect. JS developers thought they reached the zenith of programming because they had a type system and could realize some gains via strong typing checks applied to what would otherwise be network calls.
However, at a certain point, you're better off not writing a web app anymore, just an app with a somewhat wonky, imprecise runtime, one that lacks any sort of speed and has many drawbacks.
And you lose one of the most fundamentally important parts of the web, interop. I'm sure other langs can be made to speak your particular object dialect, however the same problems that plague those other type systems will still plague yours.
Which circles back to my issue, no, sticking your head in the sand and proclaiming nothing else exists, does not, in fact, make things better.
Re: Next.js is infuriating
#197I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
> My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
That is my opinion as well. Things like SSR are forced onto users with a very smooth onboarding, but I'm concerned that in practical terms this perceived smoothness can only persist if the likes of us pay the likes of Vercel for hosting our work.
In some degree I feel the whole React ecosystem might have ended up being captured by a corporation. Hopefully it wasn't. Let's see.
Re: Next.js is infuriating
#198Earlier quoted context omitted.
> my main stack is Flutter+gRPC+Go For web apps? How is the performance? How is the developer experience?
Yes, web build comes as a nice bonus, and I've been using it from the early days of Flutter web renderer support. Now I'm using it for client-side web apps exclusively. Developer experience is... well, I usually develop app while running it locally as a MacOS desktop app build. Just much easier to use with hot-reload and Flutter dev tools. Often using DevicePreview [1] wrapper to check against different sizes, dark/l…
What would you suggest as the best resource to learn flutter, for a well experienced developer?
Re: Next.js is infuriating
#199I was about to start a new project with Next.js... is anyone willing to give me some advice? I'm about to start building an e-commerce site (30-50k poster print designs, i.e. no inventory), and was leaning towards a Django backend (because I know it) and... some sort of SSR frontend. I'm not really a frontend guy, but taking this as an opportunity to learn it. This article obviously does not inspire confidence in me…
For awareness, if you want to build a SSG/SSR frontend, there's also [Astro](https://astro.build/)
It lets you ship client islands to the client, which AFAIK is essentially partial hydration.
Re: Next.js is infuriating
#200Earlier quoted context omitted.
I think React is fine, the problem is that every single react app I've inherited is ass - people just do everything incorrectly and overcomplicate simple things. Components with like 5 different useEffects, huge global state causing all kinds of bugs, way too much frontend logic in general. The amount of JS code that exists just to mimic things you can do with HTML and CSS is staggering. Everyone complains that react…
> It's their code that's slow and horrible, react is snappy as hell when you use it properly. That's the problem though, it's hilariously easy to shoot yourself in the foot with React. If almost every project makes the same common mistakes, it ceases being an issue with the people using it, it's a broader problem. With Vue or Svelte you'd have to try damned hard and go out of your way to mess up in similar ways, beca…
I don't know Vue so I can't compare. All I know is when I write react apps they're simple, nice and snappy. And I'm not even a frontend dev nor a JS dev, I mainly work backend. It's not that hard. In fact it's significantly harder to write a horrible mess. I have to spend ages cleaning up before I can start doing real work, because I can't deal with the horrible messes people make.
This isn't just a react problem by the way, people write horrible messy backend code as well so I'm having a hard time believing that they wouldn't find a way to make a horrible mess of a Vue app as well.
But maybe you're right, maybe it is better. I wouldn't know.