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!" when it's really always two entirely decoupled components instead.
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...
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).
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.
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...
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.
Why accept the result? Send it back and have them deliver something usable.
It was running when they accepted it. However they didn't realize that the group was running the Django/Postgres 'backend' on a managed Digital Ocean instance, then there were two different Vercel 'projects'. It was costing hundreds and hundreds of dollars a month to run for a project that was VERY lightly used.
They paid them on the strength of seeing it working, but then the consulting group basically ghosted when the customer asked to adjust it to run on cheaper hosting (probably because they couldn't), then the site got shut off because the hosting was all in the consulting groups name and they stopped paying it. Digital Ocean nuked the database for non-payment and they lost tons and tons of manual work putting in data.
Damn, what a horror story
I felt really bad for them. They're super nice people and I don't think the contractors set out to take advantage of them, it ended up being an bad experience for everyone.
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.
The non-profit works in Africa and is all about using local resources when at all possible. They knew some people that worked with a group out of Nairobi that talked a good game and they liked the people they met and the non-profit folks are NOT technical, they jumped on it. It's a classic story really--I've been on this side of the table many times before with outsourced work.
If they had brought me in before hand I could have saved them a lot of work by asking the hard questions and reigning in the tech overspend.
"We don't know a lot about this, what could go wrong?!" Sigh...
They're sweet well meaning people. They're very familiar with the realities of working in Africa, but they always assume people will try and do the right thing at the end of the day.
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)
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.
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.
Yes I know but the way I see sveltekit is that there are adapters for cloudflare etc. and I doubt how sveltekit can drift into such direction without immense blacklash
I don't know much about the nextjs and whether it was open like sveltekit currently is.
To me, nextjs (I think) was always meant to favour vercel but sveltekit has a rich history of managing multiple adapters.
Now, that being said there are still some chances of a rugpull that might happen but if that ever happens, I am staying on the last sveltekit that worked with cf and other cloud providers.
Only 3/40 Svelte maintainers work at Vercel and they mainly finance work on Svelte core. SvelteKit day-to-day is primarily maintained by folks outside Vercel
A little disingenuous to say “only 3/40” maintainers. Which 3? And how percentage of the total work hours invested per month do those 3 represent?
The number 3, 4, and 5 contributors to SvelteKit in the past year work at Vercel: https://github.com/sveltejs/kit/graphs/contributors?from=8%2...
Rich and Simon are incredibly important, but they're in it for Svelte and the community more so than a paycheck from Vercel. Tee has been doing most of the maintenance on SvelteKit currently funded by community donations. And this isn't counting other infrastructure like vite-plugin-svelte or the Svelte CLI which are entirely maintained by volunteers. I don't think Vercel funds a majority of the work on Svelte even if it might be close to it.
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
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.
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.
> 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”
> 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.
You have to remember, Next is the only framework that can support some of the features in the latest version of React.
To many people, it's just basic logic: "everyone must want the latest React features, and the only way to get those is with Next, so everyone must want Next".
Vite is coming along with rsc at least. https://github.com/vitejs/vite-plugin-react/tree/main/packag...
> You have to remember, Next is the only framework that can support some of the features in the latest version of React.
That is extremely fishy, isn't it?
Not necessarily since they have to do with the inherently complex niche features like unified server/client rendering (e.g. RSC, streaming SSR with selective hydration, server actions).
Next.js is essentially the reference and test bed impl.
Where people go wrong is thinking they need to default to the inherently complex niche feature of client hydration which is a niche optimization enabled by a quirk of web tech.
It was interesting handling frontend interviews recently.
We do a 30-min tops exercise where you create a React project to show how to use useState and useEffect, etc. I help with whatever command they want to use and allow Google/ChatGPT.
More than half of the candidates had no idea how to use React without Next.js, and some argued it was impossible, even after I told them the opposite.
What are you really testing for? That sounds like a bad interview.
Basic react experience presumably. As a first approximation, it seems like every possible interview sounds like a bad interview to someone. What has worked well for you?
Seems more like a test on random React minutiae. Like, let's take some framework, take away some random piece. How well do you know the area around that random piece we just removed? Frameworks are large and gnarly (or there isn't enough to them). Expecting a candidate to be lucky and know random implementation details in the area that happened to be picked doesn't seem like you'd select for anything other than luck.
For me, lately, the interview question is "here's code that ChatGPT generated for (previous interview question as related to the role we're hiring for that we could do)", what's wrong with it? What do now? (ChatGPT may or may not have actually generated the code in question.)
> Seems more like a test on random React minutiae.
It is more like test on whether or not you can figure out random React minutiae (with Google/ChatGPT, if needed) when presented with a need. Which isn't a bad approximation for how well you will do at finding any random minutiae as needs present themselves. React-based development doesn't require much original thought — the vast majority of the job really is just figuring out the minutiae of your dependencies to fit your circumstantial need.
For fun, I asked ChatGPT for an answer and it gave a perfectly good one back without hesitation. Even if you had no idea what React was beyond knowing it is a library for developing web components, you should still be able to answer that particular question with ease.
I was assuming that particular interview was not open ChatGPT. If all you want to test for is can you understand the words that are coming out of my mouth, type that into ChatGPT, and then read it to me, yeah, it seems fine.
Why would one random part of the interview disallow ChatGPT when it is otherwise accepted for answering other random React minutiae?
Because humans have to interact with other humans in conversations, and if you can't read social cues as to when something is and isn't acceptable, you're boned. I have trouble with that, so it's not surprising to me when others do as well.
When you're in a work meeting, do you just put ChatGPT up on one laptop and Claude on another and just sit back for 30 minutes to an hour?
It was deemed acceptable to use ChatGPT to discover the minutiae of useState and useEffect. What is special about createRoot that makes it off limits?
If everyone made decisions for themselves instead of following everyone else we’d be so much better off, in all areas.
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.
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.
Why? Microsoft's GUI framework as well as Apple's covered plenty of use cases before the rise of the web browser.
Then why did HTML became so popular if win32 or MFC were so great?
Because it solved different problems. CSS is terrible, but deployment simplicity and distribution channel were more powerful than how shitty HTML is for making GUIs. The fact that MFC was owned by Microsoft didn't help either.
Why would you make GUI's with HTML? Its main use was for content, not applications. Hyper Text Markup Language.
So you agree both solve different problems. Well, those are 2 use cases of front-end right now.
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 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 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 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.
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.
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).
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.
I should have been more specific here indeed. I meant more library or framework, not technology in the broader sense. My apologies.
You just reminded me of the nightmare Lotus Notes was.
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).
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).
No one will understand until they’ve seen it with their own eyes.
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.
You have my sympathy.
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.
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.
That would be Nest, not Next. A true abomination.
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:
set KEY=value
./myApp
$env:KEY='value'
./myApp
[System.Environment]::SetEnvironmentVariable('KEY', 'value')
./myApp
eh `cmd /C "set KEY=value && ./myApp"` isn't that bad if you really need complete isolation.
or directly in powershell, `Start-Process myproc.exe -Environment @{ FOO = 'bar' }`
What an absolutely awful syntax.
How Powershell ever got popular is beyond me.
Right? This is your brain on Windows.
> 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.
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.
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.
Windows had most of these APIs _before_ UNIX ever dreamed them up. You can jerk yourself off about the superiority of io_uring all day long, but it had been in Win32 for 15 years prior, and has kept compatibility throughout. I can't promise that io_uring will still be in the kernel by 2040.
So, yeah, speaking in hindsight is really easy.
PS: no, the UNIX way is also shit, just in a different way.
Port detection? Thread management? These things have nothing to do with next.js right?
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
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.
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.
>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.
Im kind of confused by what you mean here. You can use PHP, Java, Ruby, etc. for the backend with Next.js. You can even use if for the SSR server if you want.
I guess you are actually talking about simply not doing server side rendering at all? Im just clarifying because I think that still constitutes using "React for the frontend." I mean, how could React be used for anything BUT the frontend?
The server side rendering is actually one of the objective goods Next.js offers (not necessarily that it handles the complexity of it well). I mean, if you dont need that, sure... that's one more reason to just use Vite. But the backend choice is irrelevant.
Sounds like a conspiracy theory. What's wrong with making the framework easier to use? Yes, the company that's paying for development on the framework is also paying those developers to make the golden path for deployment to use that company's PaaS offering, but unless we all band together and GoFundMe a framework that doesn't, how else do you want framework development to happen? Heroku/Cloudflare/AWS/GCp's entirely able to also pay those devs to make it easier to deploy to their platform.
> What's wrong with making the framework easier to use?
Vendor lock in. Magic leaky abstractions are great until you need to debug something a few layers down when the magic stops working.
> how else do you want framework development to happen?
Loosely affiliated open source efforts maybe. If that doesn't work, I would prefer to have none at all.
> If that doesn't work, I would prefer to have none at all.
While we would all like to retire to a cabin in the woods and be a carpenter, and for corporations not to exist, that seems unrealistic.
Magic leaky abstractions are orthogonal to vendor-lock in, and the source is open, so I'm not seeing the lock-in part. The "hey it's easier and cheaper to smash the deploy-to-vercel"-in, sure, but things cost money. Either to a developer, or to a company.
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.
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
It's almost like the channeled the same problems and bad juju that plagued ext.js.
> 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.
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.
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.
I wouldn't say I agree with those circumstances, but even if they did indicate a match with Next.js, they are not worth the reduction in productivity and maintainability that comes with it.
I use Gleam's Lustre and am not looking back. Elm's founder had a really good case study keynote that Next.js is basically the opposite of:
this is a really interesting talk - thank you for sharing!
Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web.
Thank you for the reminder. Not used next.js in years, mental health improved significantly.
Vercel funds and sponsors many open source projects that would otherwise be struggling for funding. Their framework is tailored to the platform they build because that’s a good experience. I don’t currently use them, but people get funneled to their paid plans because it’s a good developer experience. I acknowledge that they are a capitalist enterprise with their own motives, but I think cancer of the modern web is a little strong.
People get funneled to their paid plans out of necessity. While NextJS is open source, the back-end to run it is not. That is where all the complexity lies. Even on Netlify, you run into crazy issues with things like their image stack. It does all this "Optimization" and caching that make it completely impossible to reason about and you run into implementation problems from the providers. Sure you can just run it in a container but then you are taking on all the complexity of NextJS preoptimizations without getting any of them.
Serverless framework attempted to make this stack to run yourself for Next but it is buggy due to the complexity of Next. Open source includes being able to run it. Releasing the framework and funding OSS that also enhances NextJS is nice, but it is a trap because if it comes time to seriously run it, your only option is vercel.
Vercel won the techfluencer space like none other. They get a bad rep largely due to the influencer crowd adjacent to them. Influencers are cancer but an almost necessary one like marketing.
Annoying, obnoxious, and always trying to get your email but god damn do they get your attention.
I agree, I don't understand the hate in this thread.
And I think their paid hosting was actually really good, up until they switched their $20/month plan to a whatever-it-may-cost and we-send-you-10-cryptic-emails-about-your-usage-every-month plan. That's when they lost me, not because it got more expensive but because it became intransparent and unpredictable and annoying instead of carefree.
And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR.
With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture.
> Half these issues stem from a relative misunderstanding of exactly where the code is running.
I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea.
My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and there's no need for a general API. (Note: Inertia works with React and Svelte too)
We tried Nuxt at first, but it was a shit show. You end up having _two_ servers instead of one: the actual backend server, and the server for your frontend. There was so much more complexity because we needed to figure out a bunch of craziness about where the code was actually being run.
Now it's dead simple. If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.
Notice that nearly everyone pushing edge-execution JS has some infrastructure to sell you.
It's positioned as a ramp up for companies where frontend and backend devs work at loggerheads and the e-commerce / product teams need some escape hatch to build their own stateless backend functions
I am a backend dev, and I needed a website that was temporary for an event. I thought to myself this would be a good opportunity to learn some frontend development.
After looking through the 20 different popular front end frameworks and getting confused by SSR, CSR, etc. I decided to use Nuxt. I thought oh this is great, Vue makes a lot of sense to me and this seems like it makes it easer to make Vue apps. I could not have been more wrong. I integrated it with Supabase + Vercel and I had so many random issues I almost scrapped the entire thing to just build it with squarespace.
would love to know what kinds of issues you encountered
> If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.
In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)?
Do you ever output JavaScript from PHP?
My biggest question though is how do you avoid ever duplicating logic between js and PHP? Validation logic, especially, but business logic leaks between the two, I've found. Doing it all in Next saves me from that particular problem.
spoken like a middle manager.
why would anyone send JavaScript from the php? why care about duplicating a couple json translations and null checks... it's all code is today anyway.
and switching languages? you can't use most of js as it is. even something as simple as split() have so many weird bugs that everyone just code from a utils lib anyway.
Yeah this is basically it. Vercel is trying to solve for optimised performance by using a combination of React Server Components, Partial Pre-rendering, Edge servers, streaming, etc. A lot of their seemingly weird design and API decisions basically come down to that. If you need it, it's good that it exists. But you can also go pretty far with doing some ssr in an edge function too.
I would be more inclined to believe it’s an end product of years of simultaneous resume and job security driven development.
LIRPslop, as Brad Troemel would put it.
> so edge semantics actually help with latency issues
Hum... You make an entire app in node, load the UI over react, pile layers and more layers of dynamicity on top (IMO, if next.js didn't demonstrate those many layers, I wouldn't believe anybody made them work), eschew the standard CDN usage, and then want distributed execution to solve your latency issues?
As mentioned somewhere else, these are the kinds of layers SSR frameworks have had for decades, maybe people should learn not to do SPAs for everything.
> a relative misunderstanding of exactly where the code is running.
This is the exact problem with the App Router. It makes it extremely difficult to figure out where your code is running. The Pages Router didn't have this issue.
Does it? Just look for "use client" at the top of the file.
> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR.
Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript.
There's absolutely no reason to tightly couple your front-end and backend, despite how many Javascript developers learned the word "isomorphic" in 2015.
Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way.
You can have a monorepo with any tech stack you'd like.
You can write your front-end and back-end in the same language.
No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question.
> Next.js tightly couples your front-end and back-end, no question.
I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor.
I don't use next.js really any more. That's exactly what I do.
Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great.
This is the problem inherent in web dev I suspect. JS developers thought they reached the zenith of programming because they had a type system and could realize some gains via strong typing checks applied to what would otherwise be network calls.
However, at a certain point, you're better off not writing a web app anymore, just an app with a somewhat wonky, imprecise runtime, one that lacks any sort of speed and has many drawbacks.
And you lose one of the most fundamentally important parts of the web, interop. I'm sure other langs can be made to speak your particular object dialect, however the same problems that plague those other type systems will still plague yours.
Which circles back to my issue, no, sticking your head in the sand and proclaiming nothing else exists, does not, in fact, make things better.
You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees.
Agreed. It's a bit insane that updating a button padding redeploys your entire backend.
Not the same problem though is it? You can have a express backend and react-vite frontend both in typescript and in a mono repo.
Are you paying for computer time by the CPU cycle?
I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch.
I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.
What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
> There's absolutely no reason to tightly couple your front-end and backend
I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2].
[1] https://www.geldata.com/ [2] https://www.geldata.com/blog/designing-the-ultimate-typescri...
or dont even write a SPA. Send hypermedia from your backend language/framework, use HTMX + Alpine or Datastar, and call it a day.
I’ve been experimenting with HTMX and it feels so much simpler.
> Half these issues stem from a relative misunderstanding of exactly where the code is running.
If I take a look at other languages, these kind of multi-threading issues are usually represented by providing a separate context or sync package (that handle mutexes and atomics) in the stdlib.
And I guess that's what's completely missing in nodejs and browser-side JS environments: An stdlib that allows to not fall into these traps, and which is kind of enforced for a better quality of downstream packages and libraries.
This has nothing to do with multithreading, though?
Absolutely correct. Those are runtime execution context-issues. There are other frameworks that do force you do deal with those (and in other languages, probably), but I believe in next.js the difficulies are at another level - because of poor documentation and the built in abstractions to allow for running next.js both in development, node.js server, and edge.
Not OP but wasn't the article about lots of async/await context issues?
If the handle() method of the middleware API would have provided, say, a context.Context parameter, most of the described debugging issues would have been gone, no?
> Let's not skip over the fact that you can't have multiple middlewares or chain them either.
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.
Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.
It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."
As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.
I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)
I can’t help but feel some of these decisions are made because it’s what is best for Vercel and not what’s best for the framework.
I don't see how this particular case makes anything better or worse for Vercel. It's just a poor developer experience to need to come up with your own composeMiddlewares function (or find one of the many that people have posted in various threads).
They validated this on the thread. They made an architectural decision to run middleware only on edge.
That's unrelated to the complaint I'm responding to, which is simply that you can only provide a single middleware file. This is merely a DX problem. You absolutely can develop your own composeMiddlewares function and import different middleware functions from different modules. It's just on you to do that, and to reimplement some basic functionality for each composable middleware function (like matcher regexes).
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]
[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/i...
Appreciate the response. But ...
> Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention
That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way? This can't be such a hard problem, can it? Every other language and framework does it!
> Why can’t logger().info() just work in a sensible way?
I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff?
If you view that as being overkill, perhaps you're not the target audience of the framework
[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...
Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.
Again, why would one need such a heavyweight tool?
Most frameworks have powerful loggers out of the box, like Monolog in the PHP world.
First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point.
I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.
The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.
This is a trend across a lot of projects these days - often missing all the nuances and details - writing good documentation is really hard. Finding the balance between making things user friendly and detailed is hard.
Keep it up
Don't you find it problematic, as a framework that's 8 years old to already have reached version 15.x? Assuming they follow semantic versioning and those are 15 different backwards incompatible upgrades?
Most of our upgrades have been fairly painless. Yes, they're not CI-succeeds Dependabot merges, but usually it's basically running the auto codemod and you're done, though I do always scan through the release notes and migration guide. That seems justified for the backbone of our application.
I haven't used next.js but it looks like they have mostly automatic/codemod migrations
`npx @next/codemod@canary upgrade latest`
Don’t think it’s semver.
I think it is, that is why it is still unstable, 2 majors changes/year.
> Finding the balance between making things user friendly and detailed is hard.
Thanks for the note! Indeed, it is also challenging when experience hides what things are not obvious or necessary to make further connections when reading the docs. It is an area of continuous improvement.
> The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.
I think on this particular topic, there had been an assumption made on the docs side, that, listing Edge runtime (when middleware was introduced), as its own thing, that might as well run in another computer, would also communicate that it does not share the same global environment as the underlying rendering server.
I'll do some updates to narrow this down again.
> The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.
Do you have anymore examples on this. I have been improving the revalidateTags/ Paths, layouts, fetch, hooks like useSearchParams, gotchas with Response.next, etc..
I know the OP post does talk about issues not being responded to, but that trend has been changing. If you do find/remember something as you describe, please do open a documentation issue, pointing to the docs page and the confusion/gotcha - we have been addressing these over the past months.
Since you're here — I'll just pipe in.
Here in this article, the author, failing to comprehend the domain differences, is applying the same approach to call a function everywhere. Of course it won't work.
The fallacy of nextjs is attempting to blend function domains that are inherently different. Stop doing that and you will be fine. Documentation won't work, it will be just more confusing. Blending edge and ssr and node and client-side into one is a mess, and the attempt to achieve that only results in layers upon layers of redundant framework complexity.
Sounds like you wouldn’t be a fan of React Server Components in general then since blending domains is its whole point.
Blending domains is great. Blending domains where you don't get logging at some levels because your framework is incompetent is not.
Yeah, I was actually recommended the instrumentation route by a commenter on Reddit.
I spent a similar amount of time setting up opentelemetry with Next and while it would have been titled differently, I would have likely still written a blog post after this experience too.
This isn't your fault, but basically every opentelemetry package I had to setup is marked as experimental. This does not build confidence when pushing stuff to production.
Then, for the longest time I couldn't get the pino instrumentation working. I managed to figure it out eventually, but it was a pain.
First, pino has to be added to serverExternalPackages. If it's not, the OTel instrumentation does not work.
Second, the automatic instrumentation is extremely allergic to import order. And also for whatever reason, only the pino default export is instrumented. Again, this took a while to figure out.
Module local variables don't work how I would expect. I had to use globalThis instead.
And after all that I was still hit by this: https://github.com/vercel/next.js/issues/80445
It does work, but it was not great to set up. Granted, I went with the manual router (eg. not using vercel/otel).
If you finally decided to support proper server-side middleware, why is there still a limitation for only one middleware function and not a chain of middleewares as every other sane server implementation offers?
Consider middleware.ts as a root middleware. Nothing is stopping you from creating your own chain (which is trivial) in there. I mean, that would eventually work the same if nextjs implemented that feature — there would be a root somewhere.
That doesn't answer parent's question.
People expect "middleware" to mean a certain thing and work a certain way.
middleware = fn(req) → next(req).
type mw = (req: Request, next: () => Response) => Response;
const logger: mw = (req, next) => {
console.log(req.url);
return next(); const auth: mw = (req, next) => {
if (!req.headers.get("x-auth")) return new Response("forbidden", { status: 403 });
return next();
};
function chain(mws: mw[]) {
return (req: Request) =>
mws.reduceRight((next, mw) => () => mw(req, next), () => new Response("ok"))();
}
export function middleware(req: Request) {
return chain([logger, auth])(req);
}
Nothing trivial about that implementation in my mind - need to keep track of where middleware is registered, reduceRight is non obvious.
I expect these things to be standardized by the framework and all the sharp edges filed off - thats why I go to a framework in the first place.
The reduceRight is just a bit of cute FP code golf. All it’s saying is that chaining an empty list of middleware yields an ‘OK’ response, and that the first middleware is passed a function which, when called, executes the remaining middleware chain, and so on. It would be obvious enough if written out as a for loop, or via direct recursion.
(My username has never been more appropriate!)
Will vercel/next come up with an official policy on pages roter/API routes, will they be supported long term? If I start a next project I still use pages/API routes, because of several really really bad experiences with the app router.
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.
Thing is I'm spoilt by asp.net, which has so much bad 'stigma' in the (esp startup) dev community but it is _extremely_ well designed.
You get a very batteries included approach(es) but you can always punch out of it and override it. I've never got into a situation where I'm feeling like I'm fighting the framework.
I also really like both Blazor Server and Blazor Webasm which allows you to write the frontend in C# too. Blazor server is great for internal admin panel style apps, and blazor webasm is good for saas apps, and for everything else plain old server sider rendering works great.
I'd really recommend anyone who is annoyed with their web framework to give it a go. It's extremely cross platform now (the huge drawback until about a decade ago was it was very hard to run on Linux, which isn't the case at all now - in fact, it's the opposite, harder to run on Windows), very fast and very easy to use. It takes a while to figure out the mental model of the design in your head but once it comes together you can quickly figure out how to override everything when you hit limitations (which tbh, is pretty rare compared to every other framework).
It's weird how C# can elicit such an eugh response, and TypeScript gets so much love. They're.. made.. by.. the.. same.. people
I agree people really need to update their mental model of where dotnet is at. I worked with it on Linux and it's a great experience
Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.
It's more likely they never tried C#, but have a very strong negative bias towards it nevertheless. C# can also be written very functional if you want, it's a multi-paradigm language like Typescript itself.
Of course it _can_ be. But that's not how major libraries are structured. Which defines how majority of business apps are structured. The way majority of folks use a language defines the language in its entirety, doesn't matter if theres a kitchen sink of alternative paradigms. You can't argue that C# isn't enterprisey in the majority case. In JS you can build on top of a whole, extremely popular library ecosystem purely using functions and options objects.
Blazor is not good at anything. Please stick with JS for the frontend .NET devs. You'll thank me later.
> 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).
I have done a few Angular apps and the experience/setup quoted above is basically foreign to me. I know that it is a framework and not a library but it is a very well designed framework (atleast Angular 2 onwards; I used Angular v20 for my latest component). Basically most of the commonly needed stuff is included in the framework (I just added NGXLogger for logging) and the abstractions are pretty nice and fairly similar to a backend service (services wrap libraries and components rely on services). RxJS can be a bit of a learning curve but once you are comfortable with the basics, it can take you quite far. Atleast I rarely had to fight with the framework for typical SPAs. Also, the documentation along with tutorials is great - I learned using the tour of heroes application[0] but seems angular.dev[1] is the new home for v20 docs.
[0]: https://v17.angular.io/tutorial/tour-of-heroes
[1]: https://angular.dev/
Nah, Laravel is proof that over engineered abstraction can sometimes be done right. Laravel works beautifully in production and I have never regretted using it.
I don't think Laravel is over engineered. It seems more like a bag of libraries for building web applications held together by a thin framework layer. Even if there's a lot of reflections being used, it's a very readable codebase and very semantically tied to the web apps domain.
> it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other
This is my job. We're a small team and my job is to keep things up to date. Insanely time consuming. Packages with hard dependencies and packages that stopped being supported 5 years ago.
Yep, been there. It is a lot better these days for React SPAs but it is still a pain.
Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible.
And this tooling-hell is not only a browser frontend problem only either, it is also quite common in game development. Where you also have these monstrosities like Unreal Engine that "includes batteries" but makes it really hard to troubleshoot problems because it is so massively big and complex. A game engine is basically a bundler too that combines assets and code into a runnable system to be run on top of a platform.
Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards.
Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit.
Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the time.
Browser standards have come a long way in filling the holes that caused react to be written in the first place.
I don't think we will ever be able to get away from bundlers because there is no way to solve the waterfall request problem of using modules (one module imports requires another module). Maybe some kind of standard manifest spec that tells the browser which parts of the code to load upfront and which parts of the code to lazy-load, but to generate that manifest in an efficient manner you would need at least part of what the bundlers do today.
Minifying is also somewhat of a hurdle, I guess it could be done at the CDN level on-the-fly+cache, but that is also its own nest of complexity.
SPA frameworks have a place, if anything I think they will become more prevalent, but I can foresee WASM opening the door for non-JS language stacks. However they will need bundlers as well and some languages are just not built around giving ways to minimize binary size and lazy-load code. Just try to compile some C++ to wasm, you end up with 10+mb .wasm files.
> Advances in the browser standards are slowly removing the need for most client side JS altogether
I probably wasn't clear enough when I said this.
If you're talking about waterfall requests in module loading, you've missed what I said and are likely sending orders of magnitude more JS to clients than you need to.
It's really worthwhile looking at all the new features in browsers over the last 5-10 years and asking yourself if you really can't do what you need just with vanilla HTML and CSS at this point. You can always sprinkle in a bit of JS to fill in some gaps if needed. My team usually has a 2-300 line JS file in each project. No bundlers or modules ever required at that scale.
> It definitely needs people with more experience to set up everything
I mean it's not just the experience - it's the upfront time cost and then ongoing maintenance.. and for what? It's really easy to underestimate how much effort this will be
Having done both I genuinely think Rails is a 10x productivity boost over stitching your own mishmash of libraries together in Node
The only lack of flexibility you run into is if you really disagree with the fundamentals of the framework. If you hate the ActiveRecord pattern for example you need to stay away
"shit breaks once complexity comes in" is a skill issue
>both over-abstracted and inflexible which made it really hard
This seems to be built into the culture of companies which have those ridiculous whiteboard leetcode interviews. You find people who can produce very clever complex solutions in their sleeep, and then they do that. Interviews aren't selecting for people whose strength is simplicity and clarity instead. So you get a lot of tight loop optimizers and they tight loop optimize everything... not just the tight loops. But if your product is a library/framework being consumed by mere mortals, you probably want something simple if you want to succeed in the long run. The super car's performance is meaningless to you if you can't drive stick.
Yeah, clever code is the bane of my existence.
Only my own code is allowed to be clever!
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.
I'm not a React or Next.js user. Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed.
I was somewhat surprised when I noticed simple Next.js landing pages would break in Firefox. Worse yet, the failure mode was to overlay all of the content with a black screen and white text, "An application client side error has occurred". It was surprising in that a simple landing page couldn't render, but when I discovered that the cause was a JS frontend framework, I felt that it was par for the course.
Perhaps it makes sense to the advocates, but for those of us not on the bandwagon, it can be sincerely baffling.
> Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed.
If you don't mind my asking, what sort of applications have you worked on, how many contributors were there, how long was their lifespan, and how long did you work on them for? Personally, I've found the type of "vanilla" JS approach to be prohibitively difficult to scale. I've nearly exclusively worked on highly interactive SaaS apps. Using a substantial amount of JS to stitch together interactions or apply updates from the server has been unavoidable.
The engineering organizations at companies I've worked at have ranged in size from three devs to over 20,000. Projects I've worked on have ranged from three devs to maybe 500-1,000 (it's sometimes hard for me to keep track at a giant company). I've worked on projects using "vanilla" JS, Knockout, Backbone, Vue, and React[0]. The order in which I listed those technologies is also roughly how quickly the code became hard to maintain.
[0] This is not an exhaustive list of which frontend frameworks/libraries I've used, but it's the ones I have enough experience with to feel comfortable speaking of the long term support of[1]. For example, I used Ember heavily for about a year, but that year was split between two projects I spent six months each on. Similarly, I've used Next.js, but only for prototyping a few times and never deployed with it to anything other than a private server.
[1] Except Lightning Web Components, which I've used a lot but hate so much that I don't want to dishonor those other technologies by listing it alongside them.
Next has enshittifed themselves some time ago. Everything that goes through the VC cycle does that eventually.
I am happy for them and their money, but I can't use this anymore. I take Vite as the default option now, but I would prefer something more lightweight.
My 2cents: Nextjs with page router was a very nice (and simple to learn but powerful) framework.
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 think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server.
The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs.
I struggled with Next.js at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.
> But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.
The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in the same process. The fact that Next.js puts it on the edge and only allows one is breaking that assumption, and further, most applications do not need the additional complexity. To go back to your toolbox analogy, more tools mean more complexity (and money), so you wouldn't get a new tool simply because you might need it, you get it because you do need it, and the same applies to edge functionality. If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in, so you don't need to worry about it when you don't need it, and it shouldn't be called "middleware".
Yes, the term "middleware" is unfortunate, this is abundantly clear.
> you wouldn't get a new tool simply because you might need it
No but you get a framework precisely because it's "batteries included": many apps will need those tools. You don’t have to use all of them, but having them available reduces friction when you do.
> If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in
It already is. Nothing runs at the edge unless you add a middleware.ts. You can build a full app without any middleware. I'm surprised the author of the article fails to acknowledge this, given how much time was spent on finding alternative solutions and writing the article.
As I have mention in another comment
> If learn what is a package/module in python, try to apply that in Go without any brain power, you will complain that Go is bad. If you are using any technology, you should have some knowledge about that technology.
Don’t really think the analogy holds up, middleware is an established term in web frameworks, the same space next is operating in and the thing looks a lot like a middleware but violates some of the core assumptions people make about what a middleware is. It is not really surprising it is a point of confusion.
I wouldn't consider this a misnomer, but a really big misuse of the term. Middleware has a long established definition in web applications, so they really should not use the term if they mean something entirely different.
I'm also working with Next.js, app router, and like it very much.
The problem is probably that Next.js makes it very easy to move between front and back end, but people think this part is abstracted away.
It's actually a pretty complex system, and you need to be able to handle that complexity yourself. But complexity does not mean it makes you slower or less productive.
A system with a clearly separated front- and back-end is easier to reason about, but it's also more cumbersome to get things done.
So to anyone who knows React and wants to move to Next.js, I would warn that even though you know React, Next.js has a pretty step learning curve, and some things you will have to experience yourself and figure out. But once you do, it's a convenient system to easily move between front- and back-end without too much hassle.
To people who downvote my comment (and there are many): please elaborate.
I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.
Finally someone with a brain.
If learn what is a package/module in python, try to apply that in Go without any brain power, you will complain that Go is bad. If you are using any technology, you should have some knowledge about that technology.
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 believe the obsession with streaming is a major factor in the new constraints. Together with supporting the lowest common denominator, edge runtimes.
And the reason they're all in on streaming to begin with is because they're sending massive amounts of data back and forth all the time. Like Sean Goedecke said in his API design writeup [0], a technically poor product can make it nearly impossible to build an elegant API. I believe we're seeing the same thing with Next.js, all of these wonky interfaces derive from the underlying architectural issues.
Maybe it's a good design from the perspective of making more money from your hosting business
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.
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
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.
Your observations apply generally. Debugging "magic" frameworks is often more complex than starting with simple basics and a coherent design. As a bonus there are less dependencies, less build issues and lighter pages or binaries.
Fully agree really enjoying TRPc for this.
> 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.
Spot on. This is the core problem.
The ammount of functionality is not the problem.
The problem is that the functionality is not a set of composable functions and classes. It's an inversion of control "framworky" blackbox, where behavior is hard to reason about.
I did find it quite funny that he makes this claim, but then writes an entire blog piece about how nextjs is no good because of one particular thing it doesn't do to his liking!
The Unix philosophy?
Every DOM element is a file. And you can use ioctl from JavaScript for anything that doesn't fit neatly into a one dimensional stream of bytes.
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.
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.
I've worked on many very large Angular applications I've always loved working with it. I have worked with plenty of React but I avoid Next.js like the plague after reading through documentation / examples / blog posts.
I was in the trenches pre-ES6 with JavaScript and JS/CSS since the year they came out, so of course I do love KISS-style bare-bones websites when that is the proper tool for the job. But certainly not for anything at scale. Angular, being a framework and not a library, is perfect for those purposes. I prefer that it IS opinionated (no "what router does this project use?"), and I also would not develop anything these days without TypeScript (even small sites).
To each their own.
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.
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.
- Other options?
For awareness, if you want to build a SSG/SSR frontend, there's also [Astro](https://astro.build/)
It lets you ship client islands to the client, which AFAIK is essentially partial hydration.
You can make islands with pretty much any JS framework or even none e.g. Web Components
Katie Sylor-Miller named them when she was at Etsy and from memory they were React components in a PHP page to start
Vanilla Django would get my vote. Your description doesn’t sound like it needs a heavy frontend. Sprinkle in some scripts as needed. If you really want to learn front-end, Next is really just the worst place to start or finish or anything in between.
Sonnet 4 and gpt5 are both good at SvelteKit. You might have to specify that you want to use Svelte 5 in the llm instructions for your editor.
Use Context7 mcp to get Svelte 5 docs if the agent messes up something you know should work.
The new experimental remote functions solved a big pain point with sveltekit, so I no longer have any reasons not to recommend svelte and sveltekit to people.
Personally I love Sveltekit.
Theres some things to learn but once you do its amazingly simple and powerful.
That said I havent tried Astro, Nuxt
Use what you know. Build the backend first. You probably won't know what the frontend requires before this.
Once you know what is actually going to be on your site, you can style the output with CSS and add the necessary interactivity with JS. Browser APIs have mostly standardized as compared to the bad old days. Using them directly instead of libraries or frameworks will keep your site lean and fast.
All of your CSS, HTML and browser API knowledge will continue to serve you for the years to come. In a few years, people will be arguing about a new magic framework.
If already know Django, go with Django and sprinkle in some HTMX as necessary. You’ll get 95% of the benefits with a fraction of the effort compared to a modern Javascript SPA. And it’ll be a breeze to maintain. You’ll also save so much time never needing to debug a bundler, minifier or ESM/CJS issues.
You should really try Nuxt (a vue framework, like Next.js but better).
I had to use a webpage built with Nuxt recently. This thing was completely messed up.
In my opinion (9 years FE exp) you should build your ecommerce site in shopify or wordpress + woocommerce or some other off the shelf tool. It will be up before the evening's out and you won't be spending that much extra than you would have anyway, and everything will Just Work (tm) and look pretty good (chuck out 50$ for a nice wordpress theme and you're golden).
If you insist on rolling your own, Django + templates should be plenty. Lots of existing code for integrating Stripe or whatever. AI will be fine at it. You could potentially investigate medusajs or prestashop. Here's a list that could be fun to investigate: https://github.com/awesome-selfhosted/awesome-selfhosted?tab... but keyword is fun. You should build it in wordpress because that is a bombproof solution running like half the internet and will save you endless amount of time.
If you're doing this as an exercise to learn a new tool, leave the AI to the side as you're robbing yourself an opportunity to delve into docs and gain more domain knowledge. And absolutely do not touch nextjs with a 10 foot pole, it's an absurdly overwrought tool. The only people that should learn nextjs are people working at dev houses that churn out a shitload of full stack apps for clients that have the budget to shell out for vercel's hosting costs. And even then imo they should just be using django + react + vite + tanstack MAYBE.
HTMX is cool but I'm not sure the point, again if for fun why not, but I would ask yourself: you get your site up and running and you spend the next year scrambling around putting things in boxes and printing shipping labels, and then in 2026 Thanksgiving right before the holiday rush something breaks in your app and you want to fix it but HTMX/nextjs/whatever have gone through 2 breaking change upgrades and so have 4 different libraries they rely on and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions or some other bullshit, and now what do you do?
Just use wordpress.
I was 100% on board with WordPress/WC at first, and had already started building with it, but was immediately coming into issues. Just Work (tm) was my expectation, and was most definitely not what I found.
- I used the product variations feature, 18 variations per product, and all of a sudden the "Duplicate" button took 15 seconds! I learned this is because each variation is it's own thing, so it was making 18 new things (still insane it took that long, on my beefy dev pc). I can't imagine 30-50k products * 18 variations * metadata stuff working fast in any way.
- In avoiding product variations, there's plugins for adding product fields, and plugins for pricing rules, but clicking around to do stuff, or maybe writing php that integrates with plugins that I'm clicking around in... it's not the way I want to spend my time developing. It especially integrates terribly with AI tools, which at this point are an important development tool for me.
- I don't want to have a 1-to-1 mapping between products and pages. This doesn't fit the WC model well (or Shopify for that matter).
Generally, I can imagine an experienced wordpress/PHP dev being able to overcome these issues, but if I'm learning something anyway, I'd personally rather learn a proper frontend framework (be it any of the options you mentioned). Leveraging AI tools also matters.
I appreciate your response! Gives me more confidence in maybe sticking to Django + templates. But from what I've seen, and also in discussions with other developers, I think wordpress is out for this project. Thanks again :)
No! PHP is merely bad, but Wordpress is truly abysmal. Steer clear. Webdev since 1998 (27y).
Well, fine, what would you recommend instead? I've never had issues with wordpress as long as I stay away from their stupid block editor thingy but you've much more experience than me so I'm curious your opinion.
htmx will not have gone through 2 breaking change upgrades
And also:
> and so have 4 different libraries they rely on
HTMX has no dependencies. https://htmx.org/essays/vendoring/
> and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions
HTMX has no build step. https://htmx.org/essays/no-build-step/
This is the real advice.
Do what gets the actual job done: focus on the selling, not the tech of the shop. Grab a template and adjust it to fit your marketing.
Actual useful tech is integration with a printer/printshop. Or getting packaging labels automatically for orders. Or using AI to make new posters.
Or use PayloadCMS, which is Next but at least you don't need to deal with WordPress.
SolidStart
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!
I think it's actually a good conversation starter. "I had to get rid of [popular framework/tool]."
Possible follow up questions:
- what led your team to want to remove it? - what was involved in removing it? - what did you replace it with? - what makes the new thing better than the old thing? - how did you evaluate that spending X days/weeks/months to remove it was worth the time that could have been spent on developing features?
I think all frameworks and tools have their time and place, and knowing when and how to use them is important.
If a company can't understand this then I wouldn't want to work for them.
It would be a point in your favor if I was interviewing you. In fact, telling that anecdote may be a good way to weed out koolaid-drinking companies.
Modern development in a nutshell.
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.
reminds me of this talk https://www.youtube.com/watch?v=SxdOUGdseq4 :)
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.
What are the alternatives beyond Vite and Remix?
Rails and Laravel are still big players in the space that have only gotten better with time.
> What are the alternatives beyond Vite and Remix?
On more than one occasion I’ve seen someone refer to Vite as an alternative to Next.js. Isn’t Vite a bundler and Next and Remix frameworks? How is Vite an alternative to these?
Solid and sveltekit
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.
As someone who went from MEAN -> Java (Spring) -> MERN - > Rails I cannot comprehend how many times the JS community has reinvented the wheel.
These days I do my best to stay in Rails land, far away from Next.js. It just looks like a cluster.
> SvelteKit is a Vercel product
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?
Rich Harris answered this question on Reddit a year ago: https://www.reddit.com/r/sveltejs/comments/19ac6lp/concern_a...
Seems Svelte is still mostly managed as an independent open source project.
I came here exactly for this. Vercel has long since passed the investment threshold where they are driven by building cool things. Now they are surely driven by project managers managing PKIs. I love Svelte and I'm sure Rich Harris has been in meetings where someone said to him "Sure, I know that's important, but this feature I'm talking about will bump my numbers next quarter..." And, that's the slippery slope.
Given that Svelte's marketing and docs now treat Svelte itself as a minor implementation detail of SvelteKit, this doesn't exactly inspire confidence.
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.
> 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].
[1]: https://nextjs.org/docs/app/guides/open-telemetry
[2]: https://grafana.com/
this is a fantastic, state of the art way of “now we have two problems”, i can say unequivocally from my own experience.
OT might be too heavy of a hammer depending on what OP needs.
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...
Huh? Modals work the same way they do anywhere else.
> 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.
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.
I also had similar issues and wrote a guide on how to use LogLayer + pino to get server-side logs working properly.
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.
Next.js is a cancer. I wish more people would see it sooner before Vercel completely destroys ReactJS.
I thought NodeJS itself was the cancer*. Hard to keep up with all the cancers I guess ;)
It's not listed under N
https://web.archive.org/web/20190612110518/http://kill-or-cu...
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.
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.
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.
I have been frustrated with Next.js changing it's API so much in the last few years and making things more and more complex and confusing.
I am wondering about giving Remix a whirl for an upcoming forum/CMS rewrite with custom auth. Anybody else have experiences with Remix?
If you don't like changing APIs I'd stay away from the Remix guys. I know it is not like Next but I've used react-router, which had some API churn, later evolved to remix and then back to react-router... Backward incompatible changes are the signature of it. The documentation story is a problem too because of that. Completely different things are named the same and they are now building a new Remix, not even on React as far as I can tell.
Stick with a single version and you'd probably be happy though.
While the "Remix" renaming / branding is a little confusing, the React Router team has always done a fantastic job delivering a robust solution that properly leverages the web as the platform. Its framework mode (fka "Remix") is simpler and better than Next.js, and more featureful than vite-ssr. Want to mutate data? Use a form. Fetch data? Uses browser-native fetch under the hood. It's all about the fundamentals: HTML and HTTP. You can decide how much clientside JS to ship, and mostly eliminate it. OR, if you want a traditional SPA, go for it. A quick HN comment thumbed on my phone can't do it justice -- but it's very, very good. And its maintainers have a stellar track record. (No vendor bias like w/ Next.js / Vercel.)
FWIW, I've been doing webdev-related work for a living since 1998, and React since 2016.
their issue with breaking changes is from way before the Remix days - React Router introducing massive breaking changes at every major that required significant rewrites was already a running joke of the community
Their documentation was also abysmal the last time I used their product.
I used it with Shopify's hydrogen framework. Wasn't a huge fan of hydrogen but Remix works fine, it mostly just got out of my way and worked. Dependency injection was trivial :)
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.
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.
Completely agree. Nuxt is intuitive - convention-over-configuration and auto-imports remove a ton of boilerplate. The key is treating it as an app framework, not a backend solution - within that scope, it handles modern SSR/SPA complexity.
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 think HonoX is similar to Fresh, with the Interactive Islands
https://fresh.deno.dev/docs/concepts/islands
https://github.com/honojs/honox?tab=readme-ov-file#interacti...
Ooo nice, I didn’t know about this. Thanks for posting, looks interesting, and framework agnostic to boot :)
(Edit: well, potentially at least)
I did try to make something like this a couple years back to deal with multiple renderers and a choose-your own set of various SSR techniques [0], but didn’t get very far with it in the end. I should have based it on Hono really, to get web standard Request objects.
Fresh looks promising but still has no support for any CSS solution that is not Tailwind.
Edit: I just saw an email from two hours ago that they added support for any CSS solution because they just migrated to Vite. This is promising!
I had a project slated to use this framework. The pilot went fairly well. Fresh has the right ideas on static vs dynamic islands. In the end, we deployed with Astro - which also has similar ideas. In the end, I just wasn't able to get full buy-in on Deno.
That’s a shame, I’ve also been through much the same process.
Astro is pretty good too, though. I’m not 100% sure on some of the decisions it’s made, and personally don’t enjoy the need for new file formats and domain specific languages, but it does a half decent job of being framework-agnostic despite a few pain points.
I feel like Fresh being Deno only isn't the primary issue. It's based on Preact which is really just a non-starter for so many because it isolates away too much of the react ecosystem instantly.
I don’t disagree on that front, the React ecosystem is huge, and rebuilding a load of complex components is often beyond the budgets of many greenfield projects.
I also don’t believe a React monoculture is good, so a growing Preact or Solid ecosystem would be really positive, alongside growing web/DOM standards to ultimately make these frameworks more of a light wrapper around some trivial updates.
React and Next.js, to me, have done the typical architecture astronaut thing, and it feels like they’ve both increased the barrier to entry and just made everything a little more complicated than it really needs to be for much of the web.
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.
In what way does Next.js handle translations or authentication? It doesn't prescribe or even do much to simplify either of those things.
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! :(
I've rebuilt multiple gatsby projects in NextJS recently, and mostly it's actually been pretty nice. However, the crazy high level of abstraction and black-boxing does mean occasionally we run into bugs caused by undocumented behavior and have no idea what is the right way to handle them.
Hmmmm, that sounds like it would work, but is also a bit concerning :) I’d rather not have some mystery bugs, and considering all the open issues in GitHub…
FYI remix doesn't really exist anymore, it was folded into react-router a while back.
Astro I've found to be pretty solid for prototyping, I like that it gives you control over the rendering of client side code islands and that it works with multiple rendering libraries. I don't love some of the direction they've taken lately though, and I worry that it will become bloated with things like astro db
Say anything negative you could possibly say about Next ... and it will apply a thousandfold to Gatsby.
Likewise React Router is ... the example I use when I want to tell someone about a terribly engineered library. As you said, there are multiple React Routers, because the developer is completely incompetent, and has no idea what he is doing. As a result, he changes the entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION.
Astro and Remix are viable options, but there's a reason why Next (despite it's flaws) remains dominant over them.
React Router v4 was released in was released in March 2017 (more than 8 years ago!). v5 was released in May 2019 with no API changes. v6 was released in November 2021 with a new API based on React hooks (this API was much better than the previous). v7 was released in November 2024 with the "Remix" APIs (most importantly the "framework mode"). So, the gaps are 4 years and 3 years - that's doesn't seem that crazy.
I personally updated Remix v2 project to React Router v7 and because I used various flags to prepare for the upgrade, it was done without any issue and fairly quickly.
> entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION
So a new major version has some breaking changes? Why is that surprising?
Any thoughts on the Tanstack libraries? We use their query library, and ironically, it reminds me of ext.js tiny bit, but it's been pretty consistent.
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.
I don’t know if this counts as experienced, but I’ve spent about a year exploring Next.js, the last 6 months of which transitioning from exploring to building a serious project.
I understand the author’s frustrations. I have had similar ones when it comes to middleware and other parts of Next.js. I’ve also had those kinds of frustrations with every piece of software and framework I’ve ever used. A lot of times they stem from trying to shove a square peg into a round hole, and it only gets better when I finally develop the right mental model for how the thing works.
As a web developer going back to CGI scripts in the 90s, all this server and client side rendering, edge runtimes, etc., is quite foreign. But when I find myself screaming “why won’t it let me do this?”, the answer is often “because it doesn’t make sense to do that”. Auth is one of the places where that happened, and going through the process of “but why can’t I look the user up in my database from middleware” was a big part of wrapping my head around the parts of Next.js that I had been ignoring.
As far as being married to Vercel for hosting, not at all, if you don’t choose to use all their stuff. The sample Docker build they have works just fine to deploy anywhere, in my experience.
Maybe I’m speaking mostly out of ignorance of not having tried dozens of other modern TS web frameworks (I was on a big tech island for a decade and not in touch with what the cool kids were up to), but I rather like Next.js. I may feel differently when I want to start adding native mobile apps and realize I was lulled into omitting a clean API layer, but for now, adding features has been pretty smooth.
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.
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.
[1] https://reactrouter.com/community/api-development-strategy
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.
That seems like the most unfortunate of reasons to choose it as a framework for new projects, though. I hope that doesn't become the deciding factor in the future.
Yes, we try not to do that. But I know very many people do.
Significantly better than just React and a Node backend? I doubt it, what's the comparison here?
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.
NextJS has been pushed aggressively by many people and often recommended as a kind of default for React applications. Which I consider a bad idea, in a large part because NextJS contains a lot of complexity that most applications don't need.
the React documentation is infamously responsible of recommending Next as a "default". After a lot of backlash it got somewhat toned down, but it's still the first thing they suggest[1] for creating a new app
What challenges did you pick up with Elixir?
I'm sorry, but please do read the post.
The middleware section is a setup. The real trouble starts when ejecting from Next and using a custom server still doesn't allow you to do anything because Next is a black box.
I would have been happy with installing fastify and just using it's middleware, but even that doesn't work.
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.
yeah, nextjs middleware is garbage
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
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.
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.
Use .run.
return LoggerStorage.run(requestLogger(), () => {
logger()?.debug({ url: request.url }, "Started processing request!");
return NextResponse.next();
});Nope, this doesn't work either.
He made a whole new blog to complain about Next.js and built the blog with Next.js
Sounds like he writes from experience.
Looks like we're all joining the anti next.js train especially as more and more vibe coded apps seem to be building on next.js!
It's the designed-for-vibe-coding framework, same as its creators are the designed-to-be-replaced-by-AI cohort.
Next.js is marketing to get you locked into vercel hosting.
Using nextjs for years without paying a cent to Vercel. If you want React SSR, why would you create a DIY solution if there is a framework with huge community and support?
remember a while back when they was "rails is a ghetto" piece.
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
Can't wait for the opinionated fork that gets abandoned in 3 weeks.
Do people feel this way about Nuxt too? They have recently joined Vercel…
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.
What’s the rationale behind NextJS for this client? If you’re not using Vercel, NextJS doesn’t make much sense. Something like Astro is likely to be a much better fit.
Any sufficiently advanced development ecosystem will be full of issues and people ready to tell you about them. Whatever the flaws, it's probably still an improvement over what it replaced in your situation.
Fair enough I guess.
I think Next.js has its place in enterprise software. For the rest of us I think it's time to simplify. I like to do that to the point of absurdity.
Why I'm writing pure HTML and CSS in 2025:
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
Reading the comments here is pretty funny, this time last year NextJS was the greatest thing ever.
Similar experience here.
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.
The two best days of a NextJs developer life if the day he starts his project and the day he migrates it to React Router.
I can only recommend vike.dev .
I wish more people knew about and were talking about vike, really powerful tool
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.
Seriously, give Elixir a shot.
> Scientists discover a new super massive black hole at https://github.com/vercel/next.js/issues
got me good
JS devs having Stockholm syndrome is no news.
React server components and server side rendering should never have been in react but instead should have lived its life as a separate project.
I've came to the pain conclusion on Next.js:
It's a bad framework for building full stack apps, but it's better than anything else.
lol when i try to explain this to fellow devs in discords they adamantly fight me on it and i dont even bother getting further into it.
When I see Next.js on a job posting as a "requirement" or even as a "something we use" I immediately discard 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.
I also recommend inertia.
It really doesn't do much, which is very refreshing coming from Nextjs.
It's simple tooling for backend for frontend-style APIs, taking care of basic routing, fetching of data, and submitting forms.
While inertia was invented for Laravel, I'd argue that it works even better with Adonisjs. Because Adonisjs is TypeScript you can infer the types coming from the backend.
Every time I hear about modern JS/TS frameworks, I'm amazed at the unnecessary complexity.
In python / bottle.py this would just be a print statement to stderr in before_request() or before_response(). One additional LOC.
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.
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.
I have no major problem with Next running on Dokploy. I don't use lots of its functionnalities, just some SPA routes and dôme RSC routes.
That's fine. It works fine.
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.
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
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…
What about vite.js?
One of my latest experiments was using vite.js and then using a go backend where I embedded the vite app using embed.FS. I haven't tried it in a live environment yet but it seemed like a potentially nice way of doing it.
Hehe, great post. Just use Hono or Hono X. It's so easier to reason about what's going on for me, mostly backend guy.
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.
Out of curiosity, have you tried out Tanstack Start? It appears to be a framework similar to next and remix/react router.
I've loved all the Tanstack libraries so I'm looking for an excuse to use Start lol.
I think I’m just paranoid, but nextjs has always felt like a trap for the boot camp participant.
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.
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?
Each paragraph/element has a unique ID, starting at 0, incrementing by 1. You originally land at the page https://blog.meca.sh/3lxoty3shjc2z . When you create a link, you're linking instead to a different page at https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64 . The format of the extra link metadata is `64_25-65_174#64`, which means:
- Start the highlight on the 64th element/paragraph. Inside of that paragraph, start from the 25th character.
- End the highlight on the 65th element. Inside of that element, end at the 174th character.
- Scroll the user to element #64 on page load.
They've then got some code on the page to add a highlighted span starting and ending at those points.
If the site maintainer is here: For me, the links are currently broken, as they should link to https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64, but currently link to https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64_2..., and `64_25` isn't a valid id on page-load.
Ok, I think I can reproduce it by starting the selection from the end of the previous line.
I've reported the issue here: https://github.com/hyperlink-academy/leaflet/issues/196
The blog itself is build on leaflet.pub.
I'll take a look and file an issue.
Do you know what, it uses to be OK in the early days with pages and not too much magic/abstraction.
These days vite is far far nicer.
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.
I didn’t fully read the post, but pretty sure they have a good point. I inherited next.js on a project it is the absolute worst framework.
I don’t need/want to elaborate.
Next js is magic just like laravel, it's nice when you expect magic and not nice when you like to understand what's going on.
Laravel is easy to learn and use and get started with. No compiler. No javascript on the back-end. Eloquent is a good ORM. There's not much magic, no async/await. Or course you should not use Livewire. It's really terrible!
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.
https://pikku.dev/docs/runtimes/nextjs-app
Disclaimer: I’m the pikku core developer
There you go. We are now past the honeymoon period of yet another web framework.
This one has been the most over-hyped, vendor locked-in and completely vulnerability ridden web framework I have ever seen.
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.
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.
Next.js turned out to be worse than PHP.
Next.js turned out to be worse than JEE, which is ironic to say the least. People moved to Node.js at first place because the Java ecosystem was "too bloated". Fast forward 15 years later, the Node.js community has adopted its own flavor of JEE. And rince and repeat, new developers will deem Next.js too bloated therefore they are going to go with another platform that doesn't have that stigma...
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.
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.
I think Edge infra and SSR irks me the most out of everything.
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.
Genuine question - What are the alternatives?
React Router + Express?
Or something else?
We do React Router 7 (previously Remix) with Fastify for a couple of our apps. Both external and internal. I'm really happy with the dev experience. We also have plenty of NextJS floating around here too. Most teams use it as a "better Create React App". There's little use of any of its features. I'm the only one that's used any server-side stuff.
For my team, React Router 7 just gets out of the way. If you use it in framework mode (SSR) you will have loaders and actions, which are things that run on your server. I find it SO much less convoluted. The logger example from the article above is childs play in React Router. Either import your logger and run it in your loader. (You may want to add .server.ts to make it explicitly ONLY server) or inject the logger via context.
React Router v7 is actually awesome and can do SSR if you need it.
React Router is great. Express is ok for its server (hono or fastify have advantages).
I've lost count how many times I've had to struggle to enable a simple logging.
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.
I use svelte and it is alright.
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
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
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.
nuxt.js is also infuriating and we need another article on it
oh no
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.
100% agree.
Node/express/postgresql will never disappoint you
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.
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.
> my main stack is Flutter+gRPC+Go
For web apps? How is the performance? How is the developer experience?
Yes, web build comes as a nice bonus, and I've been using it from the early days of Flutter web renderer support. Now I'm using it for client-side web apps exclusively.
Developer experience is... well, I usually develop app while running it locally as a MacOS desktop app build. Just much easier to use with hot-reload and Flutter dev tools. Often using DevicePreview [1] wrapper to check against different sizes, dark/light mode, font scaling etc. Unless I'm working on something platform-dependent (like push notifications or a QR code scanner that uses camera/ML frameworks from OS), I don't even test it on mobile devices or web - I know that it will look pixel-perfect. There are optimization caveats like "emojis are not included in the web build by default to decrease the size", but otherwise web build looks the same way pixel-to-pixel as MacOS or mobile view. Test I run with maestro in iOS simulator.
Centering widgets ("<divs>") is never a problem, haha. Having a properly designed layout system is a no-brainer and thousands of times better experience than that pile of hacks on top of hacks called CSS.
Still, my main issue with the current Flutter design is the tight coupling of two main design systems (Material Design and Cupertino) and the core, and the lack of a wide choice of alternative design systems. Just to make it clear - it's extremely easy to create your own widgets/themes/look-and-feel in Flutter app. But having a well-thought-out design system is a different beast. Luckily, decoupling is on the way [2] and I hope it will lead to a boom of nice design systems implementations.
Also, because Flutter originally was targeting mobile development, and expanded to desktop/web almost accidentally, the majority of the widgets are optimized for mobile UI. For example, if you want a date input field that feels native to a desktop user, with masking and yet a calendar picker – good luck finding one. And as I create desktop/mobile apps 50/50, I settled for now with forui [3] design system, heavily inspired by shadcn.
Performance has been the last of my concerns with Flutter, because the engine was originally heavily optimized to hit <15ms frame rendering and modern web renderer is using Wasm and shader precomilation and some dark magic I don't even want to know about. And to be honest, my own experience with "web apps" is so bad, that I don't think any non-native-to-browser rendering pipeline can make it worse. Like, having UI glitches and unresponsive components, bad state management, need to refresh the page (which is essentially a "restart an app" in web), mess with forms/fields it's just such a normal experience in web. I don't have any of that with Flutter web apps. They might feel a little bit "non-native" to HTML-based web apps, but I never heard real users caring about that.
[1] https://pub.dev/packages/device_preview
[2] https://docs.google.com/document/d/189AbzVGpxhQczTcdfJd13o_E...
What would you suggest as the best resource to learn flutter, for a well experienced developer?
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.
Agh, sorry about this! I'm one of the people building leaflet.pub, which this blog is running on. Just pushed a fix for this (ironically on nextjs/vercel). The redirect loop is to handle sharing auth between our "main" domain, and people's various custom subdomains. Auth, via the ATProtocol, is used for things like subscribing and commenting!
a lot of this BS is avoided when you code native you know.... was the sole benefit to web (not having to distribute new binaries) really worth it?
The slow response time on hithub is most likely due to layoffs
may the title of this should say Next.js middleware /logging is infuriating
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 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.
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.
>is this even a word
Everything can be a word if you know what you're trying to say. Don't let anyone tell you otherwise. If they try, say: фakdelengiчpolis!
Even though I'm a fan of looking for underlying motivations to what people do, I'd be wary of pointing out "only" reasons for anything. I know it's a rhetorical exaggeration, but still.
For example, I've found Node to do what Python does, only better. For example, Node does dependency resolution without involving the OS package manager. And ultimately, people end up using whatever they become comfortable with.
Which is not an exact science and people resist it being made into one. (Maybe if it was, it'd be much easier to sell people on working with the "least worst" tooling that is not actually good for anything.)
But the important thing is that on the backend they're all different. The baseline is the CPU, and you get to choose between real tools with real histories of real tradeoffs. Even if the tradeoff is "run JS" or "be written in C++" or smth else.
On the frontend, the baseline is JS, and whatever the browsers bolt to JS, and as us few sane keep pointing out, JS land is already such an "OS-within-an-OS" that there is very little point to building entire freaking frameworks between that and the application, just for the sake of having to swim through someone else's moat instead of invoking the APIs directly (which are also better designed for the most part).
So, in order to differentiate the market, one would need to build at least 1 "layer of layers" on top of JS, some products in which are gonna more pointless, while others are gonna be less pointless (all of this to all different people of course). That way the user gets to choose between what sucks more vs what sucks less, and one gets to feed on the attention paid to the choice of lesser evil; or -- if insufficient attention is paid -- to entirely direct the choice in whatever direction. It's a win-win.
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.
RoR wasn't picked up by e-commerce at this scale. Most of the craziness comes from attempting to squeeze out every last inch of performance so that the prospective client won't go "neeeih" and shop somewhere else.
A RoR app will just sit comfortably wherever you deploy it, slowly doing its job like a good, reliable tractor.
A typical Next.js app is smeared all across its origin, some geographically convenient Edge and the frontend. It's a very different use case.
what do you mean? Shopify is the largest eCommerce platform and runs rails.
I think they mean that Shopify doesn't decide what happens or doesn't happen to Rails; Vercel decides what happens or doesn't happen to NextJS.
Tobi is Ex-Rails Core contributor and Shopify is significantly contributing to Rails and Ruby.
Like said in the article, most other JS frameworks are actually pretty good these days.
I work with Vue 2 and Vue 3, both options and composition APIs and both are pretty great. I dont know how it's like for very complex UI but it 100% fulfills my needs.
Also shout out to Pinia, I love you!
I have a monstrosity of a Vue 3 project at work and I far prefer it to any "elegant" React codebase I've ever had the displeasure of working with. Boggles the mind that React still has any mindshare to me, Vue and Svelte are both superior to it in pretty much every way except for availability of component libraries (which isn't so relevant in my line of work), and a slight edge in terms of TypeScript support (mostly a problem with Vue's props).
Yea I would agree. I do not use component libraries ever as I prefer building my own. But I also know that stuff like shadcn also has Vue variants.
Yeah, vue is really easy to work with, conceptually simpler and has so many more niceties.
I think React is fine, the problem is that every single react app I've inherited is ass - people just do everything incorrectly and overcomplicate simple things. Components with like 5 different useEffects, huge global state causing all kinds of bugs, way too much frontend logic in general. The amount of JS code that exists just to mimic things you can do with HTML and CSS is staggering.
Everyone complains that react is so slow and horrible, it isn't. It's their code that's slow and horrible, react is snappy as hell when you use it properly.
> It's their code that's slow and horrible, react is snappy as hell when you use it properly.
That's the problem though, it's hilariously easy to shoot yourself in the foot with React. If almost every project makes the same common mistakes, it ceases being an issue with the people using it, it's a broader problem. With Vue or Svelte you'd have to try damned hard and go out of your way to mess up in similar ways, because the idiomatic way of writing Vue, especially with Options API, is so simple and straightforward. How many articles do we have out there begging people to please stop using `useEffect`, for example?
Plus, React's reactivity model is terrible and a source of a lot of performance pitfalls. Vue's and Svelte's Proxy/Signals-based approach is much more performant out the gate, and in the case of Vue the diff reconciliation algorithm is a lot better than React's, which itself will already prevent a bunch of useless re-renders compared to 'standard' React apps.
I don't know Vue so I can't compare. All I know is when I write react apps they're simple, nice and snappy. And I'm not even a frontend dev nor a JS dev, I mainly work backend. It's not that hard. In fact it's significantly harder to write a horrible mess. I have to spend ages cleaning up before I can start doing real work, because I can't deal with the horrible messes people make.
This isn't just a react problem by the way, people write horrible messy backend code as well so I'm having a hard time believing that they wouldn't find a way to make a horrible mess of a Vue app as well.
But maybe you're right, maybe it is better. I wouldn't know.
I mean don't get me wrong, I'm not saying Vue is perfect, it has its share of annoyances that I hope get resolved, mostly around poor typescript experience with things like props and events for example. But for your average day-to-day Vue experience, it is in my opinion so much more productive than React, and importantly for the less skilled/knowledgeable members of the team it's so much harder to fuck up than React is. And as I said in my original comment, the codebase at work I maintain is a monstrosity, but because of Vue's patterns it's also easier to deal with and fix than the equivalent fucked up React version would be.
I'd recommend giving it, and especially Svelte, a try, especially with Options API in Vue (but CompAPI is nice too). It's really clear early on how simple it is, despite it paradoxically having more to it than React does (like the event/prop system)
> Everyone complains that react is so slow and horrible, it isn't. It's their code that's slow and horrible, react is snappy as hell when you use it properly.
Why use something that you have to use "properly" when there are things out there that enforce being used properly?
Because I'm not convinced there exists a programming language/library/framework that you can't use improperly.
And just to be clear I'm not saying react is better than Vue. I don't know Vue. Maybe it is better. All I'm saying is react is alright in my experience, the problem is people overcomplicate and mess things up. I've seen that in pretty much every piece of software I've ever worked on, backend/frontend/whatever. So the claim that Vue just magically can't be messed up is difficult for me to believe.
I can understand that. For me personally, Vue has a limited set of lifecycle hooks you can use so its hard to pick the wrong one. React on the other hand gives u some kind of use_ for everything, so its first and foremost harder to understand the app lifecycle and to pick the correct hook.
With Vue I started to use Pinia for my whole apps state management, which are data stores. Clean and centralized logic, with React idk what a substitute would be.
I know React can be clean too, but that (in my opinion) requires a lot more depth of knowledge about the framework.
Yet 95% of fresh companies raising funds use that cursed NextJS framework.
This feels a whole lot like when everybody with VC cash was using Mongo. And I see that as a competitive advantage if your competitor is using these types of technologies, it means you can out maneuver them and build a better product.
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?
> Was Express ever _that_ easy before you actually understood it and knew what you were doing?
yes
also sails.js was the bomb.
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.
To be fair Next.js is just following the natural progression of what their product always has been: holding devs' hands in all things deployment at the expense of vendor lock-in. Being aware of Vercel's limitations is not about the open web, it just means you should be setting up servers yourself at this point.
This
I was talking to a fellow dev at the company I work at and he was extolling the virtues of one-click nextjs deployments. As the conversation progressed it turned out he'd never actually had to set up or manage his own servers and felt that it was a waste of time for him to learn.
It hurt my soul. I am considering linking this article, but i feel it may come across as aggressive.
I don't get these kind of complaints, coming from Java and .NET web frameworks, Next,js is the only sane frontend framework followed by Angular.
Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.
I don't think the post is an unreasonable complaint. The fact that you have to even think about how to get logs out of your application is insane, never mind all the hoops you need here. Logging should be a first class citizen in anything that goes to production.
Interesting, because that is hardly so in most frameworks, logging requires additional libraries and configuration almost everywhere.
In most languages and frameworks logging is as simple as import, initialize, done. Here it's far from it.
Really, which ones?
Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.
> .NET
I think you haven't used .NET in a while. Nowadays, logging is absurdly easy to configure. Heck, you usually don't even need to configure it, because the basics are already included in most templates. You just use the Logger class and it works.
The only time you have to spend more than 30 minutes on it is when you use some external logging libraries. And most of them are quite sane and simple to use, because it's so easy to create a custom logging provider.
Log4j can be as simple as add the dependency and you're good to go. Of course, you can do fancier setups and bridge your logs wherever where it is more work, but out of the box, it's very straightforward and batteries included. I have a very hard time believing you're seriously arguing the case that some of the most commonly used languages don't have good options for logging.
Which Java framework has log4j working out of the box for serious production deployment?
Spring Boot for example, which is arguably one of the most common ways to do Java anything these days. If you're trying to make a point, it would be considerably easier if you just said what you mean, because so far you're not making one. You could've easily looked up any of these questions.
Wrong again.
Spring Boot doesn't provide a serious production quality deployment without configuration.
Bare bones logging into standard out, yes.
That isn't production quality.
Production quality is telemetry logging, log rotation and zipping, forwarding logs to Kibana or Datadog dashboard.
This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than telling.
Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case.
Word vomit into standard output isn't production quality.
It seems you might've missed functional reading class. The first thing I led with was that you need to import and initialize logging which covers both of those. You're the only one insinuating the strawmen you're arguing against. This isn't Reddit, surely you can do better.
Angular is absolutely not a sane framework. I'd argue it used to be, but you can't build trust in anything after being rugpulled with 4+ major breaking refactors over the years. If you get it that wrong that many times, I start to wonder what the actual purpose of the framework is.
Angular isn't doing bad on the backwards compatibility front. Case in point: ParamMap was introduced at some point as a successor to Params, but the people revolted, so both are available without favouring one or the other:
https://github.com/angular/angular/pull/43529#issuecomment-9...
It's kind of funny in hindsight, but at least we didn't have to modify every project just to update such a minor thing which was working already anyway.
In this regard the thing that absolutely sucks is the migration tool. Your best course of action is to update the versions manually in package.json, read the documentation on breaking changes and act accordingly.
In my view Angular was always insane, but it's becoming saner with each subsequent version. We now have typed forms (that took a while), standalone components and, most importantly, signals, which do most of the stuff RxJS is doing, but without the junior-killing hidden state and memory leaks.
Really just one major breaking refactor in 13 years, and that is partly because not only have we learned a ton, but browsers themselves have changed dramatically. I'm not going to say it was perfectly handled, but they also didn't have nearly as much support from Google back then.
In consulting we don't do upgrades, we come, we deliver, and we leave, with maintenance contracts for existing deployed versions.
For an upgrade someone has to pay for it anyway, so whatever pains there are, they are reflected on project budget anyway.
More devs should do the math of work hours to money.
This really highlights one of the main differences between "product" and "project" centric work. With a project, it's the client's problem ($$$.) Usually they'll balk at the dollars and effort required and accept the risks. Even with an outdated, obsolete framework, the actual risks are often minimal. "It's still working, right?"
> Angular is absolutely not a sane framework
I have not worked with older versions, but with V20 & signals, it has been pretty good.
I kinda get what you are talking about (did those refactors too...), but which of major changes had such a high impact in your case?
I’m guessing you enjoyed the nostalgia when you saw directory based path convention from the good old CGI days?
It is more the irony of pendulum going back and forth between generations.
[flagged]
Please don't post unsubstantive comments here.
JavaScript was made insufficiently expressive on purpose (see Eich, Sun, Scheme).
He still ended up sneaking some metaprogramming capabilities into it, though he stopped short of something recognizable like macros.
So when the highest grade vendors started taking front end extra seriously since I'd say 2008-2010, what they built basically bulldozed over the things that made JS per se tolerable. Instead, they built frameworks out of the standard imperative primitives in JS, which take things in more of a C++-inspired direction.
The "growth hack" is here, as with vaunted Apple, vertical integration. The only way to couple markup to state management to server/client flow does not amount to a framework; it amounts to no framework since the Web was not invented by VCs.
To get a framework out of it, i.e. couple developers' practical knowledge to your ecosystem (turning it from general to domain specific but fuck devs right), you also need to couple things in your stack at the wrong places, as exemplified by the already much-maligned misfeature explored in TFA.
I.e. for the onboarding flow of a hosting business to work in 2025, you first need to have been teaching bad architecture for a generation. (It's why Meteor.js didn't take.)
On the one hand, pragmatic of Vercel to exist in the long shadow of the React/TS monstrosities. On the other hand, it's just one more company whose mere existence in this world has contributed for my work and life becoming harder for no real reason, even though nobody I'm within a handshake is even their customer.
Like many, I only learned of them only when I googled, "who the hell made this horrible thing the frontend team over is now stuck with, it's 0.01xing their velocity and frying their brains besides" and, well, now they're here. I would like to remind them to try and measure their externalities.
Thank you for censoring the word "shit." We try to keep Hacker News clean, for families and children.
You’re welcome