3 comments

[ 2.9 ms ] story [ 21.5 ms ] thread
That conversation in Next's GitHub repository makes it super clear why using Next on your own servers is a terrible technical decision, and many people there seem to not realise yet about the real reasons for things to be like this.

Going through that discussion, people seem perplexed and confused as to why they wouldn't allow such a simple change so that people can run their middlewares on a standard Node runtime when running it on their own servers.

Despite of all the excuses given there, I'm very surprised most people can't read between the lines and don't realize the real reasons they're not doing this: It's conflict of interests. They want to promote it as a tool you can run everywhere, but they also want you to deploy it to their platform (obviously...).

If they allow you to run your middlewares on a standard node runtime (which their platform doesn't support because middleware runs on "the edge" or whatever) that means that your application will never be able to be deployed to Vercel's platform.

That means that your application that you're running now on your own servers is having to deal with artificial limitations with the only purpose that the path is clear for when the time comes for you to deploy to Vercel's platform.

So, if you're using Next and have no plans to ever ship to Vercel's platform, you're picking the wrong tool, and having to deal with workarounds and limitations that should not be there at all.

I needed to mention this because, once again, somebody is rooting for Next at work and that won't happen on my watch, given we're not Vercel customers. If we were, it'd be a different story.

While running your middlewares on Node seems like a normal thing to do, they'll never allow it unless they support it first on Vercel.

This is just an example among many.

(comment deleted)
(comment deleted)