←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 1 comments | | HN request time: 0.265s | source
Show context
kremi ◴[] No.45102052[source]
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 at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

replies(5): >>45102174 #>>45102311 #>>45102380 #>>45102454 #>>45102698 #
yladiz ◴[] No.45102380[source]
> But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in the same process. The fact that Next.js puts it on the edge and only allows one is breaking that assumption, and further, most applications do not need the additional complexity. To go back to your toolbox analogy, more tools mean more complexity (and money), so you wouldn't get a new tool simply because you might need it, you get it because you do need it, and the same applies to edge functionality. If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in, so you don't need to worry about it when you don't need it, and it shouldn't be called "middleware".

replies(2): >>45102710 #>>45105264 #
iw7tdb2kqo9 ◴[] No.45102710[source]
As I have mention in another comment

> If learn what is a package/module in python, try to apply that in Go without any brain power, you will complain that Go is bad. If you are using any technology, you should have some knowledge about that technology.

replies(1): >>45103557 #
1. mrbombastic ◴[] No.45103557[source]
Don’t really think the analogy holds up, middleware is an established term in web frameworks, the same space next is operating in and the thing looks a lot like a middleware but violates some of the core assumptions people make about what a middleware is. It is not really surprising it is a point of confusion.