Most active commenters
  • matt-p(3)

←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 17 comments | 02 Sep 25 06:57 UTC | HN request time: 0.001s | source | bottom
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 #
1. 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 #
2. b_e_n_t_o_n ◴[02 Sep 25 10:13 UTC] No.45101081[source]▶
Agreed. It's a bit insane that updating a button padding redeploys your entire backend.
replies(2): >>45101447 #>>45104617 #
3. zarzavat ◴[02 Sep 25 10:47 UTC] No.45101278[source]▶
I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch.

I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.

replies(1): >>45106050 #
4. 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 #
5. matt-p ◴[02 Sep 25 11:09 UTC] No.45101447[source]▶
Not the same problem though is it? You can have a express backend and react-vite frontend both in typescript and in a mono repo.
6. webdevladder ◴[02 Sep 25 11:54 UTC] No.45101888[source]▶
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.
replies(1): >>45102114 #
7. nchmy ◴[02 Sep 25 11:59 UTC] No.45101931[source]▶
or dont even write a SPA. Send hypermedia from your backend language/framework, use HTMX + Alpine or Datastar, and call it a day.
replies(1): >>45103184 #
8. 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 #
9. matt-p ◴[02 Sep 25 12:07 UTC] No.45102013{3}[source]▶
I don't use next.js really any more. That's exactly what I do.
10. smaudet ◴[02 Sep 25 12:17 UTC] No.45102114{3}[source]▶
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.

replies(1): >>45106350 #
11. icedchai ◴[02 Sep 25 13:57 UTC] No.45103184[source]▶
I’ve been experimenting with HTMX and it feels so much simpler.
12. evilduck ◴[02 Sep 25 15:31 UTC] No.45104396{3}[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.

13. jakubmazanec ◴[02 Sep 25 15:39 UTC] No.45104531[source]▶
> There's absolutely no reason to tightly couple your front-end and backend

I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2].

[1] https://www.geldata.com/ [2] https://www.geldata.com/blog/designing-the-ultimate-typescri...

14. fragmede ◴[02 Sep 25 15:43 UTC] No.45104617[source]▶
Are you paying for computer time by the CPU cycle?
15. turtlebits ◴[02 Sep 25 17:16 UTC] No.45106050[source]▶
What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
replies(1): >>45114159 #
16. webdevladder ◴[02 Sep 25 17:34 UTC] No.45106350{4}[source]▶
You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees.
17. zarzavat ◴[03 Sep 25 10:30 UTC] No.45114159{3}[source]▶
HTML is not a programming language. But yes, I don't write much HTML anymore.

The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get.

Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication.