Comment by YuukiRey
1 month ago
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.
I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase.
Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly.
Infinite complexity everywhere, breaking changes CONSTANTLY, impenetrable documentation everywhere.
It is just so, so awful. If we rewound the last five years of FE trends and instead focused on teaching the stuff that existed at the time properly, we'd be in a much better position.
I've also built a very complex React frontend (few thousand users, pretty heavy visual computation required in many places). And while I don't particularly like React either, Next.js was even worse.
And lastly, built a CMS in Go, with vanilla JS. And while the DX sometimes feels lacking, I just can't help but feel that I actually know wtf is going to happen when I do something. Why is that so hard?
In React and Next.js I am STILL, AFTER SIX YEARS constantly guessing what might happen. Yes, I can fix just about anything these frameworks throw at me, thanks to all the experience I've gathered about their quirks, but it all just feels to messy and badly designed.
In Go, the last time I guessed what might happen was in the first six months of learning it. No surprises since. Codebases from years ago are still rock-solid.
Why can't we do this at the frontend, goddammit?
" Codebases from years ago are still rock-solid." This is the biggest thing for me. I recently pulled down an 8 year old hobby Java/Maven project I had and it compiled and ran perfectly on the first try. Imagine trying to get an 8 year old javascript project to work...
At my previous startup (co-founder who made all technical decisions) we were unfortunately stuck with React Native. I had Mondays that started with the project not building after some dependency changes. Imagine something failing to build 3 days after you've last touched the codebase…
Just did, I installed the version of node specified somewhere, codified it into mise, and was up and running in no time.
You mean like this?
nvm use && npm i && npm run dev
5 replies →
[dead]
I think the big complex FE frameworks are going to go away. After doing work with HTMX and Alpine JS, and Ruby on Rails with Turbo + Stimulus, I am all in on this paradigm. Basic JS, or a micro front end framework is all you really need.
it might be a bit over the top but there is Cogent Core[0]; it supports apps on desktop, mobile apps, and the web. it even supports 2d and 3d. and it's all in go, backend and frontend (using WASM).
[0] https://github.com/cogentcore/core
As much as I hate Next.js as the next guy, let's please not push full canvas rendering approaches. They SUCK. Their https://www.cogentcore.org/core/ own site is slow to load, scrolling is visually painful since it render at what I assume is 60Hz and not my native much higher monitor refresh rate. They are expensive in terms of computation, wasting resources on the machine, to display text. Want to select text, better hope the developers want you to be able to select text or didn't forget to do so, case in point text inside buttons. Accessibility is also usually much weaker, screen readers often suffer and if they don't something else will.
Canvas instead of DOM -> :(
EDIT: Gave it another try and more issues appear, within seconds of using. The left side has a rendering bug where the selected areas are cut off sometimes, ctrl+zoom does not zoom the page as it does on all normal websites. I can still zoom via menu. Middle mouse open link in new tab doesn't work. Z layer bugs everywhere. I expect more the longer I'd look.
1 reply →
wow this is bad! like truly bad UX. please don't recommend this.
I typed "0" into the scaling field to see how it handled it, and couldn't recover from there...
it's completely shit
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
Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it should run anywhere!' and I took a run at it.
After a week of futzing with it I just threw up my hands and said 'no can do'. I couldn't untangle the spaghetti JS and piles of libraries. 'Compiling' would complete and if you looked at the output it was clearly missing tons of bits but never threw an error. Just tons of weirdness from the toolchain to the deployment platform.
I haven't heard anything about trends, stereotypes, positives, and negatives regarding IT and development in Africa. Following HN's guideline to increase curiosity as topics get more divisive (as this subthread has), and looking for "the strongest plausible interpretation of what someone says" I'm going to assume the best:
What's the story here? I assume this group was chosen for a reason and didn't meet expectations.
5 replies →
Why accept the result? Send it back and have them deliver something usable.
3 replies →
[flagged]
4 replies →
Fun anecdote: last time I needed to build a quick full stack app for a silly little project that my friend needed, I thought “it only needs to be up for a few months, so I’ll just use the next.js starter and throw it on vercel and be done”. I’d used vercel + next once before and thought it was easy.
Open up vercel, point it at my repo, and environment variable, it starts building and… build error. I search up the strange error log on the next issues page, and find a single issue from 3 years ago with one upvote and no response or resolution.
So I threw it on a VPS and just built it with whatever the “prod build” command is, and it totally worked fine.
So in my limited anecdotal experience, hosting it on vercel won’t save you either lol
> 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 feel the whole React ecosystem might have ended up being captured by a corporation. Hopefully it wasn't. Let's see.
It’s already been captured. Check out the docs for creating a new React app on react.dev:
https://react.dev/learn/creating-a-react-app
It throws you straight at Next.js
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)
3 replies →
Looking at history, many popular frameworks have been "captured by a corporation" or in the case of React (FB) and .NET (MS), created by one. We mere SEs ride the wave of corporate whims, but everyone knows if and when they tighten the noose too hard everyone will move on to the next hot new thing.
Which is why I actually love sveltekit considering that its really easy to self host it / host it anywhere serverless. I hosted it on cloudflare. Though I do feel that everyone is pushing nextjs in the llm space and llm's are more comfortable with next instead of sveltekit but they can still do some mind boggling things in sveltekit and I love them while using sveltekit itself
Svelte is financed by vercel, so who knows if sveltekit drifts in the same direction.
4 replies →
The author's examples of rough edges are however no better when hosted on vercel. The architecture seems... overly clever, leading to all kinds of issues.
I'm sure commercial incentives would lead issues that affect paying (hosted) customers to have better resolutions than those self-hosting, but that's not enough to explain this level of pain, especially not in issues that would affect paying customers just as much.
I agree, but I suspect the cleverness is part proprietary behaviour, part having a monstrosity that only runs as intended on their own infra
I feel like that describes a whole bunch of "FOSS-project-backed-by-consulting-company" packages. You want it to be good enough to become industry standard, but painful enough to figure out on your own that anyone with the budget will just pay the developer to do it for them.
Same. Feels like it's a lure into a vendor lock
Better use something else
Not a web developer, but I do small web projects from time to time.
I heard this excuse for Next.js and thought I’d get around it by using Vercel, which was fine for my project. It didn’t seem to make a difference.
[dead]
> 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.
Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here we are.
The train of thought is “what is everyone using? I’ll use that too”
This coupled with the fact that "web development" now means anything going from a content rich website like a blog, towards some e-shop, all the way to complex applications like ux design, video editing, etc.
It's pretty absurd to have such a broad range of web solutions, and think the same solution can cover everything.
6 replies →
> The train of thought is “what is everyone using? I’ll use that too”
I'm not so sure about that. We're seeing Next.js being pushed as the successor of create-react-app even in react.dev[1], which as a premise is kind of stupid. There is something wrong definitely going on.
[1] https://react.dev/learn/creating-a-react-app
20 replies →
If everyone made decisions for themselves instead of following everyone else we’d be so much better off, in all areas.
1 reply →
This is only partially true. For example, with React Native even the core team now tells you to "just use Expo", as if relegating all responsibility to a project maintained by a for-profit that thinks 2 weeks is enough time to beta test a Major release.
It's also dismissive of market forces, i.e. developers have to pay bills and therefore are easier to hire if they know the skillset that is in wide use.
I've never worked or interviewed a single senior that wanted to use Next.
Second worst for me. I’ve used Sharepoint.
Third worst if you have used Lotus Notes mail. I still don't understand how an email and calendar client can slow down a computer like that (going by memory, the last time I used it was at work in 2013 so pre-SSD days).
Everyone at IBM when I worked where used Fetchnotes (internal tool that leaked onto the internet that wraps Lotus notes .so file and allows you to use normal email / contact / calendaring programs and formats).
Well... I don't know exactly what the OP meant by "technology", but Notes at least wasn't supposed to be a development platform.
It surely was a development platform, but wasn't supposed to be one.
1 reply →
You just reminded me of the nightmare Lotus Notes was.
What do you mean you don't want to step through scripts with a debugger just to understand how to use the official APIs? I'm sure it's better these days, but Sharepoint was one of the platforms I worked with when I was younger and it still gives me bad flashbacks whenever it comes up.
I remember a few early projects that revolved around SP, but one that stands out as "special" was using the SOAP APIs to update a WordPress site. It was a special hell, every hour it would fetch any updates, and push them to the specific WP content-type (iirc - content-types might not have existed yet - this was 2008).
The reason for this, IT had contracted for a content management system from a Microsoft shop, because the CIO was a former Accenture/Avanade consultant. But the brochure-ware website had already been contracted to some random NYC-based web firm, but the CIO didn't want multiple usernames/passwords, so after the WordPress site hand been build, they hired the SharePoint consultants to build out the CMS that the employees would use, but it still didn't hook up to wordpress, so then it became another contractor's job (me) to join the two.
I had worked on Word Press, I even had a few decently popular plugins, but I had never seen the absolute hellscape that was SharePoint before. I wrote a codegen tool that would read the WSDL and create a library with all the classes and calls needed to use it without any SharePoint experience, and wrote some simple ETLs for the handful of "buckets". It was a 2-3 month long journey, but those libraries and my code are still in place today, where they still use wordpress for front-end, and sharepoint as backend (or at least did in 2022 still, the last I talked to anyone still working there).
Some people get my hatred for Teams, and some people don't. Most of the ones who do had to use Sharepoint at some point, and can see its pointy little horns sticking out of Teams.
No one will understand until they’ve seen it with their own eyes.
You have my sympathy.
To me, Sharepoint feels like it's not sure what it's supposed to be, so it tries to be everything, and so feature creep has run so rampant that it's just an utter mess with awful performance.
To me, Sharepoint feels like it was vibe coded by the first primitive coding agent, and then made worse over time.
I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity.
I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router).
Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it. My marketing site is entirely static, and my app is entirely client rendered.
I also use next and use the pages router. Makes for a development friendly react front end.
And I have some use cases where I want to have a headless crm/api “hidden” behind the front end. So in these cases using next as a backend proxy works well for me.
I regret “upgrading” my personal site to app router. Big mistake esp for is an almost purely static site.
Sadly tan stacks releases a new version every other day and react router was complete 5 versions ago but cannot seem to keep changing the api to stay relevant in the never ending js relevancy ending war.
I would recommend React Router over Tanstack. I tried both and RR was so much easier and more reliable.
Tanstack seems to be following Next.js in that they’re just over complicating everything and their docs felt lacking for the most of their features.
I've only ever used Tan's React-Query and I absolutely love it inside of a React codebase.
https://tanstack.com/query/v5/docs/framework/react/overview
Why're trying to move off next? What makes the opportunity cost worth it?
Looking for full control over where the frontend is hosted. Sure, I can run Next.js elsewhere, but I could also run React Router elsewhere and have a much better overall experience in the process.
2 replies →
Yes, and even if you manage to work around its profoundly silly limitations—seriously who designed the new routing nonsense and have they ever made a website before—every time you go to upgrade the new version breaks everything.
By comparison, DIY SSR with Express takes a few days to get working and has run quietly for multiple projects for years on end.
Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too.
I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way, you'll end up with next.js alike piles of reinvented wheels and abstractions (that in the end are always leaking anyway)
>Windows doesn't (didn't?) have ENV vars
Nope, windows has had perfectly standard environment variables since the DOS days
What's "missing" is the ability to launch things the "Bash" way: `KEY=value ./myApp`. Where the variable is scoped to the single execution.
Windows' command prompt requires two separate invocations:
PowerShell also:
Or more "verbosely/explicitly":
Regardless, all those methods aren't "scoped".
6 replies →
> because Windows doesn't (didn't?) have ENV vars.
As long as I can remember in my career, Windows had environment variables. So that's at least 25 years. It's both available to view/edit in the GUI and at the prompt.
Damn, I didn't know someone could be so clueless about Windows or operating system history in general. What the hell do they teach in computer science these days
Port detection? Thread management? These things have nothing to do with next.js right?
Windows has had envvars since before Linux existed. It also has FindFirstChangeNotification (or ReadDirectoryChangesW if you hate yourself) since before inotify existed, etc.
Windows has pretty much everything you can dream of (although sometimes in the form of complete abominations), it's just that the people employed by Vercel don't give a shit about using native APIs well, and will map everything towards a UNIX-ish way of doing things.
My point was not that windows doesn't have Inotify (or the other stuff) but that it does it different to Unix.
Or, if you insist, that Unix is inconsistent with how windows does it.
Which is what those wrappers and abstractions do: they expose a single api to e.g. detect file changes that works with inotify, readdirectorychanges, etc.
This seems to ignore the possibility of Windows having done them in a UNIX-ish way to begin with, which would be infinitely better than what Microsoft came up with.
1 reply →
My biggest problem with it now is the official React team pushes it as their framework of choice. Back when it used the Pages Router and wasn't trying to push everything into server components, etc., it wasn't terrible but I can't help but feel bad for any newcomers trying to learn web development.
I switched to Astro from Next for most projects and haven't looked back. It's such a breath of fresh air to use.
Next.js was a godsend when it came out because of how easy it made SSR. Many React projects don't need SSR, but for those that do it was technically complicated and time-consuming to hand-roll it.
I was part of a successful large project where we did our own SSR implementation, and we were always tinkering with it. It wasted a lot of time. Next.js "just worked". I've used Next with the pages router on two significant and complex projects and it was a great choice. I have no regrets choosing it.
The most frustrating thing about Next.js is that it tries to be a really cool Rails/Wordpress/Meteor-like full-stack everything-and-the-kitchen-sink framework, but you quickly realize that all the opinions you delegate for it to make are, like, the most boring possible things it could choose to take opinions on (e.g. its opinions about middleware, image resizing, SSR-everywhere, etc) while the actually productive opinions it could take it leaves to you (database, ORM, communication protocols). Its not remotely in the same realm as Rails/Wordpress/Meteor.
Framework-defined infrastructure is a seriously cool and interesting idea, but nowadays Next feels more like an Infrastructure-defined framework; the Vercel platform's architecture and design are why things in Next are the way they are. It was supposed to be "Vercel adapts to Next", but instead we got four different kinds of subtly different function runtimes. My usage dashboard says my two most-used things are "Fluid Active CPU" and "ISR Writes". I just pay them $20/mo and pray none of those usages go over 100% because I wouldn't have the first clue why I'm going over if it does.
Half the labels on there are Star Trek technobabel, which I would take the effort of learning, except I'm convinced they're all going to change with the next major release anyway. Partly because, I keep hoping & praying they will. I know a concerning number of former die-hard Zeit fans who've taken their projects and customers elsewhere. At the end of the day, if they were to ask me what they need to address in the next major release, I seriously do not know how to answer that question beside "practically every major and minor decision y'all have made since and including the App Router was the wrong one". How do you recover from that? Idk.
Sounds like Javascript's answer to Spring.
Java Spring is at root a way to combine large software components (singletons) together in a controlled manner (dependency injection). It doesn't really have an opinion on what you do with it, or even if you use it for webapps. In fairness the Servlet API (which predates Spring) was and always has been really good (which is why it's still the foundation of everything webapp in the Java ecosystem). Oddly enough, logging in Java was a mess but became really good when slf4j and logback became the de facto standard. The OP's problem is trivial in Java, Spring, Spring Boot, or Dropwizard.
Java doesn't offer isomorphic React SSR, but in most cases that is a questionable feature. Most SPAs don't need or want search-engine indexing or require instantaneous-seeming load times.
Best explanation of spring I have ever read.
And while Spring has it's rough edges and quirks it is still an incredibly stable framework. Next, on the other hand, is a box of surprises that keeps on giving even when you think you saw it all.
Spring Boot pulls in countless dependencies without warning. It can generate classes without you asking it to. It will run code just because you added a dependency, even if you don't explicitly call it. A lot of functionality is action-at-a-distance activated through annotations, which could just as easily be simple method calls which are easier to trace and debug. Version updates are aggressive about making breaking changes, sometimes seemingly for aesthetic reasons.
It just adds a lot of complexity even if you don't explicitly opt in to it or need it.
1 reply →
That would be Nest, not Next. A true abomination.
I'm a bit surprised at reading that. I've tried both, Next left a bad taste in my mouth, but Nest was kinda neat. Didn't used it for anything too complicated though, so I'm curious about what sort of grievances people have against Nest.
1 reply →
I needed to move something. By a few pixels. I spent about 4 hours learning about hydration and somewhere in my source there's a note about why I can't move the thing and how I'm working around it.
What did you use instead?
People will complain about Next but there is no perfect solution. The complexity driving the problems with Next materialize in other forms elsewhere. Remix is a competitive option with its own quirks. You can always roll your own with Vite, Tanstack router, etc. but then of course you're manually implementing the same stuff albeit better suited to your needs. Which isn't necessarily bad but it's not the right choice for everyone.
The perfect solution is to use React for the frontend (where its main purpose and strengths lie) and use something like PHP, Java, ruby or whatever for the backend.
This insanity of server side react introduces all kinds of unnecessary quirks.
Also, the VC-funded Vercel is of course purposely dumbing down Next.js, so that everyone pays them. Its a trap everyone should be aware of.
5 replies →
Lightweight native web components rendered on the light dom with lit-html and a simple API layer in express 5 is about as close to perfect as I've ever found.
The only "weakness" is that it doesn't have guard rails, so may not be great for larger teams with mixed experience.
It's hard for me to give a blanket answer to this. I tend to mostly work on services that offer GraphQL APIs these days, and not so much on client side rendering. For APIs I stick with Go because it's what I'm most familiar with. But I'd also be happy to work on a Django or FastAPI service. Anything is fine really, as long as it's mostly boring technology.
If I had to create something that has a UI I'd just go with a bog standard server rendered multi page app, built using really boring technology as well. If you like Javascript and friends, go with Express. Nowadays you can run Typescript files directly and the built-in test runner is quite capable.
If a single page application makes sense, then go with vanilla React. For a highly interactive application that's potentially behind a log in anyway, you probably don't need React Server Components.
I've really been loving Astro lately, it's simple enough that it stays out of your way and you can host it yourself easily. Gives you nice backend + frontend with the option to drop in React, Vue, Angular, etc if you need them.
react-router if you just want a simple React frontend, write your backend in something else.
Not OP but FYI React Router v7 (fka "Remix") has all the key features of Next.js but none of the bloat or Vercel-driven enshittification.
My personal experience is Remix has all kinds of problems akin to the issues in the blog post, including the mess that is remix -> react router v7. When I worked with Remix a year ago logging and middlewares were also a disaster. For example it didn't have middlewares, and had no way to create a LocalContext from the host (e.g. Express or whatever you use) that first starts handling the request down through the remix app.
I also had the impression they would probably follow the Vercel style, framework as a business model, with it being sold to Shopify.I don't really know where it's all going, but it is not the sort of thing I would tie myself to.
Except when they ship v8 and you'll be forced to restructure your app to the whims of the library creators in case you need to update.
Hono
This. It's what inspired me to build a static site generator and web framework built from first principles: https://mastrojs.github.io
> Next.js is easily the worst technology I've ever used.
To be fair, this is partly on the kind of people who use it. E.g. if you're trying to build something that's intended to last for 10+ years but you don't think it's worth it to spend the 20 hours watching the Udemy course on Angular, then your technology is going to be a complete dumpster fire no matter which stack you choose.
What is frustrating is that like 3 or 4 major versions ago Next.js was the best thing since sliced bread.
It's almost like the channeled the same problems and bad juju that plagued ext.js.