Live data from Hacker News

Next.js is infuriating

blog.meca.sh

141–150 of 602 posts

Re: Next.js is infuriating

#141
post #96
post #77

Earlier quoted context omitted.

That doesn't answer parent's question. People expect "middleware" to mean a certain thing and work a certain way.

middleware = fn(req) → next(req). express/koa give you the use() chain. next.js gives you one root, but nothing stops you from chaining yourself. same semantics, just manual wiring. type mw = (req: Request, next: () => Response) => Response; const logger: mw = (req, next) => { console.log(req.url); return next(); }; const auth: mw = (req, next) => { if (!req.headers.get("x-auth")) return new Response("forbidden", { s…

Nothing trivial about that implementation in my mind - need to keep track of where middleware is registered, reduceRight is non obvious.

I expect these things to be standardized by the framework and all the sharp edges filed off - thats why I go to a framework in the first place.

Re: Next.js is infuriating

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

Will vercel/next come up with an official policy on pages roter/API routes, will they be supported long term? If I start a next project I still use pages/API routes, because of several really really bad experiences with the app router.

Re: Next.js is infuriating

#144
For people wanting to try something else, I recommend SolidJS and SolidStart. Personally I never tried Next.js exactly because it feels like too many decisions are being made for me without having any choice. And I don't trust frameworks like that.

Depending on the project, just write an SPA with an API server, or if it is a static website just prerender it and serve on Cloudflare. I don't get the appeal of all the complexity. If you need SSR for SEO, then SolidStart is a nice and simple solution.

Re: Next.js is infuriating

#145
post #107

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.

Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too. I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way…

Windows has had envvars since before Linux existed. It also has FindFirstChangeNotification (or ReadDirectoryChangesW if you hate yourself) since before inotify existed, etc.

Windows has pretty much everything you can dream of (although sometimes in the form of complete abominations), it's just that the people employed by Vercel don't give a shit about using native APIs well, and will map everything towards a UNIX-ish way of doing things.

Re: Next.js is infuriating

#146
we started a purely-frontend project with nextjs but moved to react-router pretty soon. Sure, it can be convenient (when it works), but you can't really see or understand how or how to control it, and black magic breaking is the least of what you want. Much happier now.

Re: Next.js is infuriating

#147
There are so many frameworks in this fast-moving space that I need mnemonics to keep track of which ones are well-regarded and which aren’t. Looks like this one is easy. Next.js? Next.

Re: Next.js is infuriating

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

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?

Re: Next.js is infuriating

#149

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…

SolidStart

Re: Next.js is infuriating

#150

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…

If already know Django, go with Django and sprinkle in some HTMX as necessary. You’ll get 95% of the benefits with a fraction of the effort compared to a modern Javascript SPA. And it’ll be a breeze to maintain. You’ll also save so much time never needing to debug a bundler, minifier or ESM/CJS issues.
Post reply on HN