8 ms·

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 gene

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.

christophilus 1y ago
Second worst for me. I’ve used Sharepoint.
- mcny 1y ago
  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).
  - marcosdumay 1y ago
    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.
    - YuukiRey 1y ago
      I should have been more specific here indeed. I meant more library or framework, not technology in the broader sense. My apologies.
  - codegeek 1y ago
    You just reminded me of the nightmare Lotus Notes was.
  - nailer 1y ago
    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).
- Etheryte 1y ago
  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.
  - jermaustin1 1y ago
    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).
- rhubarbtree 1y ago
  No one will understand until they’ve seen it with their own eyes.
- VenturingVole 1y ago
  You have my sympathy.
- Sohcahtoa82 1y ago
  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.
  - christophilus 1y ago
    To me, Sharepoint feels like it was vibe coded by the first primitive coding agent, and then made worse over time.
- hinkley 1y ago
  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.
berkes 1y ago
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)
- rcxdude 1y ago
  >Windows doesn't (didn't?) have ENV vars Nope, windows has had perfectly standard environment variables since the DOS days
  - colejohnson66 1y ago
    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: set KEY=value ./myApp PowerShell also: $env:KEY='value' ./myApp Or more "verbosely/explicitly": [System.Environment]::SetEnvironmentVariable('KEY', 'value') ./myApp Regardless, all those methods aren't "scoped".
    - amonith 1y ago
      eh `cmd /C "set KEY=value && ./myApp"` isn't that bad if you really need complete isolation.
      - RaptorJ 1y ago
        or directly in powershell, `Start-Process myproc.exe -Environment @{ FOO = 'bar' }`
        Sohcahtoa82 1y ago
        What an absolutely awful syntax. How Powershell ever got popular is beyond me.
lysecret 1y ago
What did you use instead?
- YuukiRey 1y ago
  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.
- chrisweekly 1y ago
  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.
  - aswerty 1y ago
    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.
  - mm263 1y ago
    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.
zero_shift 1y ago
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
- hoppp 1y ago
  Same. Feels like it's a lure into a vendor lock Better use something else
- motorest 1y ago
  > 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.
  - lubujackson 1y ago
    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.
  - zero_shift 1y ago
    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)
    - Silhouette 1y ago
      Yes - there's been a very obvious shift in the "official" React positions over the last 2-3 years. It's regrettable that they have moved so sharply away from the simplicity and "doing one thing well" philosophy that made React so successful in the first place. I've used React since those early days and built successful, long-lived projects with it so I'm genuinely sad to see it fall so hard. Objectively that sadness does not change reality however. At least within my own professional network no-one seems comfortable starting a new project using React today. Almost 100% of the paid front end work I've been involved with myself or discussed with others recently is now using alternatives - most often Vue though I've seen other choices at least seriously considered. I've even had a couple of recruiters I haven't worked with for years suddenly reappear desperately looking for someone to take on React work and openly admit it's because they are struggling to find anyone good who wants to go near it. All of this is a sharp contrast with the market of the early 2020s when React was clearly the preferred front end choice. And all of this is surely a direct response to the push to make React a full stack framework, the added complexity that has introduced, and the apparent capture of official React development by Vercel.
motorest 1y 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. 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.
- felipeccastro 1y ago
  The train of thought is “what is everyone using? I’ll use that too”
  - gigatree 1y ago
    If everyone made decisions for themselves instead of following everyone else we’d be so much better off, in all areas.
    - nightski 1y ago
      This is a little disingenuous because unfortunately you can't make decisions on technical merits alone. It takes a lot of resources to keep these projects thriving and up to date. You almost have to go with options where these resources have been deployed, even if they are terrible sometimes.
  - koonsolo 1y ago
    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.
    - fragmede 1y ago
      Why? Microsoft's GUI framework as well as Apple's covered plenty of use cases before the rise of the web browser.
rozenmd 1y ago
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.
- bodhi_mind 1y ago
  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.
- 16mb 1y ago
  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.
  - eYrKEC2 1y ago
    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 https://tanstack.com/query/v5/docs/framework/react/overview
- fragmede 1y ago
  Why're trying to move off next? What makes the opportunity cost worth it?
  - rozenmd 1y ago
    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.
coffeefirst 1y ago
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.
jimbokun 1y ago
Sounds like Javascript's answer to Spring.
- thr0w 1y ago
  That would be Nest, not Next. A true abomination.
  - mablopoule 1y ago
    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.
    - Aeolun 1y ago
      Something, something enterprise software. I find its dependency injection harder to reason about.
- simpaticoder 1y ago
  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.
  - theflyinghorse 1y ago
    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.
throwaway77385 1y ago
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?
- ecshafer 1y ago
  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.
- tankenmate 1y ago
  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 https://github.com/cogentcore/core
  - Voultapher 1y ago
    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/ 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.
nailer 1y ago
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.
rpcope1 1y ago
It's almost like the channeled the same problems and bad juju that plagued ext.js.
avdwrks 1y ago
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.
- signaleleven 1y ago
  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.
Alex3917 1y ago
> 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.
827a 1y ago
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.
Aeolun 1y ago
What is frustrating is that like 3 or 4 major versions ago Next.js was the best thing since sliced bread.
mb2100 1y ago
This. It's what inspired me to build a static site generator and web framework built from first principles: https://mastrojs.github.io https://mastrojs.github.io

christophilus 1y ago

Second worst for me. I’ve used Sharepoint.

mcny 1y ago
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).
- marcosdumay 1y ago
  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.
  - YuukiRey 1y ago
    I should have been more specific here indeed. I meant more library or framework, not technology in the broader sense. My apologies.
- codegeek 1y ago
  You just reminded me of the nightmare Lotus Notes was.
- nailer 1y ago
  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).
Etheryte 1y ago
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.
- jermaustin1 1y ago
  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).
rhubarbtree 1y ago
No one will understand until they’ve seen it with their own eyes.
VenturingVole 1y ago
You have my sympathy.
Sohcahtoa82 1y ago
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.
- christophilus 1y ago
  To me, Sharepoint feels like it was vibe coded by the first primitive coding agent, and then made worse over time.
hinkley 1y ago
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.

berkes 1y ago

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)

rcxdude 1y ago
>Windows doesn't (didn't?) have ENV vars Nope, windows has had perfectly standard environment variables since the DOS days
- colejohnson66 1y ago
  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: set KEY=value ./myApp PowerShell also: $env:KEY='value' ./myApp Or more "verbosely/explicitly": [System.Environment]::SetEnvironmentVariable('KEY', 'value') ./myApp Regardless, all those methods aren't "scoped".
  - amonith 1y ago
    eh `cmd /C "set KEY=value && ./myApp"` isn't that bad if you really need complete isolation.
    - RaptorJ 1y ago
      or directly in powershell, `Start-Process myproc.exe -Environment @{ FOO = 'bar' }`
      - Sohcahtoa82 1y ago
        What an absolutely awful syntax. How Powershell ever got popular is beyond me.

lysecret 1y ago

What did you use instead?

YuukiRey 1y ago
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.
chrisweekly 1y ago
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.
- aswerty 1y ago
  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.
- mm263 1y ago
  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.

zero_shift 1y ago

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

hoppp 1y ago
Same. Feels like it's a lure into a vendor lock Better use something else
motorest 1y ago
> 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.
- lubujackson 1y ago
  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.
- zero_shift 1y ago
  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)
  - Silhouette 1y ago
    Yes - there's been a very obvious shift in the "official" React positions over the last 2-3 years. It's regrettable that they have moved so sharply away from the simplicity and "doing one thing well" philosophy that made React so successful in the first place. I've used React since those early days and built successful, long-lived projects with it so I'm genuinely sad to see it fall so hard. Objectively that sadness does not change reality however. At least within my own professional network no-one seems comfortable starting a new project using React today. Almost 100% of the paid front end work I've been involved with myself or discussed with others recently is now using alternatives - most often Vue though I've seen other choices at least seriously considered. I've even had a couple of recruiters I haven't worked with for years suddenly reappear desperately looking for someone to take on React work and openly admit it's because they are struggling to find anyone good who wants to go near it. All of this is a sharp contrast with the market of the early 2020s when React was clearly the preferred front end choice. And all of this is surely a direct response to the push to make React a full stack framework, the added complexity that has introduced, and the apparent capture of official React development by Vercel.

motorest 1y 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. 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.

felipeccastro 1y ago
The train of thought is “what is everyone using? I’ll use that too”
- gigatree 1y ago
  If everyone made decisions for themselves instead of following everyone else we’d be so much better off, in all areas.
  - nightski 1y ago
    This is a little disingenuous because unfortunately you can't make decisions on technical merits alone. It takes a lot of resources to keep these projects thriving and up to date. You almost have to go with options where these resources have been deployed, even if they are terrible sometimes.
- koonsolo 1y ago
  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.
  - fragmede 1y ago
    Why? Microsoft's GUI framework as well as Apple's covered plenty of use cases before the rise of the web browser.

rozenmd 1y ago

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.

bodhi_mind 1y ago
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.
16mb 1y ago
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.
- eYrKEC2 1y ago
  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 https://tanstack.com/query/v5/docs/framework/react/overview
fragmede 1y ago
Why're trying to move off next? What makes the opportunity cost worth it?
- rozenmd 1y ago
  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.

coffeefirst 1y ago

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.

jimbokun 1y ago

Sounds like Javascript's answer to Spring.

thr0w 1y ago
That would be Nest, not Next. A true abomination.
- mablopoule 1y ago
  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.
  - Aeolun 1y ago
    Something, something enterprise software. I find its dependency injection harder to reason about.
simpaticoder 1y ago
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.
- theflyinghorse 1y ago
  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.

throwaway77385 1y ago

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?

ecshafer 1y ago
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.
tankenmate 1y ago
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 https://github.com/cogentcore/core
- Voultapher 1y ago
  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/ 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.

nailer 1y ago

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.

rpcope1 1y ago

It's almost like the channeled the same problems and bad juju that plagued ext.js.

avdwrks 1y ago

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.

signaleleven 1y ago
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.

Alex3917 1y ago

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

827a 1y ago

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.

Aeolun 1y ago

What is frustrating is that like 3 or 4 major versions ago Next.js was the best thing since sliced bread.

mb2100 1y ago

This. It's what inspired me to build a static site generator and web framework built from first principles: https://mastrojs.github.io https://mastrojs.github.io