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.

> 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".

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.

I wouldn't consider this a misnomer, but a really big misuse of the term. Middleware has a long established definition in web applications, so they really should not use the term if they mean something entirely different.

To people who downvote my comment (and there are many): please elaborate.

I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.

Finally someone with a brain.

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.