Live data from Hacker News

Next.js is infuriating

blog.meca.sh

241–250 of 602 posts

Re: Next.js is infuriating

#242
As someone who went from MEAN -> Java (Spring) -> MERN - > Rails I cannot comprehend how many times the JS community has reinvented the wheel.

These days I do my best to stay in Rails land, far away from Next.js. It just looks like a cluster.

Re: Next.js is infuriating

#243

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.

I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity. I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router). Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it.…

I also use next and use the pages router. Makes for a development friendly react front end.

And I have some use cases where I want to have a headless crm/api “hidden” behind the front end. So in these cases using next as a backend proxy works well for me.

Re: Next.js is infuriating

#244
post #190

I think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server. The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs. I struggled with Next.js a…

I'm also working with Next.js, app router, and like it very much.

The problem is probably that Next.js makes it very easy to move between front and back end, but people think this part is abstracted away.

It's actually a pretty complex system, and you need to be able to handle that complexity yourself. But complexity does not mean it makes you slower or less productive.

A system with a clearly separated front- and back-end is easier to reason about, but it's also more cumbersome to get things done.

So to anyone who knows React and wants to move to Next.js, I would warn that even though you know React, Next.js has a pretty step learning curve, and some things you will have to experience yourself and figure out. But once you do, it's a convenient system to easily move between front- and back-end without too much hassle.

Re: Next.js is infuriating

#245
post #55

Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused. It’s just a shame it’s Deno-only (although I completely understand why)

I think HonoX is similar to Fresh, with the Interactive Islands

https://fresh.deno.dev/docs/concepts/islands

https://github.com/honojs/honox?tab=readme-ov-file#interacti...

Re: Next.js is infuriating

#246
Most of the modern frontend ecosystem is infuriating. The early React + Typescript era was mildly upsetting but bearable, and it hinted at a relatively nice future if abstractions improved. Then Vercel et al threw that slow progress into an overpriced garbage can.

Re: Next.js is infuriating

#247
post #211

I’ve always felt that Vercel’s way has had fundamental flaws at its core “philosophy” and their approach to creating shiny objects from outside that stink from inside. Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point. What are the alternatives beyond Vite and Remix?

Rails and Laravel are still big players in the space that have only gotten better with time.

Re: Next.js is infuriating

#248
post #55

Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused. It’s just a shame it’s Deno-only (although I completely understand why)

I think HonoX is similar to Fresh, with the Interactive Islands https://fresh.deno.dev/docs/concepts/islands https://github.com/honojs/honox?tab=readme-ov-file#interacti...

Ooo nice, I didn’t know about this. Thanks for posting, looks interesting, and framework agnostic to boot :)

(Edit: well, potentially at least)

I did try to make something like this a couple years back to deal with multiple renderers and a choose-your own set of various SSR techniques [0], but didn’t get very far with it in the end. I should have based it on Hono really, to get web standard Request objects.

[0] https://github.com/coxmi/ssr-tools

Re: Next.js is infuriating

#249
post #177
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…

Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web.

Vercel funds and sponsors many open source projects that would otherwise be struggling for funding. Their framework is tailored to the platform they build because that’s a good experience. I don’t currently use them, but people get funneled to their paid plans because it’s a good developer experience. I acknowledge that they are a capitalist enterprise with their own motives, but I think cancer of the modern web is a little strong.

Re: Next.js is infuriating

#250
post #148

Earlier quoted context omitted.

Don't you find it problematic, as a framework that's 8 years old to already have reached version 15.x? Assuming they follow semantic versioning and those are 15 different backwards incompatible upgrades?

Don’t think it’s semver.

I think it is, that is why it is still unstable, 2 majors changes/year.
Post reply on HN