I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts.
Next.js is easily the worst technology I've ever used.
I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase.
Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly.
Infinite complexity everywhere, breaking changes CONSTANTLY, impenetrable documentation everywhere.
It is just so, so awful. If we rewound the last five years of FE trends and instead focused on teaching the stuff that existed at the time properly, we'd be in a much better position.
I've also built a very complex React frontend (few thousand users, pretty heavy visual computation required in many places). And while I don't particularly like React either, Next.js was even worse.
And lastly, built a CMS in Go, with vanilla JS. And while the DX sometimes feels lacking, I just can't help but feel that I actually know wtf is going to happen when I do something. Why is that so hard?
In React and Next.js I am STILL, AFTER SIX YEARS constantly guessing what might happen. Yes, I can fix just about anything these frameworks throw at me, thanks to all the experience I've gathered about their quirks, but it all just feels to messy and badly designed.
In Go, the last time I guessed what might happen was in the first six months of learning it. No surprises since. Codebases from years ago are still rock-solid.
Why can't we do this at the frontend, goddammit?
" Codebases from years ago are still rock-solid." This is the biggest thing for me. I recently pulled down an 8 year old hobby Java/Maven project I had and it compiled and ran perfectly on the first try. Imagine trying to get an 8 year old javascript project to work...
At my previous startup (co-founder who made all technical decisions) we were unfortunately stuck with React Native. I had Mondays that started with the project not building after some dependency changes. Imagine something failing to build 3 days after you've last touched the codebase…
Just did, I installed the version of node specified somewhere, codified it into mise, and was up and running in no time.
You mean like this?
nvm use && npm i && npm run dev
Does NPM work for you in the first place? Much less after 5 years? They’ll have gone through 2 major revisions on their lock file format, and it’ll complain you don’t have the exact version of node specified in your package.json
Oops, one of the dependencies is a C++ library that doesn't compile on your less-than-five-years old arch.
That only works if the project is constantly maintained. Otherwise it can and will break in time.
Ok, 50 packages have critical vulnerabilities now
And another 30 didn't use versioning correctly so they installed new dependencies of their own that broke things three levels deep. Yes, based on a true story.
[dead]
I think the big complex FE frameworks are going to go away. After doing work with HTMX and Alpine JS, and Ruby on Rails with Turbo + Stimulus, I am all in on this paradigm. Basic JS, or a micro front end framework is all you really need.
it might be a bit over the top but there is Cogent Core[0]; it supports apps on desktop, mobile apps, and the web. it even supports 2d and 3d. and it's all in go, backend and frontend (using WASM).
[0] https://github.com/cogentcore/core
As much as I hate Next.js as the next guy, let's please not push full canvas rendering approaches. They SUCK. Their https://www.cogentcore.org/core/ own site is slow to load, scrolling is visually painful since it render at what I assume is 60Hz and not my native much higher monitor refresh rate. They are expensive in terms of computation, wasting resources on the machine, to display text. Want to select text, better hope the developers want you to be able to select text or didn't forget to do so, case in point text inside buttons. Accessibility is also usually much weaker, screen readers often suffer and if they don't something else will.
Canvas instead of DOM -> :(
EDIT: Gave it another try and more issues appear, within seconds of using. The left side has a rendering bug where the selected areas are cut off sometimes, ctrl+zoom does not zoom the page as it does on all normal websites. I can still zoom via menu. Middle mouse open link in new tab doesn't work. Z layer bugs everywhere. I expect more the longer I'd look.
Oh my god, I thought you were exaggerating at least a little.
The “static preview” it shows while it loads (for like 10-15 seconds!) is so much smoother and nicer to scroll around than the actual thing. On mobile, every third scroll attempt actually opens the right click context menu. It’s a stuttering mess on my high refresh rate phone. Nobody should ever make websites like this.
wow this is bad! like truly bad UX. please don't recommend this.
I typed "0" into the scaling field to see how it handled it, and couldn't recover from there...
it's completely shit
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it should run anywhere!' and I took a run at it.
After a week of futzing with it I just threw up my hands and said 'no can do'. I couldn't untangle the spaghetti JS and piles of libraries. 'Compiling' would complete and if you looked at the output it was clearly missing tons of bits but never threw an error. Just tons of weirdness from the toolchain to the deployment platform.
I haven't heard anything about trends, stereotypes, positives, and negatives regarding IT and development in Africa. Following HN's guideline to increase curiosity as topics get more divisive (as this subthread has), and looking for "the strongest plausible interpretation of what someone says" I'm going to assume the best:
What's the story here? I assume this group was chosen for a reason and didn't meet expectations.
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.
"We don't know a lot about this, let's hire some experts to handle it for us"
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.
[flagged]
When I read "African engineering group" I felt an instant "ugh" of recognition, based on my experience with software created by external consultants on other continents. My experiences were with groups in Asia and Europe, not Africa, so I think what the poster successfully evoked was the experience of dealing with differences of distance, culture, time zone, and commercial interest (engineers answerable to different management and a different bottom line,) all of which tend to produce inferior software compared to what gets produced for in-house use or sale in the SaaS market.
Exactly--bad work can be from anywhere. However working with contractors at this kind of distance, through a language barrier, with different societal norms (for example, the US project manager was a woman, and the programmers just completely ignored things she said. If myself or another man was present, they completely changed their tone and would immediately act on things we said. Our project manager was pretty much ignored or steam rolled at every turn) is extremely difficult.
Yup, we do. Mind you, I'm not an american. But we often say something like "the americans" or other less flattering terms.
Here come the police, ever-vigilant for perceived or potential slights. Bless you, Officer.
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)
Hi! I maintain Redux and am deeply involved in the React community, and have spent a lot of time both critiquing the React team's decisions and explaining their decisions to the community.
I actually wrote exactly that blog post and did a conf talk on it earlier this year. I covered why the React team switched to directing users to use "frameworks" to build React apps, the development influences behind React Server Components, why the React docs didn't list tools like Vite as viable options until just a couple months ago, and various other related topics:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
- https://blog.isquaredsoftware.com/2025/06/presentations-reac...
Thank you for the writeups. I learned a lot reading those.
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
I feel like that describes a whole bunch of "FOSS-project-backed-by-consulting-company" packages. You want it to be good enough to become industry standard, but painful enough to figure out on your own that anyone with the budget will just pay the developer to do it for them.
Same. Feels like it's a lure into a vendor lock
Better use something else
Not a web developer, but I do small web projects from time to time.
I heard this excuse for Next.js and thought I’d get around it by using Vercel, which was fine for my project. It didn’t seem to make a difference.
[dead]
> I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here we are.
The train of thought is “what is everyone using? I’ll use that too”
This coupled with the fact that "web development" now means anything going from a content rich website like a blog, towards some e-shop, all the way to complex applications like ux design, video editing, etc.
It's pretty absurd to have such a broad range of web solutions, and think the same solution can cover everything.
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?
> Then why did HTML became so popular if win32 or MFC were so great?
One of the factors is that web dev pushes for a complete separation of concerns, and thus allows frontend developers to specialize in front end development. Therefore it becomes far easier to hire someone to do frontend work with a webdev background than a win32/MFC background.
Number of applicants is also a big factor. There is far more demand for webdev than pure GUI programming. You can only hire people who show up, and if no one shows up then you need to scramble.
Frontend development is also by far the most expensive part of a project. In projects which use low-level native frameworks you are forced to hire a team for each target platform. Adopting technologies that implement GUIs with webpages running in a WebView allow projects to halve the cost. This is also why technologies like React Native shine.
Also, apps like Visual Studio Code prove that webview-based apps can be both nice to look at and be performant.
It's not capabilities. It's mainly the economics.
In the win32/MFC days, there was no "front-end developer". There was only HTML and content creators writing it.
Then there came small web applications, and still no "front-end developers", since functionality could only work on the server.
It's only when AJAX was introduced in the mid 2000's that you could start to talk about "front-end developers".
By that time, win32 and MFC was old. We had Java, C# with .net framework, etc.
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.
> The train of thought is “what is everyone using? I’ll use that too”
I'm not so sure about that. We're seeing Next.js being pushed as the successor of create-react-app even in react.dev[1], which as a premise is kind of stupid. There is something wrong definitely going on.
[1] https://react.dev/learn/creating-a-react-app
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.
This surprises me a lot. I spin up new react apps with vite often to replicate issues with 3rd party libs we use. Like how do they not know you can just spin something up over on CodePen or CodeSandbox and there's not a hint of a server side paradigm required? (sure, vite has a little server but you don't really need to know anything about it)
Some devs have worked exclusively in feature mills where expectations are rock bottom and some senior setups the project for them. When recruiters don't filter them, a basic React test has to.
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.)
It's not React "minutiae". It's incredibly basic concepts, that if you don't know, you cannot in good faith say you know react.
It's like not knowing how to write a for loop or how to access an object's property in JavaScript.
I remember one of the first technical interviews I conducted about 15 years ago, I asked the candidate the difference between == and ===. She had the same answer as gp, claiming the doesn't "memorize minutiae like that."
> 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?
The most basic React functionality isn't "React minutiae".
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.
> Not necessarily since they have to do with the inherently complex niche features like unified server/client rendering (...)
My point is that it's fishy how they push features that just so happen to be the value proposition of the only corporation that just so happens to be able to implement them.
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 is only partially true. For example, with React Native even the core team now tells you to "just use Expo", as if relegating all responsibility to a project maintained by a for-profit that thinks 2 weeks is enough time to beta test a Major release.
It's also dismissive of market forces, i.e. developers have to pay bills and therefore are easier to hire if they know the skillset that is in wide use.
I've never worked or interviewed a single senior that wanted to use Next.
Second worst for me. I’ve used Sharepoint.
Third worst if you have used Lotus Notes mail. I still don't understand how an email and calendar client can slow down a computer like that (going by memory, the last time I used it was at work in 2013 so pre-SSD days).
Everyone at IBM when I worked where used Fetchnotes (internal tool that leaked onto the internet that wraps Lotus notes .so file and allows you to use normal email / contact / calendaring programs and formats).
Well... I don't know exactly what the OP meant by "technology", but Notes at least wasn't supposed to be a development platform.
It surely was a development platform, but wasn't supposed to be one.
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.
What do you mean you don't want to step through scripts with a debugger just to understand how to use the official APIs? I'm sure it's better these days, but Sharepoint was one of the platforms I worked with when I was younger and it still gives me bad flashbacks whenever it comes up.
I remember a few early projects that revolved around SP, but one that stands out as "special" was using the SOAP APIs to update a WordPress site. It was a special hell, every hour it would fetch any updates, and push them to the specific WP content-type (iirc - content-types might not have existed yet - this was 2008).
The reason for this, IT had contracted for a content management system from a Microsoft shop, because the CIO was a former Accenture/Avanade consultant. But the brochure-ware website had already been contracted to some random NYC-based web firm, but the CIO didn't want multiple usernames/passwords, so after the WordPress site hand been build, they hired the SharePoint consultants to build out the CMS that the employees would use, but it still didn't hook up to wordpress, so then it became another contractor's job (me) to join the two.
I had worked on Word Press, I even had a few decently popular plugins, but I had never seen the absolute hellscape that was SharePoint before. I wrote a codegen tool that would read the WSDL and create a library with all the classes and calls needed to use it without any SharePoint experience, and wrote some simple ETLs for the handful of "buckets". It was a 2-3 month long journey, but those libraries and my code are still in place today, where they still use wordpress for front-end, and sharepoint as backend (or at least did in 2022 still, the last I talked to anyone still working there).
Some people get my hatred for Teams, and some people don't. Most of the ones who do had to use Sharepoint at some point, and can see its pointy little horns sticking out of Teams.
No one will understand until they’ve seen it with their own eyes.
You have my sympathy.
To me, Sharepoint feels like it's not sure what it's supposed to be, so it tries to be everything, and so feature creep has run so rampant that it's just an utter mess with awful performance.
To me, Sharepoint feels like it was vibe coded by the first primitive coding agent, and then made worse over time.
I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity.
I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router).
Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it. My marketing site is entirely static, and my app is entirely client rendered.
I also use next and use the pages router. Makes for a development friendly react front end.
And I have some use cases where I want to have a headless crm/api “hidden” behind the front end. So in these cases using next as a backend proxy works well for me.
I regret “upgrading” my personal site to app router. Big mistake esp for is an almost purely static site.
Sadly tan stacks releases a new version every other day and react router was complete 5 versions ago but cannot seem to keep changing the api to stay relevant in the never ending js relevancy ending war.
I would recommend React Router over Tanstack. I tried both and RR was so much easier and more reliable.
Tanstack seems to be following Next.js in that they’re just over complicating everything and their docs felt lacking for the most of their features.
I've only ever used Tan's React-Query and I absolutely love it inside of a React codebase.
https://tanstack.com/query/v5/docs/framework/react/overview
Why're trying to move off next? What makes the opportunity cost worth it?
Looking for full control over where the frontend is hosted. Sure, I can run Next.js elsewhere, but I could also run React Router elsewhere and have a much better overall experience in the process.
Hm could you explain further? Why is React Router going to lead to a better experience?
You don't understand why being able to freely pick your vendors might lead to a better experience?
Yes, and even if you manage to work around its profoundly silly limitations—seriously who designed the new routing nonsense and have they ever made a website before—every time you go to upgrade the new version breaks everything.
By comparison, DIY SSR with Express takes a few days to get working and has run quietly for multiple projects for years on end.
Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too.
I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way, you'll end up with next.js alike piles of reinvented wheels and abstractions (that in the end are always leaking anyway)
>Windows doesn't (didn't?) have ENV vars
Nope, windows has had perfectly standard environment variables since the DOS days
What's "missing" is the ability to launch things the "Bash" way: `KEY=value ./myApp`. Where the variable is scoped to the single execution.
Windows' command prompt requires two separate invocations:
PowerShell also: Or more "verbosely/explicitly": Regardless, all those methods aren't "scoped".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.
Because it's objects, not text. It "scales" a lot better in your brain because in general you need to know a lot less than in bash. No more awkward sed and awk scripts, manipulating objects is a breeze. Awkward syntax at places where you have to create an object from scratch is a fair price.
Right? This is your brain on Windows.
yeah | it's | so | much | better | with | bash | tr | cut -d' ' -t5 | jq .entry[].text | sed -i s/who/evenknows/g
Anyone who has ever maintained a semi complex set of bash invocations and pipes knows it's a fragile incantation that breaks anytime you look at it funny, or something in your chain produces unexpected output.
Powershell, while absolutely horrible to read and only slightly less horrible to write (hey look, proper auto completion instead of trying to cut on the 4th, wait no sorry 5th, ah fuck it's the 6th there's an invisible space) at least produces consistent and reproductible results.
No, your python script doesn't count, it makes me do a pip install requests. Oh, sorry, pip can't be used like that, gotta run apt instill python3-pip or my whole system breaks.
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.
> because Windows doesn't (didn't?) have ENV vars.
As long as I can remember in my career, Windows had environment variables. So that's at least 25 years. It's both available to view/edit in the GUI and at the prompt.
Damn, I didn't know someone could be so clueless about Windows or operating system history in general. What the hell do they teach in computer science these days
Port detection? Thread management? These things have nothing to do with next.js right?
The most frustrating thing about Next.js is that it tries to be a really cool Rails/Wordpress/Meteor-like full-stack everything-and-the-kitchen-sink framework, but you quickly realize that all the opinions you delegate for it to make are, like, the most boring possible things it could choose to take opinions on (e.g. its opinions about middleware, image resizing, SSR-everywhere, etc) while the actually productive opinions it could take it leaves to you (database, ORM, communication protocols). Its not remotely in the same realm as Rails/Wordpress/Meteor.
Framework-defined infrastructure is a seriously cool and interesting idea, but nowadays Next feels more like an Infrastructure-defined framework; the Vercel platform's architecture and design are why things in Next are the way they are. It was supposed to be "Vercel adapts to Next", but instead we got four different kinds of subtly different function runtimes. My usage dashboard says my two most-used things are "Fluid Active CPU" and "ISR Writes". I just pay them $20/mo and pray none of those usages go over 100% because I wouldn't have the first clue why I'm going over if it does.
Half the labels on there are Star Trek technobabel, which I would take the effort of learning, except I'm convinced they're all going to change with the next major release anyway. Partly because, I keep hoping & praying they will. I know a concerning number of former die-hard Zeit fans who've taken their projects and customers elsewhere. At the end of the day, if they were to ask me what they need to address in the next major release, I seriously do not know how to answer that question beside "practically every major and minor decision y'all have made since and including the App Router was the wrong one". How do you recover from that? Idk.
My biggest problem with it now is the official React team pushes it as their framework of choice. Back when it used the Pages Router and wasn't trying to push everything into server components, etc., it wasn't terrible but I can't help but feel bad for any newcomers trying to learn web development.
I switched to Astro from Next for most projects and haven't looked back. It's such a breath of fresh air to use.
Next.js was a godsend when it came out because of how easy it made SSR. Many React projects don't need SSR, but for those that do it was technically complicated and time-consuming to hand-roll it.
I was part of a successful large project where we did our own SSR implementation, and we were always tinkering with it. It wasted a lot of time. Next.js "just worked". I've used Next with the pages router on two significant and complex projects and it was a great choice. I have no regrets choosing it.
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.
Spring Boot pulls in countless dependencies without warning. It can generate classes without you asking it to. It will run code just because you added a dependency, even if you don't explicitly call it. A lot of functionality is action-at-a-distance activated through annotations, which could just as easily be simple method calls which are easier to trace and debug. Version updates are aggressive about making breaking changes, sometimes seemingly for aesthetic reasons.
It just adds a lot of complexity even if you don't explicitly opt in to it or need it.
Spring Boot is not Spring (Framework). (Yes it makes use of it).
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.
I'm a bit surprised at reading that. I've tried both, Next left a bad taste in my mouth, but Nest was kinda neat. Didn't used it for anything too complicated though, so I'm curious about what sort of grievances people have against Nest.
Something, something enterprise software. I find its dependency injection harder to reason about.
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.
This. It's what inspired me to build a static site generator and web framework built from first principles: https://mastrojs.github.io
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.
I never claimed my preferences were realistic!
Stuff costs money, sure. But I don't think it's that simple. Next and Vercel come from the same organization. I have no objection to a paid hosting solution making it operationally simpler. However when that same org has control over the free thing, they can make it even more easier (probably grammatical! who knows) that it would have "naturally" been.
Lightweight native web components rendered on the light dom with lit-html and a simple API layer in express 5 is about as close to perfect as I've ever found.
The only "weakness" is that it doesn't have guard rails, so may not be great for larger teams with mixed experience.
It's hard for me to give a blanket answer to this. I tend to mostly work on services that offer GraphQL APIs these days, and not so much on client side rendering. For APIs I stick with Go because it's what I'm most familiar with. But I'd also be happy to work on a Django or FastAPI service. Anything is fine really, as long as it's mostly boring technology.
If I had to create something that has a UI I'd just go with a bog standard server rendered multi page app, built using really boring technology as well. If you like Javascript and friends, go with Express. Nowadays you can run Typescript files directly and the built-in test runner is quite capable.
If a single page application makes sense, then go with vanilla React. For a highly interactive application that's potentially behind a log in anyway, you probably don't need React Server Components.
I've really been loving Astro lately, it's simple enough that it stays out of your way and you can host it yourself easily. Gives you nice backend + frontend with the option to drop in React, Vue, Angular, etc if you need them.
react-router if you just want a simple React frontend, write your backend in something else.
Not OP but FYI React Router v7 (fka "Remix") has all the key features of Next.js but none of the bloat or Vercel-driven enshittification.
My personal experience is Remix has all kinds of problems akin to the issues in the blog post, including the mess that is remix -> react router v7. When I worked with Remix a year ago logging and middlewares were also a disaster. For example it didn't have middlewares, and had no way to create a LocalContext from the host (e.g. Express or whatever you use) that first starts handling the request down through the remix app.
I also had the impression they would probably follow the Vercel style, framework as a business model, with it being sold to Shopify.I don't really know where it's all going, but it is not the sort of thing I would tie myself to.
Except when they ship v8 and you'll be forced to restructure your app to the whims of the library creators in case you need to update.
Hono
> Next.js is easily the worst technology I've ever used.
To be fair, this is partly on the kind of people who use it. E.g. if you're trying to build something that's intended to last for 10+ years but you don't think it's worth it to spend the 20 hours watching the Udemy course on Angular, then your technology is going to be a complete dumpster fire no matter which stack you choose.
What is frustrating is that like 3 or 4 major versions ago Next.js was the best thing since sliced bread.
It's almost like the channeled the same problems and bad juju that plagued ext.js.