I 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.
Half 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 issues
* You're willing to pay Vercel a high premium for them to host
* You have no need for background task processing (Vercel directs you to marketplace/partner services), so your architecture never pushes you to host on another provider.
Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR.
Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time.
If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It’s also a somewhat advanced escape hatch.
Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention[2]
When I first saw Next.js I was immediatelly reminded of Meteor.js. I did invest a bit in learning into it and did some personal projects. But quickly realized it was both over-abstracted and inflexible which made it really hard to get it past prototypes.
But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Laravel vs Symphony and it was the same thing: shit breaks once complexity comes in.
If you compare those solutions with the old model that made NodeJS / React SPA get so popular, so fast: Buffet-style tooling/libraries. You basically build your own swiss army knife out of spare parts. Since all the spare parts are self-contained they have to target really low abstraction levels (like React as a component library, HTTP+Express as a backend router, Postgres as DB).
This approach has many disadvantages but it really keeps things flexible and avoids tower-of-babel style over-engineering. As in a lot of layers stacked on top of each other. Not that the complexity goes away, but instead you have a lot of layers sibling to each other and it is more doable to replace one layer with another if things aren't working well.
It is understandable why "batteries included" is so popular, it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other. It definitely needs people with more experience to set up everything.
It really is. I am a staunch react defender, I work with it daily and I found the change from class components to hooks to be a better programming model.
But whenever I work with Next, I feel like we lost the plot somewhere. I try a lot of frameworks and I like esoteric programming languages, but somehow Next.js, the frontier JavaScript framework embraced by React is the only experience where half the time, I have no idea what it’s error messages (if I get any to begin with) are trying to tell me. I can’t even count the hours I spent with weird hydration issues.
When they transitioned to the app router it was like they'd given some bootcamp graduates a crack at "improving" on the express apis - which are mature and roughly align with the composable russion doll approach taken in servlets, rack, plug and any other server interface I've ever seen.
Aside from the abysmal middleware api you also have the dubious decision to replace having a request parameter with global functions like cookies() and headers().
Perhaps there is some underlying design constraint that I'm missing where all of these decisions make sense but it really does look like they threw out every hard fought lesson and decided to make every mistake again.
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.
I have a tendency to use different stuff on new projects for the sake of it. I've built apps with express + react on client, angular, vue, next, nuxt.. Used go, .net, node, php etc on the server. I always find good and bad parts and appreciate different aspects of different solutions.
Not Next though. We built a pretty large app on Next and it was painful from start to finish. Every part of it was either weird, slow, cumbersome or completely insane.
We still maintain the app and it is the only "thing" I hate with a passion at this point. I understand that the ecosystem is pretty good and people seem to be happy with the results given that it is extremely popular. But my own experience has been negative beyond redemption. It's weird.
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 the majority who prefer runtime errors over build-time errors.
Recently started developing a client side web app using Angular v 20. The app is quite complex, with about 40 components many of them nested, about 7 to 8 "pages", data dashboards, multiple forms, continuously updating data from server, etc. There substantial amount of data flow in the application.
So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the whole process, which is,
1. I am a seasoned developer, mainly doing python stuff, back-end servers, desktop applications, data applications, etc. Very little exposure to front-end tech.
2. I keep myself updated with the concepts, patterns & architecture of front-end systems, because I am extremely into design and good UI.
3. I am at a stage where I can do basic web apps with Vue, React, Angular & vanilla HTML and JS.
With Angular Signals and concept of Stores, Services and Dependency Injection, I am able to handle data flow very easily, am able to add features to the app in a consistent manner, able to debug and trace errors with relative ease.
I have earlier read NextJS docs, Remix Docs and read tutorials about developing react apps using Vite. It has always been a confusing maze of stuff. Perhaps I am getting old (about to touch 40), but I have been programming for about 25 years now and I was able to carve out the architecture I want in an Angular app with ease.
Also, this app is going to be a production app, and is critical for my work, so its an impactful decision, which, thankfully, I have been happy and pleasantly surprised with.
It could be that I could have chosen React, and end up with the same thing, but, somehow, in the extensive tech stack selection process that I took up before committing to Angular (which involved testing out core mechanisms of the application in React, Vue & Angular), I felt very much at home with Angular way of things.
Does anybody have Vercel's mailing address? I would like to send them a "Have a good day at school!" card for this issue, which will be old enough to attend elementary school next year: https://github.com/vercel/next.js/issues/10084
The direction React and Next.js have been moving is to give you very granular control over where your code runs, and when.
The previous model was that you simply have code that runs on a server when a request comes in, sends a response to the client, and then the code in that response is run on the client. Instead, now we have a situation where some bits run on the server, some of them on the client, which call out to some bits on the server again, and all of this can happen either before or after the server started sending the response. And then on e.g. Vercel, you also have edge functions as an additional permutation.
Which is kinda neat, but also massively complicates the mental model.
> In general Next.js has so many layers of abstraction that 99.9999% of projects don't need.
This true to most software projects that are used more than one set of people. Joe Armstrong proposed a solution that we should opensource functions only and people could assemble everything else using these opensource functions. I start to think that he might be right and instead using "frameworks" we should use these set of functions instead.
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 choosing Next.js - would someone have any suggestions/pros and cons of what to use?
I currently see the options for doing SSR as:
- Next.js: well-represented in AI training data (though recent versions had breaking changes? I'm not sure), but annoying to actually use (according to this article/general sentiment I've found online), and pushes you into Vercel? (I barely know what that means)
- SvelteKit: best DX and nice to use, but might be less present in AI training data?
- Django templates + HTMX: possibly limiting? Less maintainable once you get to a certain size? I'm not sure.
A lot of companies have Nextjs as a requirement, you can see it in the job posts. It's almost like React = Nextjs, where they don't even mention React. There are developers out there who are highly invested in Vercel's business. Ultimately, the dev teams are responsible for making these decisions.
I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it.
The outcome was nicer and higher development satisfaction.
If you dare to say that you had to get rid of Nextjs from a particular project, during a job interview, you're done!
Next.js is indeed not very open for feedback.
Next.js is also opinionated.
So if you are using Next.js, you can use what they have and do it their way.
If there is something, just wait...
For me, it isn't a framework I want to use in any production environment.
Your system is too much depending on something you have no influence on.
Like in your own code, it is good to decouple, don't make things depend too much on something, not in your own code, but also on external code like frameworks and libraries.
That is why I prefer to build things like I can (kind of) easy drop my dependencies, for what reason, and use something else, or build it in my own codebase.
If some framework doesn't allow it, and you have to work it their way, and is the base of everything, that should be a big red flag.
I’ve always felt that Vercel’s way has had fundamental flaws at its core “philosophy” and their approach to creating shiny objects from outside that stink from inside.
Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point.
The only thing worse than Next.js is trying to be a subcontractor for a startup that’s building their MVP in Next.js. I will be taking no further questions.
While Vercel acqui-hired many developers behind SvelteKit and Nuxt.js, I was under the impression that they weren't interested in running these projects hands-on, or even making them similar to each other. Can anyone correct me here or explain what their long-term game seems to be?
Remix (cough react router 7 framework mode cough) is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want.
That’s the paradox of Next.js: it can feel extremely simple and extremely complex at the same time. For a small hobby project hosted on Vercel, I’d recommend it. For building a full SaaS product, I often regret it.
I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default.
Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.
I had it uninstalled when they messed with the fetch prototype which resulted in our team wasting days to find the actual reason file uploads above 100kbs failed.
Imho next attempts to do too much, moves too fast, every few months the wheel gets reinvented and never perfected.
Anyone who is running back-end code in Next.js has no idea what they are doing. It could be acceptable if it is a toy project and you want to get something quickly but even for a small operation or MVP, the whole thing is not coherent.
I've wrote previously about nextjs: https://omarabid.com/nextjs-vercel My opinion remains the same: Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform.
Since their routing/SEO/content features are also now less functional, there is really very little reason to use Nextjs especially with React Server Components.
> we of course have no idea what actually happened since the default logging is only enabled during development
Wait, if you have issues with logging, why don’t you set up opentelemetry? It’s really easy to add into a project [1], and if you don’t want to manage it, you can easily find some cost efficient solutions like Grafana Labs [2].
I like it. I have been involved in software development for 20+ years - Perl, PHP, Java, Pyhon. And Nextjs and React gave me back the joy to develop web frontend again.
There are a lot of gotchas and considerations with Nextjs, but it is a framework and it is not unexpected that unless it is developed by yourself, frameworks require some getting used to.
There are some things that could be better, especially in non-Vercel-hosted scenarios, and if the backend for frontend part becomes too complicated, I would switch to Nest.js, but overall I am satisfied with Next.
What I've found is that NuxtJS is miles ahead in DX. In NextJs it feels like their architecture stands in your way while in NuxtJS everything just works.
Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused.
It’s just a shame it’s Deno-only (although I completely understand why)
I recently migrated 2 projects away from Next.js to Vite.
It was a lot of work, Next.JS handles quite a lot of stuff: translations, authentication, bundling, css stuff, caching...
But it was very much worth it for lowering my daily infuration.
I don't think I'll be using NextJS again if I don't have to.
I'm involved in starting up a project with Next.js. Can experienced devs let me know your opinion or any potential pitfalls?
Long story short it's a proof of concept demo/exploratory project.
Currently, using Next.js app router, multi-root routes for stuff like (marketing), (app), (login), etc.
Db is Neon for the branching, will probably include Vercel AI SDK for AI stuff since its likely I'll be asked to include some AI functionality.
The only worry is I'm unsure with how this serverless layer/backend? interact with user authentication / authorization when used with the BetterAuth.
Currently hosting on Vercel, I feel like Next.js is married with Vercel for hosting. Although maybe because I'm unfamiliar with it, since Next.js made it quite simple and straightforward to do host quick proof-of-concepts on Vercel.
As much as I don't like most things about nextjs (I could write a vastly larger blogpost about it but won't as I like to keep my heartrate down), it feels like claude was trained specifically for it. In our experience, claude code is better at nextjs than other frameworks.
> This is what real engineering looks like. SvelteKit is a Vercel product. How is the flagship offering worse than what is essentially a side project. What the hell?
"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Margaret Mead
A big project becomes design by committee. If the initial kernel was sound, it can go on for quite some time. If it wasn't, it takes herculean effort to turn such a boat. And you will likely never be thanked for it.
Starting a new project to show people how it's done works as well or better than any amount of cajoling or badgering. But you still may not be thanked for it.
Posts like this really mean "this doesn't work like I expect it to based on my background with some other technology".
But in this case, I tried in earnest to use nextjs for a project with auth & stripe, etc. this past week, and I can't believe how frustrating it is to get stupid things like modal dialogs to work properly in the client.
I have tons of experience with React SPAs. But the client/server divide in Next remains quite inscrutable to me to the extent that I'm just going to start again with Django (where I nearly started it in the first place).
So yes, it doesn't work like I expect it to either...
I think too many newer "developers" are relying on AI tools trained on popular frameworks like Next.js to create things, and Vercel's loving this because they're the "go-to" in the end when you need to deploy something based on this stack.
There's no real alternative for these developers because they weren't brought up to understand server/networking fundamentals, how to operate a VPS, etc. Vercel manages to make this even more confusing for them by blurring the line between server and client, "edge" functions, etc, while all behind variable pricing.
For people wanting to try something else, I recommend SolidJS and SolidStart. Personally I never tried Next.js exactly because it feels like too many decisions are being made for me without having any choice. And I don't trust frameworks like that.
Depending on the project, just write an SPA with an API server, or if it is a static website just prerender it and serve on Cloudflare. I don't get the appeal of all the complexity. If you need SSR for SEO, then SolidStart is a nice and simple solution.
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.
I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler execution order or something.
If you picked NextJS without knowing how it structures its middleware, the vendor lock-in to Vercel, its SSR strategy, its hydration schemes etc. that's on you. I, and many others, have had a lot of success with NextJS increasing delivery speed and ultimately, customer value.
Two years ago I moved off of the React ecosystem to Elixir/Phoenix/LiveView, and it's been great. But that's had its own challenges stemming from the design decisions its creators have made. You're always going to be running into things that you don't like, and I feel NextJS has just become an easy target for people who are looking to vent.
Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, easy to use plugins. It just solved many of the boilerplate tasks for me, and let me get on with react.js components, hooks, etc. I use Django backend for API, and static hosting for the frontend.
Potential alternatives I've found:
* astro
* remix
* back to react-router... and there were multiple back when I used it! :(
Through a customer I've come into contact with InertiaJS. React with Laravel made my work so much simpler. Routing through Laravel was easier for me. The data sharing from Laravel to the frontend is painless.
I also like the server side, PHP works better for me than a Javascript server. I've had some weird bugs with nodemon, pm2 and other server tools.
Adding on to the other comments here about Next.js vs Remix.js.
We had to choose a framework for our new app last year and were researching the current state of things. Next.js was / is by far the most popular, but also had some of the worst feedback and caution to stay away. Remix isn't perfect, but I appreciate less abstractions and working with simple request / response structures.
Also, a warning for those hiring for frontend / fullstack roles:
Over the years when hiring for roles for X frontend framework, we would constantly find "experts" in framework X that would really impress us. Whether it was React, Angular, Vue, Remix, etc. Then after moving forward, we found they didn't know core JS fundamentals and were basically useless beyond the framework.
As others have noted, if you need a React framework, React Router v7 (in framework mode) is much better than Next.js. I would argue it's a great framework. No over-abstractions, just React on top of standard web technologies.
Don't be scared by the complaints about previous breaking changes (which BTW are inevitable when we still haven't figured out the best approaches to the server/client app architecture) - React Router's current strategy using various flags [1] allows you to prepare for breaking changes well in advance.
If you are trying to share context between middleware (backend) and rendering (frontend) literally rather than logically (via request-id only) then that seems to stem from a fundamental misconception of the distinction between backend and frontend to me ...
I suspect all these "all-in-one" JS frameworks out there unfortunately made people think that web apps are made of "one big happy javascript application, yay!" while it's really two (or even three) entirely decoupled runtimes (backend & frontend) instead.
> You think I'm joking? There are hundreds of issues with as many emojis with no official response for years. And when you finally get a response, it's to tell you that what you're doing is wrong and a solution to your real problems is on the way. Then they proceed to keep the "solution" in canary for years on end.
It's so much easier to hire people to do prioritisation (or deprioritisation) or code of conduct enforcement or whatever than to just do good work.
There are so many frameworks in this fast-moving space that I need mnemonics to keep track of which ones are well-regarded and which aren’t. Looks like this one is easy. Next.js? Next.
As an experienced dev who has explored almost all possible JS options - including but not limited to - React, Angular, etc. and settled for Phoenix/Elixir, I can tell you nothing comes close to the peace of mind you get from just opening up a text editor, naming a module whatever the fuck you like, writing functions, piping the results, validating with `with..do..else` and the best part - catching errors at compile time. Everything just works - even after 5 years. Whereas, with JS, something keeps getting burned down every 6 months or less even if you didn't touch the code at all.
Next.js is 8 years old and still under-documented, and you will still get lost if you veer off the beaten path - of which sometimes there is none.
Frankly, I was mad at myself for not recognizing the hubris and their ignorance of web dev history when I noticed that they brought back directory based path convention from the 90s. That should’ve been the red flag that stopped me but I fell for Vercel’s fonts and web design.
Investing in an implicit and inflexible routing pattern such directory based routing that was used when we didn’t have nice things is like being a rich hippie. Oh it doesn’t stop there. Isn’t it cool that you get to (jk, you HAVE TO) name your files like ‘[path-that-takes-arg].tsx’? You may think that I used brackets as a placeholder signifier, but I didn’t! Brackets are part of the filename and they indicate that this route takes params.
Look, we all tried and maybe had a little too much fun inventing and sometimes reinventing clever patterns we shouldn’t have, but few of us doubled down and just ran with it for so long.
Luckily, you can get around the pattern above pretty easily by just using the one route as a router file and adding your own indirection. Obviously you miss out a bit on tree-shaking and probably some other optimizations they designed to rely on their implicit conventions but your codebase remains greppable.
I’ve never used Next.js. To be honest, Express has always gotten the job done without too much hassle. In theory, what are the benefits of using Next.js over Express?
Shameless self-promotion, but I think people who agree here would enjoy my full-stack framework [1]. Just launched a new update that's much faster and has a lot more features. It was built for SaaS first, but works just as well for a traditional website. The ethos is "no rug pulls; it just works." Not the usual time waste of JS frameworks.
Folks will deal with all of this crazy stuff just to avoid using Ruby on Rails, Phoenix, Django, etc. Why? Is Next.js that much better for the user? I doubt it.
I've just convinced a large, but not global, client to move from their antiquated system to Next.js. They definitely wouldn't want to run on Vercel in prod since they're obsessed with costs.... and now I'm really concerned since this and some other "next.js in production nightmares" posts have dropped. I've only ever run smaller stuff on Vercel. Super concerned.
It rocks how Vercel has spent so much time and money on marketing Next.js that my product manager tried to tell me last year that I had to use it. In his mind we wouldn't be able to build our app correctly (an SPA that barely a couple hundred people use) or find developers since everyone uses and knows Next.js.
truly hate how hard these guys have made my job by making react popular.
I've found that as long as I don't try to use Next.js for fullstack applications I was ok. It is remarkably good at frontend only role. Since most of my applications were built with spa's in mind, I just use Nextjs primarily to consume the api. So yes, I don't experience a lot of this angst.
Middleware abstractions are challenging because third party libraries tend to abuse it and that can cause performance issues. Also, Vercel has optimized the middleware for its cloud business which includes various optimizations.
I don't see this as a major problem, since there are so many ways to work around it if you really don't like the tradeoffs.
imo, if docs never give a clear example of what something is for, that's a pretty good sign that this was just tacked on without considering any particular use case. i've come to realize that nextjs probably intends for us to use RSCs for most middleware-like behaviors
Just run production with the right flags so it'll log? Or put the app into local and try to replicate? The tone of voice is also completely off.
It seems Middleware in Next.js is not what Middleware is in framework X. This whole thread looks like a complete collection of misunderstandings of Next.js.
The real question is how the hell some circles were able to push such complexity onto mainstream tech and what will it take to prevent it from happening again.
A bit of a tangent, but how do you implement the feature when I highlight text on this blog, I get an option to generate a unique link directly to what I highlighted?
My conclusion is to use nextjs only for very simple projects. Problem is that simple projects grow and become important ones. So, just dont use nextjs at all.
I agree it’s pretty frustrating, but I do really like the SSR capabilities
I’m divide my frontend and backend via pikku, that way I can continue using normal server side functions but optionally spin up a seperate api service if needed.
Haven’t really tested it on vercel as much, but it ignores middleware on the nextJS side unless it’s for frontend code.
the interesting web problems (collaborative tools, creative software, scientific computing) have to fight against a framework ecosystem designed for the blandest landing pages.
Nextjs and most web frameworks assume you're building an e-commerce site that has to only differentiate on loading speeds.
we started a purely-frontend project with nextjs but moved to react-router pretty soon. Sure, it can be convenient (when it works), but you can't really see or understand how or how to control it, and black magic breaking is the least of what you want. Much happier now.
The app router is certainly challenging. This is why we stick to the page router and it works really well. There are some cases where the app router comes handy though.
Honestly, nextjs is not that bad and I would go as far as saying that it is perhaps the best web framework I have ever experienced but it does come with its own problems which might be overwhelming for beginners.
the App router move really killed it. The Pages router made so much sense, and was so intuitive. I have no idea why the team thought it was a good idea to completely abandon the fundamental innovation that made Next good in the first place.
Honestly I feel like this about the entire node/js ecosystem. Seems pretty cursed from top to bottom to me. And each attempt to un-curse it just adds more frameworks and layers and abstraction and new paradigms
just log your rest services only, not your view. nextjs is a view. it's a half on the server, half not on the server thingy. it would never be consistent anyway.
makes more sense to go full CRA though. it's just a view
Agreed. I've run into so many issues with documentation and sane defaults, and the Vercel team response is to always gaslight you into thinking you've done something wrong.
The truth is, its just poorly designed software.
Where it shines is batteries included for getting started. They realized if you have low activation energy requirements, you will win a critical mass of people who put up with your crap. A good metaphor for devtools overall.
Given all of the NextJS hate on here, I feel like I'll get downvoted for saying this...but we run Next.JS, don't host on Vercel - and really don't have many problems at all.
That being said, our app is largely built like a standard React app, we aren't using much server-side-rendering, and we use TanStack Query for loading most data. So, the main value of Next.JS is mostly just the routing and project organization.
NextJS as a framework is pretty good, it has gone downhill since the whole RSC shift sure but its still pretty good for most use cases. The problem however is Vercel and how closely its tied to Vercel.
I recently developed a small internal application in NextJS and we are using Azure PostgreSQL, we are on the Pro Plan from Vercel (honestly even that's an overkill, our use case would be satisfied easily on the free plan; which is very very generous) but one problem I faced is a NextJS App hosted on Vercel, it will never have a static fixed IP, so we couldn't directly access our database unless ofc we opened it to the entire world, which is never an option. This is so dumb honestly, the audacity to call it a full stack framework is stunning.
The feeling in the article is one i share. Frustration. It stems due to the rush job that is endemic to nextjs when it comes pushing out half baked features. It started with the app router.
Case and point
“Use server”
“Use client”
Intuitively, one runs on server and one on client. But you would be wrong. It is far more complicated. Now multiply this by 100 features. What you get is an obtuse hard to penetrate framework that seems to behave unpredictably unless you carefully read the thousands of pages of docs.
Now ai doesnt help as the api changes so frequently that it often spits out version 13 and not 14.5 let alone 15 or whatever is most recent.
This likely happens due to the need to rush features out for the next nextjs conf much like many other saas providers rush for their respective conf.
Most of the modern frontend ecosystem is infuriating. The early React + Typescript era was mildly upsetting but bearable, and it hinted at a relatively nice future if abstractions improved. Then Vercel et al threw that slow progress into an overpriced garbage can.
Well the thing that’s infuriating for me is feeling like there isn’t a good, well supported alternative for writing an enterprise grade React app that will be continue to be around. I used to rely on create-react-app, but now that that’s deprecated, I often find myself asking what else can I actually rely on? I don’t want to spend eng cycles dealing with webpack and stuff, this seems to be what the React team is endorsing so I guess I’m stuck?
Another thing I don’t know how to think about is the target market for nextjs seems to overlap with Ruby on Rails, a lot of e-commerce, media, etc. And most of these B2B apps I write are certainly not that…
Anything related to observability with Next.js is guaranteed to be a fucking nightmare. At work we'll typically implement a metrics endpoint for Prometheus - really trivial for just about every API or fullstack framework under the sun, except Next.js. I think I gave up at the point where the suggested method was using a custom server (negating some of Next.js's supposed benefits), or adopting Vercel's proprietary metrics service which wouldn't have helped us anyway. Terrible, terrible stuff - would never touch again.
I 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.
Seems like this is the natural evolution of web fullstack frameworks. I felt the same way about Rails when using it. You either die the hero or live long enough to become the villain!
Still love Next but it's because I drank the Kool aid early on. Would be intimidated to learn it anew in current state
Similar to Meteor.js, they've tried to abstract things that aren't really abstractable (is this even a word?).
It handles edge-cases extremely poorly, and when you have those scenarios, you either need to find a workaround (so code becomes ugly and painful to maintain) or give up.
I've worked with it for a project, gladly never again.
I'll extend my feedback about Node.JS backend. Look how many flavors: deno, bun... It's a mess.
Node.js a terrible platform for server-side in comparison to Java/C#(performance/stability) & Ruby/Python(dev speed).
The only reason it is successful is that everybody knows JS/TS. But just because everybody knows it is rarely a reason to use it.
The event loop is quite nice and easy to reason about, but that's all there's to it. It is single-threaded and comes with gotchas, with at the end being in my opinion a negative aspect of it.
Many other langs/platforms offer also an event loop for concurrency, but they aren't often used. In the end no matter how much we hate threads, they serve a great purpose that has been battle-tested for so many decades.
Unfortunately companies adopt programming languages based on hype and trends, rather than technical reasons.
Until when we will have people hyped up about writing web servers in CSS, even though it doesn't make any sense to?
TLDR: It isn't only Next.JS, but the whole NodeJS thing isn't that great.
I feel like I'm being gaslit every time nextjs is discussed. I picked it up and learned it for a couple different projects because clients heard about it and wanted it. I kept finding shit like this in the OP post, making issues, asking around about it, and being told by nextjs experts that I was Doing Everything Wrong. Fine, I'll deploy on vercel, but wait this client wants to try cloudflare edge because he knows the ceo and wants to pitch for his investment firm having better access or whatever tf, so I need to get it running on that, so now I can't use some xyz version of some library, and I have to use some bleeding edge version of nextjs and... etc.
Every day that went by I wondered if I was going insane for thinking we should just go back to building apps in straight vanilla javascript. Or like, just react SPAs pointing at fastapi apps deployed on s3, which has never failed me.
For the past 5 years, my main stack is Flutter+gRPC+Go, and I read articles like this in horror and satisfaction simultaneously.
For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and more layers of it.
Personally, I try to avoid using it as much as possible. And it works beautifully. Of course, tradeoffs are everywhere, and the sheer scale of the web development community has its own benefits. For example I miss the wide choice of alternative design systems in Flutter (compared to web), but hey, flutter now decoupling it's core from design systems in 2026. But the net effect of not using fundamentally flawed tools for your products is huge.
I felt seen after reading this post. NextJS was really good somewhere around v11 when it was first becoming stable and create-react-app was unusable. It's been rapidly enshittified since then.
You 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.
The most infuriating thing is that people still believe that you need isomorphic rendering (Next, Sveltekit, Nuxt) to have a fast, interactive and SEO friendly apps.
For all of you struggling with these modern frameworks (Next, Nuxt, Remix, TS start, etc, etc, etc)...
Don't waste your time.
They're all almost the same (crap), but the real issue is the instability of all of them. They change every week, they're constantly pushed sideways by the VCs or other interests behind them (or the constant mind change of their devs, i.e. React Router.. I mean Remix... I mean framework mode... I mean now we nap and then invent our own frontend framework but keep the old name, just to add a bit more to the confusion and keep everyone entertained).
They're overengineered, complex, and promote the little shiny "look how fast this counter updates in a type safe way" while they totally break down when you have to do real world serious stuff like authentication (ehh...go and use this SaaS..), authorization (ehh..what's that? just put an "if"), translations (who speaks other than english?..no need for that), background jobs or anything else a real world application needs. They're focused on the shiny "typesafe call server function" and everything else is just let on you to figure out, and good luck with the library you pick, because next week it's going to be a different one and you'll be out of fashion!
Many years ago I started using Inertia [1]. I'm confident to say it's the right, simple, most effective way to use React/Vue/Svelte. It's a super simple "protocol" with very thin adapters implementations that glue together your favorite frontend lib (react, vue, etc) with your favorite full stack backend framework (laravel, rails, django, adonis).
I've used it for client projects with both, Rails, Laravel and Adonis. I have no complaints about it. It works super well, follows a simple to understand model and you literally get the best of both worlds: a powerful frontend, and a powerful backend. It keeps things simple and stable using rock solid battle proven production ready building blocks with great documentation and community support.
I'm just done with all these other "meta frameworks". They're all marketing and hype and everyone is swallowing it and then ending up cornered with a terrible solution and a lots of problems they didn't account for and have no official or recommended solution to get out of it.
That won't happen if you use plain React/Vue. That won't happen if you use plain Laravel/Rails/Django/Adonis. Inertia just glues plain X + plain Y. No lock in. No possibility of being "stuck" in a situation where "I can't do X because...."... you can.. and you can in a very nice and clean framework-supported way.
It's a fantastic undervalued idea, and we're not paying enough attention to it (yet).
Don't fall for the marketing and the hype. Look for the simple and pragmatic solutions, they're there. They work. They're just not as hyped, so I'm hyping it up a bit for you in this post. Apparently that's what everything needs: Marketing.
Reading through all these comments gives me hope. Finally people are speaking up about what we have all been experiencing in isolation — the gradual enshittification of Vercel/Next.js in service of Vercel's business model.
The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that don't support Node.js APIs — these are all deliberate choices to push you toward Vercel's platform. Guillermo and his team have prioritized their cap table over the open web.
This is why I started https://github.com/openuiai/next.js last month. The web is humanity's greatest collaborative achievement. We are building toward a global, decentralized network that should enable unrestricted computation and storage for everyone. And for that to actually happen, we need frameworks with the power and flexibility that Next.js used to have. But instead we are all watching Vercel carve it up to lock developers into their platform
Next.js used to be great. Now it's a trojan horse for vendor lock-in. The fact that so many developers are comparing it to SharePoint and Lotus Notes should be a wake-up call.
To everyone frustrated: you are not wrong. The framework is ACTIVELY working against you unless you are on Vercel.
I'm working on OpenNext.js every single day — still climbing the learning curve of the massive spaghetti codebase, but fully committed. We are already running OpenUI on a fork with full Node.js middleware support and native WebSockets. These will merge into OpenNext.js once I have properly cleaned out the cruft (their CI/CD alone has cost me $400 just figuring out how to untangle it). But I'm taking the time to do this right.
Guillermo: Vercel/Next.js shouldn't dictate where we can deploy. It should respect the open nature of the web. You know this, but you chose the money instead.
I convinced myself to hate App Router before even trying it because of all the negative sentiment on HN.
After using it in three production-scale projects now, I think it's a great isomorphic JS / TS framework. It's as close to a "batteries included" (such as Rails or Phoenix) system that the JS ecosystem has.
And yet, people generally like to shit on Next.js I sense because they haven't taken the small amount of time investment required to actually just understand it: which I fear is especially true if they came from Pages Router. This kind of fallacy appears to hold true in the OP -- bemoaning that you "can't have multiple middlewares or chain them either"... yes, you can? Sure, it's different from the Express way of doing things, but you absolutely can get it to do what you want.
Was Express ever _that_ easy before you actually understood it and knew what you were doing?
as a Rails dev this makes me LOL. I would have expected the rube goldburg machine of JS frameworks to be more robust and ergonomic by now, but it looks more to be hacks built on top of hacks with no real vision or technical leadership.
Next.js is infuriating
(blog.meca.sh)1026 points by Bogdanp 2 September 2025 | 578 comments
Comments
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.
If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It’s also a somewhat advanced escape hatch.
Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention[2]
[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/i...
But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Laravel vs Symphony and it was the same thing: shit breaks once complexity comes in.
If you compare those solutions with the old model that made NodeJS / React SPA get so popular, so fast: Buffet-style tooling/libraries. You basically build your own swiss army knife out of spare parts. Since all the spare parts are self-contained they have to target really low abstraction levels (like React as a component library, HTTP+Express as a backend router, Postgres as DB).
This approach has many disadvantages but it really keeps things flexible and avoids tower-of-babel style over-engineering. As in a lot of layers stacked on top of each other. Not that the complexity goes away, but instead you have a lot of layers sibling to each other and it is more doable to replace one layer with another if things aren't working well.
It is understandable why "batteries included" is so popular, it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other. It definitely needs people with more experience to set up everything.
Surely this can't be right?
https://nextjs.org/docs/messages/nested-middleware > If you have more than one Middleware, you should combine them into a single file and model their execution depending on the incoming request.
By Talos, this can't be happening.
But whenever I work with Next, I feel like we lost the plot somewhere. I try a lot of frameworks and I like esoteric programming languages, but somehow Next.js, the frontier JavaScript framework embraced by React is the only experience where half the time, I have no idea what it’s error messages (if I get any to begin with) are trying to tell me. I can’t even count the hours I spent with weird hydration issues.
Aside from the abysmal middleware api you also have the dubious decision to replace having a request parameter with global functions like cookies() and headers().
Perhaps there is some underlying design constraint that I'm missing where all of these decisions make sense but it really does look like they threw out every hard fought lesson and decided to make every mistake again.
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.
Not Next though. We built a pretty large app on Next and it was painful from start to finish. Every part of it was either weird, slow, cumbersome or completely insane.
We still maintain the app and it is the only "thing" I hate with a passion at this point. I understand that the ecosystem is pretty good and people seem to be happy with the results given that it is extremely popular. But my own experience has been negative beyond redemption. It's weird.
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 the majority who prefer runtime errors over build-time errors.
So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the whole process, which is,
1. I am a seasoned developer, mainly doing python stuff, back-end servers, desktop applications, data applications, etc. Very little exposure to front-end tech.
2. I keep myself updated with the concepts, patterns & architecture of front-end systems, because I am extremely into design and good UI.
3. I am at a stage where I can do basic web apps with Vue, React, Angular & vanilla HTML and JS.
With Angular Signals and concept of Stores, Services and Dependency Injection, I am able to handle data flow very easily, am able to add features to the app in a consistent manner, able to debug and trace errors with relative ease.
I have earlier read NextJS docs, Remix Docs and read tutorials about developing react apps using Vite. It has always been a confusing maze of stuff. Perhaps I am getting old (about to touch 40), but I have been programming for about 25 years now and I was able to carve out the architecture I want in an Angular app with ease.
Also, this app is going to be a production app, and is critical for my work, so its an impactful decision, which, thankfully, I have been happy and pleasantly surprised with.
It could be that I could have chosen React, and end up with the same thing, but, somehow, in the extensive tech stack selection process that I took up before committing to Angular (which involved testing out core mechanisms of the application in React, Vue & Angular), I felt very much at home with Angular way of things.
The previous model was that you simply have code that runs on a server when a request comes in, sends a response to the client, and then the code in that response is run on the client. Instead, now we have a situation where some bits run on the server, some of them on the client, which call out to some bits on the server again, and all of this can happen either before or after the server started sending the response. And then on e.g. Vercel, you also have edge functions as an additional permutation.
Which is kinda neat, but also massively complicates the mental model.
This true to most software projects that are used more than one set of people. Joe Armstrong proposed a solution that we should opensource functions only and people could assemble everything else using these opensource functions. I start to think that he might be right and instead using "frameworks" we should use these set of functions instead.
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 choosing Next.js - would someone have any suggestions/pros and cons of what to use?
I currently see the options for doing SSR as:
- Next.js: well-represented in AI training data (though recent versions had breaking changes? I'm not sure), but annoying to actually use (according to this article/general sentiment I've found online), and pushes you into Vercel? (I barely know what that means)
- SvelteKit: best DX and nice to use, but might be less present in AI training data?
- Django templates + HTMX: possibly limiting? Less maintainable once you get to a certain size? I'm not sure.
- Other options?
You want to use something full of abstractions to the point you have no idea how it actually worked.
You did this to save time.
Then when issues occur it's someone else's fault.
That said, let me pass in a flag to get my dev logs in prod. That's ultimately what the author wants.
I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it.
The outcome was nicer and higher development satisfaction.
If you dare to say that you had to get rid of Nextjs from a particular project, during a job interview, you're done!
For me, it isn't a framework I want to use in any production environment. Your system is too much depending on something you have no influence on. Like in your own code, it is good to decouple, don't make things depend too much on something, not in your own code, but also on external code like frameworks and libraries.
That is why I prefer to build things like I can (kind of) easy drop my dependencies, for what reason, and use something else, or build it in my own codebase. If some framework doesn't allow it, and you have to work it their way, and is the base of everything, that should be a big red flag.
Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point.
What are the alternatives beyond Vite and Remix?
While Vercel acqui-hired many developers behind SvelteKit and Nuxt.js, I was under the impression that they weren't interested in running these projects hands-on, or even making them similar to each other. Can anyone correct me here or explain what their long-term game seems to be?
I have always developed backend apis in nodejs with express and used Nextjs for frontend only and just when I needed SSR.
Developing projects this way had always been a joy.
App router did change everything and destroyed the good reputation of Nextjs: it is hard to learn, to manage and does offer few concrete advantages
I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default.
Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.
Imho next attempts to do too much, moves too fast, every few months the wheel gets reinvented and never perfected.
I've wrote previously about nextjs: https://omarabid.com/nextjs-vercel My opinion remains the same: Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform.
Since their routing/SEO/content features are also now less functional, there is really very little reason to use Nextjs especially with React Server Components.
These days I do my best to stay in Rails land, far away from Next.js. It just looks like a cluster.
Wait, if you have issues with logging, why don’t you set up opentelemetry? It’s really easy to add into a project [1], and if you don’t want to manage it, you can easily find some cost efficient solutions like Grafana Labs [2].
[1]: https://nextjs.org/docs/app/guides/open-telemetry
[2]: https://grafana.com/
There are a lot of gotchas and considerations with Nextjs, but it is a framework and it is not unexpected that unless it is developed by yourself, frameworks require some getting used to.
There are some things that could be better, especially in non-Vercel-hosted scenarios, and if the backend for frontend part becomes too complicated, I would switch to Nest.js, but overall I am satisfied with Next.
It’s just a shame it’s Deno-only (although I completely understand why)
Long story short it's a proof of concept demo/exploratory project.
Currently, using Next.js app router, multi-root routes for stuff like (marketing), (app), (login), etc.
Db is Neon for the branching, will probably include Vercel AI SDK for AI stuff since its likely I'll be asked to include some AI functionality.
The only worry is I'm unsure with how this serverless layer/backend? interact with user authentication / authorization when used with the BetterAuth.
Currently hosting on Vercel, I feel like Next.js is married with Vercel for hosting. Although maybe because I'm unfamiliar with it, since Next.js made it quite simple and straightforward to do host quick proof-of-concepts on Vercel.
"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Margaret Mead
A big project becomes design by committee. If the initial kernel was sound, it can go on for quite some time. If it wasn't, it takes herculean effort to turn such a boat. And you will likely never be thanked for it.
Starting a new project to show people how it's done works as well or better than any amount of cajoling or badgering. But you still may not be thanked for it.
But in this case, I tried in earnest to use nextjs for a project with auth & stripe, etc. this past week, and I can't believe how frustrating it is to get stupid things like modal dialogs to work properly in the client.
I have tons of experience with React SPAs. But the client/server divide in Next remains quite inscrutable to me to the extent that I'm just going to start again with Django (where I nearly started it in the first place).
So yes, it doesn't work like I expect it to either...
There's no real alternative for these developers because they weren't brought up to understand server/networking fundamentals, how to operate a VPS, etc. Vercel manages to make this even more confusing for them by blurring the line between server and client, "edge" functions, etc, while all behind variable pricing.
Depending on the project, just write an SPA with an API server, or if it is a static website just prerender it and serve on Cloudflare. I don't get the appeal of all the complexity. If you need SSR for SEO, then SolidStart is a nice and simple solution.
Use .run.
If you picked NextJS without knowing how it structures its middleware, the vendor lock-in to Vercel, its SSR strategy, its hydration schemes etc. that's on you. I, and many others, have had a lot of success with NextJS increasing delivery speed and ultimately, customer value.
Two years ago I moved off of the React ecosystem to Elixir/Phoenix/LiveView, and it's been great. But that's had its own challenges stemming from the design decisions its creators have made. You're always going to be running into things that you don't like, and I feel NextJS has just become an easy target for people who are looking to vent.
Potential alternatives I've found:
Update: after some research, I really Tanstack router approach: https://tanstack.com/start/latestI also like the server side, PHP works better for me than a Javascript server. I've had some weird bugs with nodemon, pm2 and other server tools.
We had to choose a framework for our new app last year and were researching the current state of things. Next.js was / is by far the most popular, but also had some of the worst feedback and caution to stay away. Remix isn't perfect, but I appreciate less abstractions and working with simple request / response structures.
Also, a warning for those hiring for frontend / fullstack roles:
Over the years when hiring for roles for X frontend framework, we would constantly find "experts" in framework X that would really impress us. Whether it was React, Angular, Vue, Remix, etc. Then after moving forward, we found they didn't know core JS fundamentals and were basically useless beyond the framework.
Don't be scared by the complaints about previous breaking changes (which BTW are inevitable when we still haven't figured out the best approaches to the server/client app architecture) - React Router's current strategy using various flags [1] allows you to prepare for breaking changes well in advance.
[1] https://reactrouter.com/community/api-development-strategy
I suspect all these "all-in-one" JS frameworks out there unfortunately made people think that web apps are made of "one big happy javascript application, yay!" while it's really two (or even three) entirely decoupled runtimes (backend & frontend) instead.
This one has been the most over-hyped, vendor locked-in and completely vulnerability ridden web framework I have ever seen.
It's so much easier to hire people to do prioritisation (or deprioritisation) or code of conduct enforcement or whatever than to just do good work.
Seriously, give Elixir a shot.
Next.js is 8 years old and still under-documented, and you will still get lost if you veer off the beaten path - of which sometimes there is none.
Frankly, I was mad at myself for not recognizing the hubris and their ignorance of web dev history when I noticed that they brought back directory based path convention from the 90s. That should’ve been the red flag that stopped me but I fell for Vercel’s fonts and web design.
Investing in an implicit and inflexible routing pattern such directory based routing that was used when we didn’t have nice things is like being a rich hippie. Oh it doesn’t stop there. Isn’t it cool that you get to (jk, you HAVE TO) name your files like ‘[path-that-takes-arg].tsx’? You may think that I used brackets as a placeholder signifier, but I didn’t! Brackets are part of the filename and they indicate that this route takes params.
Look, we all tried and maybe had a little too much fun inventing and sometimes reinventing clever patterns we shouldn’t have, but few of us doubled down and just ran with it for so long.
Luckily, you can get around the pattern above pretty easily by just using the one route as a router file and adding your own indirection. Obviously you miss out a bit on tree-shaking and probably some other optimizations they designed to rely on their implicit conventions but your codebase remains greppable.
[1] https://cheatcode.co/joystick
truly hate how hard these guys have made my job by making react popular.
https://loglayer.dev/example-integrations/nextjs.html
Overall, the logging experience in Next.js is terrible, and not being able to chain middleware, even more so.
I don't see this as a major problem, since there are so many ways to work around it if you really don't like the tradeoffs.
imo, if docs never give a clear example of what something is for, that's a pretty good sign that this was just tacked on without considering any particular use case. i've come to realize that nextjs probably intends for us to use RSCs for most middleware-like behaviors
It seems Middleware in Next.js is not what Middleware is in framework X. This whole thread looks like a complete collection of misunderstandings of Next.js.
It's a bad framework for building full stack apps, but it's better than anything else.
https://x.com/paradite_/status/1941016421934551477
now that rather seems sane compared to next.js stuff n other javascript things.
if you gotta use typescript while not use java and at least benefit from the ecosystem of the jvm ?
for me I will stick with Rails - that's what I know
In python / bottle.py this would just be a print statement to stderr in before_request() or before_response(). One additional LOC.
got me good
That's fine. It works fine.
I don’t need/want to elaborate.
I’m divide my frontend and backend via pikku, that way I can continue using normal server side functions but optionally spin up a seperate api service if needed.
Haven’t really tested it on vercel as much, but it ignores middleware on the nextJS side unless it’s for frontend code.
https://pikku.dev/docs/runtimes/nextjs-app
Disclaimer: I’m the pikku core developer
These days vite is far far nicer.
Nextjs and most web frameworks assume you're building an e-commerce site that has to only differentiate on loading speeds.
Honestly, nextjs is not that bad and I would go as far as saying that it is perhaps the best web framework I have ever experienced but it does come with its own problems which might be overwhelming for beginners.
Why I'm writing pure HTML and CSS in 2025:
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
When I see Next.js on a job posting as a "requirement" or even as a "something we use" I immediately discard it
I have customers, but no tech problems.
makes more sense to go full CRA though. it's just a view
The truth is, its just poorly designed software.
Where it shines is batteries included for getting started. They realized if you have low activation energy requirements, you will win a critical mass of people who put up with your crap. A good metaphor for devtools overall.
That being said, our app is largely built like a standard React app, we aren't using much server-side-rendering, and we use TanStack Query for loading most data. So, the main value of Next.JS is mostly just the routing and project organization.
React Router + Express?
Or something else?
I recently developed a small internal application in NextJS and we are using Azure PostgreSQL, we are on the Pro Plan from Vercel (honestly even that's an overkill, our use case would be satisfied easily on the free plan; which is very very generous) but one problem I faced is a NextJS App hosted on Vercel, it will never have a static fixed IP, so we couldn't directly access our database unless ofc we opened it to the entire world, which is never an option. This is so dumb honestly, the audacity to call it a full stack framework is stunning.
Case and point
“Use server” “Use client”
Intuitively, one runs on server and one on client. But you would be wrong. It is far more complicated. Now multiply this by 100 features. What you get is an obtuse hard to penetrate framework that seems to behave unpredictably unless you carefully read the thousands of pages of docs.
Now ai doesnt help as the api changes so frequently that it often spits out version 13 and not 14.5 let alone 15 or whatever is most recent.
This likely happens due to the need to rush features out for the next nextjs conf much like many other saas providers rush for their respective conf.
Another thing I don’t know how to think about is the target market for nextjs seems to overlap with Ruby on Rails, a lot of e-commerce, media, etc. And most of these B2B apps I write are certainly not that…
Just to make single "log("hello") appear anywhere, in a file, in a console, as smoke puffs in the sky.
Infuriating, frustrating, agitating AF.
Turning off logging in a production system is brain damaged move because inevitably production is when you need it the most.
Still love Next but it's because I drank the Kool aid early on. Would be intimidated to learn it anew in current state
It handles edge-cases extremely poorly, and when you have those scenarios, you either need to find a workaround (so code becomes ugly and painful to maintain) or give up.
I've worked with it for a project, gladly never again.
I'll extend my feedback about Node.JS backend. Look how many flavors: deno, bun... It's a mess.
Node.js a terrible platform for server-side in comparison to Java/C#(performance/stability) & Ruby/Python(dev speed).
The only reason it is successful is that everybody knows JS/TS. But just because everybody knows it is rarely a reason to use it.
The event loop is quite nice and easy to reason about, but that's all there's to it. It is single-threaded and comes with gotchas, with at the end being in my opinion a negative aspect of it.
Many other langs/platforms offer also an event loop for concurrency, but they aren't often used. In the end no matter how much we hate threads, they serve a great purpose that has been battle-tested for so many decades.
Unfortunately companies adopt programming languages based on hype and trends, rather than technical reasons.
Until when we will have people hyped up about writing web servers in CSS, even though it doesn't make any sense to?
TLDR: It isn't only Next.JS, but the whole NodeJS thing isn't that great.
I find it infuriating how people don't utilise any TSC based compiler plugin codegen, to automate two way sync for database entities...
Millions lines of code, for nothing.
Every day that went by I wondered if I was going insane for thinking we should just go back to building apps in straight vanilla javascript. Or like, just react SPAs pointing at fastapi apps deployed on s3, which has never failed me.
For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and more layers of it.
Personally, I try to avoid using it as much as possible. And it works beautifully. Of course, tradeoffs are everywhere, and the sheer scale of the web development community has its own benefits. For example I miss the wide choice of alternative design systems in Flutter (compared to web), but hey, flutter now decoupling it's core from design systems in 2026. But the net effect of not using fundamentally flawed tools for your products is huge.
Don't waste your time.
They're all almost the same (crap), but the real issue is the instability of all of them. They change every week, they're constantly pushed sideways by the VCs or other interests behind them (or the constant mind change of their devs, i.e. React Router.. I mean Remix... I mean framework mode... I mean now we nap and then invent our own frontend framework but keep the old name, just to add a bit more to the confusion and keep everyone entertained).
They're overengineered, complex, and promote the little shiny "look how fast this counter updates in a type safe way" while they totally break down when you have to do real world serious stuff like authentication (ehh...go and use this SaaS..), authorization (ehh..what's that? just put an "if"), translations (who speaks other than english?..no need for that), background jobs or anything else a real world application needs. They're focused on the shiny "typesafe call server function" and everything else is just let on you to figure out, and good luck with the library you pick, because next week it's going to be a different one and you'll be out of fashion!
Many years ago I started using Inertia [1]. I'm confident to say it's the right, simple, most effective way to use React/Vue/Svelte. It's a super simple "protocol" with very thin adapters implementations that glue together your favorite frontend lib (react, vue, etc) with your favorite full stack backend framework (laravel, rails, django, adonis).
I've used it for client projects with both, Rails, Laravel and Adonis. I have no complaints about it. It works super well, follows a simple to understand model and you literally get the best of both worlds: a powerful frontend, and a powerful backend. It keeps things simple and stable using rock solid battle proven production ready building blocks with great documentation and community support.
I'm just done with all these other "meta frameworks". They're all marketing and hype and everyone is swallowing it and then ending up cornered with a terrible solution and a lots of problems they didn't account for and have no official or recommended solution to get out of it.
That won't happen if you use plain React/Vue. That won't happen if you use plain Laravel/Rails/Django/Adonis. Inertia just glues plain X + plain Y. No lock in. No possibility of being "stuck" in a situation where "I can't do X because...."... you can.. and you can in a very nice and clean framework-supported way.
It's a fantastic undervalued idea, and we're not paying enough attention to it (yet).
Don't fall for the marketing and the hype. Look for the simple and pragmatic solutions, they're there. They work. They're just not as hyped, so I'm hyping it up a bit for you in this post. Apparently that's what everything needs: Marketing.
[1] https://inertiajs.com/
The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that don't support Node.js APIs — these are all deliberate choices to push you toward Vercel's platform. Guillermo and his team have prioritized their cap table over the open web.
This is why I started https://github.com/openuiai/next.js last month. The web is humanity's greatest collaborative achievement. We are building toward a global, decentralized network that should enable unrestricted computation and storage for everyone. And for that to actually happen, we need frameworks with the power and flexibility that Next.js used to have. But instead we are all watching Vercel carve it up to lock developers into their platform
Next.js used to be great. Now it's a trojan horse for vendor lock-in. The fact that so many developers are comparing it to SharePoint and Lotus Notes should be a wake-up call.
To everyone frustrated: you are not wrong. The framework is ACTIVELY working against you unless you are on Vercel.
I'm working on OpenNext.js every single day — still climbing the learning curve of the massive spaghetti codebase, but fully committed. We are already running OpenUI on a fork with full Node.js middleware support and native WebSockets. These will merge into OpenNext.js once I have properly cleaned out the cruft (their CI/CD alone has cost me $400 just figuring out how to untangle it). But I'm taking the time to do this right.
Guillermo: Vercel/Next.js shouldn't dictate where we can deploy. It should respect the open nature of the web. You know this, but you chose the money instead.
After using it in three production-scale projects now, I think it's a great isomorphic JS / TS framework. It's as close to a "batteries included" (such as Rails or Phoenix) system that the JS ecosystem has.
And yet, people generally like to shit on Next.js I sense because they haven't taken the small amount of time investment required to actually just understand it: which I fear is especially true if they came from Pages Router. This kind of fallacy appears to hold true in the OP -- bemoaning that you "can't have multiple middlewares or chain them either"... yes, you can? Sure, it's different from the Express way of doing things, but you absolutely can get it to do what you want.
Was Express ever _that_ easy before you actually understood it and knew what you were doing?
Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.