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