Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js is infuriating

blog.meca.sh

Post reply on HN
Print view View original

131–140 of 602 posts

Re: Next.js is infuriating

#131

Post by mcny »

christophilus wrote: post #83
YuukiRey wrote: post #79

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. 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.

Second worst for me. I’ve used Sharepoint.

Third worst if you have used Lotus Notes mail. I still don't understand how an email and calendar client can slow down a computer like that (going by memory, the last time I used it was at work in 2013 so pre-SSD days).

Re: Next.js is infuriating

#132

Post by ncphillips »

solatic wrote: post #14

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…

> 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.

Re: Next.js is infuriating

#133

Post by lysecret »

YuukiRey wrote: post #79

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. 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.

What did you use instead?

Re: Next.js is infuriating

#134

Post by zero_shift »

YuukiRey wrote: post #79

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. 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

Re: Next.js is infuriating

#135

Post by zero_shift »

ncphillips wrote: post #132
solatic wrote: post #14

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…

> 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 t…

Notice that nearly everyone pushing edge-execution JS has some infrastructure to sell you.

It's positioned as a ramp up for companies where frontend and backend devs work at loggerheads and the e-commerce / product teams need some escape hatch to build their own stateless backend functions

Re: Next.js is infuriating

#136

Post by arnorhs »

Rauchg wrote: post #5

Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time. If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It…

First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point.

I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.

The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.

This is a trend across a lot of projects these days - often missing all the nuances and details - writing good documentation is really hard. Finding the balance between making things user friendly and detailed is hard.

Keep it up

Re: Next.js is infuriating

#138

Post by matt-p »

mvdtnz wrote: post #63
solatic wrote: post #14

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…

> 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…

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.

Re: Next.js is infuriating

#139

Post by throw-the-towel »

Sammi wrote: post #76
pzmarzly wrote: post #58

> SvelteKit is a Vercel product While Vercel acqui-hired many developers behind SvelteKit and Nuxt.js, I was under the impression that they weren't interested in running these projects hands-on, or even making them similar to each other. Can anyone correct me here or explain what their long-term game seems to be?

Rich Harris answered this question on Reddit a year ago: https://www.reddit.com/r/sveltejs/comments/19ac6lp/concern_a... Seems Svelte is still mostly managed as an independent open source project.

Given that Svelte's marketing and docs now treat Svelte itself as a minor implementation detail of SvelteKit, this doesn't exactly inspire confidence.

Re: Next.js is infuriating

#140

Post by matt-p »

b_e_n_t_o_n wrote: post #94
mvdtnz wrote: post #63

Earlier quoted context omitted.

> 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…

Agreed. It's a bit insane that updating a button padding redeploys your entire backend.

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.
Post reply on HN