I've came to the pain conclusion on Next.js:
It's a bad framework for building full stack apps, but it's better than anything else.
Next.js is infuriating
121–130 of 602 posts
Re: Next.js is infuriating
#122Half 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…
I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch.
I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.
Re: Next.js is infuriating
#123I always use a custom server (even express will work) with next.js, because I found the middleware and edge stuff a load of overcomplicated BS.
Client side works like regular react app, SSR for any pages where the initial props are just populated from the server site is easily controlled, and the whole system is simple to reason about.
There are other frameworks out there to do this now, but I'm comfortable with this and it just works, so no reason to change.
Re: Next.js is infuriating
#124Earlier quoted context omitted.
Yeah this is basically it. Vercel is trying to solve for optimised performance by using a combination of React Server Components, Partial Pre-rendering, Edge servers, streaming, etc. A lot of their seemingly weird design and API decisions basically come down to that. If you need it, it's good that it exists. But you can also go pretty far with doing some ssr in an edge function too.
I would be more inclined to believe it’s an end product of years of simultaneous resume and job security driven development.
LIRPslop, as Brad Troemel would put it.
Re: Next.js is infuriating
#125Earlier quoted context omitted.
> Half these issues stem from a relative misunderstanding of exactly where the code is running. If I take a look at other languages, these kind of multi-threading issues are usually represented by providing a separate context or sync package (that handle mutexes and atomics) in the stdlib. And I guess that's what's completely missing in nodejs and browser-side JS environments: An stdlib that allows to not fall into t…
This has nothing to do with multithreading, though?
Not OP but wasn't the article about lots of async/await context issues?
If the handle() method of the middleware API would have provided, say, a context.Context parameter, most of the described debugging issues would have been gone, no?
Re: Next.js is infuriating
#126You know what else is infuriating? Pages that won't load (at all—just show a blank page, or in this case a too many redirects error—if you do not have cookies and local storage enabled.
Agh, sorry about this! I'm one of the people building leaflet.pub, which this blog is running on. Just pushed a fix for this (ironically on nextjs/vercel). The redirect loop is to handle sharing auth between our "main" domain, and people's various custom subdomains. Auth, via the ATProtocol, is used for things like subscribing and commenting!
Re: Next.js is infuriating
#127I 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 doesn't (didn't?) have ENV vars
Nope, windows has had perfectly standard environment variables since the DOS days
Re: Next.js is infuriating
#128I can only recommend vike.dev .
Re: Next.js is infuriating
#129I 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…
[deleted]
Re: Next.js is infuriating
#130Earlier quoted context omitted.
> Half these issues stem from a relative misunderstanding of exactly where the code is running. If I take a look at other languages, these kind of multi-threading issues are usually represented by providing a separate context or sync package (that handle mutexes and atomics) in the stdlib. And I guess that's what's completely missing in nodejs and browser-side JS environments: An stdlib that allows to not fall into t…
This has nothing to do with multithreading, though?
Absolutely correct. Those are runtime execution context-issues. There are other frameworks that do force you do deal with those (and in other languages, probably), but I believe in next.js the difficulies are at another level - because of poor documentation and the built in abstractions to allow for running next.js both in development, node.js server, and edge.