←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 3 comments | 02 Sep 25 06:57 UTC | HN request time: 0.576s | source
Show context
solatic ◴[02 Sep 25 08:42 UTC] No.45100515[source]▶
Half these issues stem from a relative misunderstanding of exactly where the code is running. Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances:

  * You sell a B2C product to a potentially global audience, so edge semantics actually help with latency issues
  * You're willing to pay Vercel a high premium for them to host
  * You have no need for background task processing (Vercel directs you to marketplace/partner services), so your architecture never pushes you to host on another provider.
Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR.
replies(10): >>45100563 #>>45100650 #>>45100757 #>>45100811 #>>45100840 #>>45100856 #>>45101364 #>>45101939 #>>45102281 #>>45102812 #
mvdtnz ◴[02 Sep 25 09:39 UTC] No.45100840[source]▶
> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR.

Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript.

There's absolutely no reason to tightly couple your front-end and backend, despite how many Javascript developers learned the word "isomorphic" in 2015.

replies(5): >>45101081 #>>45101278 #>>45101432 #>>45101931 #>>45104531 #
matt-p ◴[02 Sep 25 11:07 UTC] No.45101432[source]▶
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.
replies(2): >>45101888 #>>45101981 #
1. happimess ◴[02 Sep 25 12:03 UTC] No.45101981[source]▶
You can have a monorepo with any tech stack you'd like.

You can write your front-end and back-end in the same language.

No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question.

replies(2): >>45102013 #>>45104396 #
2. matt-p ◴[02 Sep 25 12:07 UTC] No.45102013[source]▶
I don't use next.js really any more. That's exactly what I do.
3. evilduck ◴[02 Sep 25 15:31 UTC] No.45104396[source]▶
> Next.js tightly couples your front-end and back-end, no question.

I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor.