Live data from Hacker News

Next.js is infuriating

blog.meca.sh

71–80 of 602 posts

Re: Next.js is infuriating

#71
I 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 choosing Next.js - would someone have any suggestions/pros and cons of what to use?

I currently see the options for doing SSR as:

- Next.js: well-represented in AI training data (though recent versions had breaking changes? I'm not sure), but annoying to actually use (according to this article/general sentiment I've found online), and pushes you into Vercel? (I barely know what that means)

- SvelteKit: best DX and nice to use, but might be less present in AI training data?

- Django templates + HTMX: possibly limiting? Less maintainable once you get to a certain size? I'm not sure.

- Other options?

Re: Next.js is infuriating

#73

as a Rails dev this makes me LOL. I would have expected the rube goldburg machine of JS frameworks to be more robust and ergonomic by now, but it looks more to be hacks built on top of hacks with no real vision or technical leadership.

Yet 95% of fresh companies raising funds use that cursed NextJS framework.

This feels a whole lot like when everybody with VC cash was using Mongo. And I see that as a competitive advantage if your competitor is using these types of technologies, it means you can out maneuver them and build a better product.

Re: Next.js is infuriating

#74
post #59
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…

I wouldn't say I agree with those circumstances, but even if they did indicate a match with Next.js, they are not worth the reduction in productivity and maintainability that comes with it. I use Gleam's Lustre and am not looking back. Elm's founder had a really good case study keynote that Next.js is basically the opposite of: https://www.youtube.com/watch?v=sl1UQXgtepE

this is a really interesting talk - thank you for sharing!

Re: Next.js is infuriating

#75
For the past 5 years, my main stack is Flutter+gRPC+Go, and I read articles like this in horror and satisfaction simultaneously.

For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and more layers of it.

Personally, I try to avoid using it as much as possible. And it works beautifully. Of course, tradeoffs are everywhere, and the sheer scale of the web development community has its own benefits. For example I miss the wide choice of alternative design systems in Flutter (compared to web), but hey, flutter now decoupling it's core from design systems in 2026. But the net effect of not using fundamentally flawed tools for your products is huge.

Re: Next.js is infuriating

#76

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

Re: Next.js is infuriating

#77
post #53

Earlier quoted context omitted.

If you finally decided to support proper server-side middleware, why is there still a limitation for only one middleware function and not a chain of middleewares as every other sane server implementation offers?

Consider middleware.ts as a root middleware. Nothing is stopping you from creating your own chain (which is trivial) in there. I mean, that would eventually work the same if nextjs implemented that feature — there would be a root somewhere.

That doesn't answer parent's question.

People expect "middleware" to mean a certain thing and work a certain way.

Re: Next.js is infuriating

#78
post #75

For the past 5 years, my main stack is Flutter+gRPC+Go, and I read articles like this in horror and satisfaction simultaneously. For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and m…

> my main stack is Flutter+gRPC+Go

For web apps? How is the performance? How is the developer experience?

Re: Next.js is infuriating

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

Re: Next.js is infuriating

#80
A lot of companies have Nextjs as a requirement, you can see it in the job posts. It's almost like React = Nextjs, where they don't even mention React. There are developers out there who are highly invested in Vercel's business. Ultimately, the dev teams are responsible for making these decisions.

I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it.

The outcome was nicer and higher development satisfaction.

If you dare to say that you had to get rid of Nextjs from a particular project, during a job interview, you're done!

Post reply on HN