Live data from Hacker News

Next.js is infuriating

blog.meca.sh

501–510 of 602 posts

Re: Next.js is infuriating

#501

Earlier quoted context omitted.

It's weird how C# can elicit such an eugh response, and TypeScript gets so much love. They're.. made.. by.. the.. same.. people I agree people really need to update their mental model of where dotnet is at. I worked with it on Linux and it's a great experience

Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.

It is because C# uses nominal types (C-like) and typescript uses structural types (ocalm-like).

https://en.wikipedia.org/wiki/Nominal_type_system

https://en.wikipedia.org/wiki/Structural_type_system

Although nominal types doesn't necessarily mean OOP-ish (inheritance-heavy) it is a pre-requisite (for inheritance-heavy code).

The distinction between the two is not a black/white thing but (modern) typescript (and Flow as well) is heavily focused on structural typing while C# is heavily focused on nominal typing. In fact the whole composition vs inheritance discussion fundamentally is about making types that behave in a more structural manner.

Re: Next.js is infuriating

#502
post #32

They're trying to do something that's fundamentally very hard. Unifying server-side and client-side code was always going to cause confusion when the difference becomes relevant. Personally I'd rather go in the direction of having code that's explicitly server-side, explicitly client-side, or explicitly shared utilities. But you'd need more of a type-safe mentality to take that approach, and you'd probably scare off…

Your observations apply generally. Debugging "magic" frameworks is often more complex than starting with simple basics and a coherent design. As a bonus there are less dependencies, less build issues and lighter pages or binaries.

Well said.

Re: Next.js is infuriating

#503

AsyncLocalStorage.enterWith is the wrong method; .enterWith changes the logger for across the *synchronous* execution. This doesn't matter if there's only one request happening at time-- like when you're testing locally. But that's why it didn't work on the actual project. Use .run. return LoggerStorage.run(requestLogger(), () => { logger()?.debug({ url: request.url }, "Started processing request!"); return NextRespo…

[deleted]

Re: Next.js is infuriating

#504

Earlier quoted context omitted.

> What's wrong with making the framework easier to use? Vendor lock in. Magic leaky abstractions are great until you need to debug something a few layers down when the magic stops working. > how else do you want framework development to happen? Loosely affiliated open source efforts maybe. If that doesn't work, I would prefer to have none at all.

> If that doesn't work, I would prefer to have none at all. While we would all like to retire to a cabin in the woods and be a carpenter, and for corporations not to exist, that seems unrealistic. Magic leaky abstractions are orthogonal to vendor-lock in, and the source is open, so I'm not seeing the lock-in part. The "hey it's easier and cheaper to smash the deploy-to-vercel"-in, sure, but things cost money. Either…

I never claimed my preferences were realistic!

Stuff costs money, sure. But I don't think it's that simple. Next and Vercel come from the same organization. I have no objection to a paid hosting solution making it operationally simpler. However when that same org has control over the free thing, they can make it even more easier (probably grammatical! who knows) that it would have "naturally" been.

Re: Next.js is infuriating

#505

AsyncLocalStorage.enterWith is the wrong method; .enterWith changes the logger for across the *synchronous* execution. This doesn't matter if there's only one request happening at time-- like when you're testing locally. But that's why it didn't work on the actual project. Use .run. return LoggerStorage.run(requestLogger(), () => { logger()?.debug({ url: request.url }, "Started processing request!"); return NextRespo…

I have enterWith working perfectly with async/sync flow - all operations between request and response are logged with request id transparently. I am using custom server for both standalone build & dev server, nextjs 14, node 22.

Re: Next.js is infuriating

#506

Earlier quoted context omitted.

or directly in powershell, `Start-Process myproc.exe -Environment @{ FOO = 'bar' }`

What an absolutely awful syntax. How Powershell ever got popular is beyond me.

Because it's objects, not text. It "scales" a lot better in your brain because in general you need to know a lot less than in bash. No more awkward sed and awk scripts, manipulating objects is a breeze. Awkward syntax at places where you have to create an object from scratch is a fair price.

Re: Next.js is infuriating

#507

Earlier quoted context omitted.

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…

Vercel won the techfluencer space like none other. They get a bad rep largely due to the influencer crowd adjacent to them. Influencers are cancer but an almost necessary one like marketing. Annoying, obnoxious, and always trying to get your email but god damn do they get your attention.

No. It’s not the influencers, they are just an irrelevant nuisance. It’s the business plan of Vercel, the venture-Capital backed company.

They hire the core contributors of all major web frameworks to continue development under their roof. Suddenly, ongoing improvement of the web platform is largely dependent on the whims of Vercel investors.

They pretend to cater to all hosting providers equally, but just look at Next, which will always be tailored toward Vercel. When will it happen to Nuxt? Sveltekit? Vercel is in a position to make strategic moves across the entire SSR market now. Regardless of whether they make use of that power, it’s bad enough they wield it at all.

When has this ever been a good idea? When has it produced a good outcome? It never has, and it never will.

Re: Next.js is infuriating

#508

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…

That sounds like a good candidate for Django using either Datastar or HTMX with web components (Lit/React/VanillaJS) as an escape hatch for really interactive bits. Instagram, Threads, Doordash, EdX, Octopus Energy, etc. have all running Django at scale for years.

Re: Next.js is infuriating

#509
post #329

Earlier quoted context omitted.

The non-profit works in Africa and is all about using local resources when at all possible. They knew some people that worked with a group out of Nairobi that talked a good game and they liked the people they met and the non-profit folks are NOT technical, they jumped on it. It's a classic story really--I've been on this side of the table many times before with outsourced work. If they had brought me in before hand I…

"We don't know a lot about this, what could go wrong?!" Sigh...

"We don't know a lot about this, let's hire some experts to handle it for us"

Re: Next.js is infuriating

#510

Earlier quoted context omitted.

> 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 That is my opinion as well. Things like SSR are forced onto users with a very smooth onboarding, but I'm concerned that in practical terms this perceived smoothness can only persist if the likes of us pay the likes of Vercel for hosting our work. In some degree I f…

Might have? The official React docs recommend Next. That capture happened... two years ago? (Perhaps there's a good blog post there, if it doesn't exist already)

Hi! I maintain Redux and am deeply involved in the React community, and have spent a lot of time both critiquing the React team's decisions and explaining their decisions to the community.

I actually wrote exactly that blog post and did a conf talk on it earlier this year. I covered why the React team switched to directing users to use "frameworks" to build React apps, the development influences behind React Server Components, why the React docs didn't list tools like Vite as viable options until just a couple months ago, and various other related topics:

- https://blog.isquaredsoftware.com/2025/06/react-community-20...

- https://blog.isquaredsoftware.com/2025/06/presentations-reac...

Post reply on HN