←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.011s | 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 #
ncphillips ◴[02 Sep 25 10:58 UTC] No.45101364[source]▶
> Half these issues stem from a relative misunderstanding of exactly where the code is running.

I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea.

My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and there's no need for a general API. (Note: Inertia works with React and Svelte too)

We tried Nuxt at first, but it was a shit show. You end up having _two_ servers instead of one: the actual backend server, and the server for your frontend. There was so much more complexity because we needed to figure out a bunch of craziness about where the code was actually being run.

Now it's dead simple. If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.

replies(3): >>45101394 #>>45102636 #>>45104557 #
1. fragmede ◴[02 Sep 25 15:40 UTC] No.45104557[source]▶
> If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.

In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)?

Do you ever output JavaScript from PHP?

My biggest question though is how do you avoid ever duplicating logic between js and PHP? Validation logic, especially, but business logic leaks between the two, I've found. Doing it all in Next saves me from that particular problem.

replies(1): >>45106474 #
2. 1oooqooq ◴[02 Sep 25 17:42 UTC] No.45106474[source]▶
spoken like a middle manager.

why would anyone send JavaScript from the php? why care about duplicating a couple json translations and null checks... it's all code is today anyway.

and switching languages? you can't use most of js as it is. even something as simple as split() have so many weird bugs that everyone just code from a utils lib anyway.

replies(1): >>45130263 #
3. fragmede ◴[04 Sep 25 18:06 UTC] No.45130263[source]▶
Oh hey, insults. Those are fun.

spoken like someone who's not experienced enough to realize that duplicated code needs to be kept in sync, and then when it inevitably isn't, it'll lead to incidents, and also can't write JavaScript without using leftpad.