Kinda. I use managed Nextcloud by Hetzner (StorageShare) for ~20 people with their smallest instance (1TB, 4.50 EUR/month) and connected it with a Collabora hosted on the smallest Hetzner VPS (this could use more cores).
If you wanna self-host completly look at https://github.com/nextcloud/all-in-one . I have this running on my NAS for other stuff, but it just works out of the box.
Edit: and it scales. Orgs with a lot more people use it for 10k users or more. And it doesn't need a 100 EUR/month setup, from what I experienced.
We use it as primarily a file sharing thing. We do not use it for video calls (and I woulnd't recomment it for that purpose).Last time I tried integrating with an office suite server was also a pain in the ass. I do use its calendar and dav addressbook because it works fairly well.
The only security thing we've done is disable a few paths in the web configuration and only allow SSO logins. (Authentik). You can also put it behind Authentik's embedded proxy for more security. I didn't do it because of the use case with generic calendar/addresbook software.
Hetzner is good. Great even, in terms of what you get for the money. They do provide mostly professional service. You will not get one iota of extra service other than what they promise. VERY German in that regard and very unapologetic about it. And don't talk about them in public with your real identity attached. They ban people for arbitrary reasons and have their uber fans (children with a 4 dollar vps) convince other fellow users that if you got banned you must have been a Russian hacker trying to infiltrate the Hague.
Really feels like react has held back frontend development. The idea that everything on the web should be written in react is baffling but I'm sure people thought similar thoughts when jquery or angular were popular.
Forget the underlying language, the real shift was this idea that every website should be a single page application, which we are now moving away from again but seemingly everyone has forgotten how to do it, so it's being done "the React way".
This could be because of developer fatigue and the trend of forcing backend devs to do fullstack.
Its very hard to keep up with the frequent changes to programming models, new frameworks, CSS libraries (why the heck are they soo many?!) when you also have to design O(Log n) backends, IaC, Observability, LLMOps, etc.
I have come to a compromise and have started advocating for React/Redux/TS/NextJS as the default CRUD application stack so that I can focus on solving real CS problems in the backend that I’m passionate about.
But react is where developer fatigue is most endemic. Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time. You can easily tell when a react project was started based solely on it's dependencies. This is bad because it typically means no two react projects will use the same dependencies.
These dependencies are the root of the issue.
FWIW, I've only ever professionally work with react on the frontend. For nearly 10 years too. My first job I was doing react.createElement() before classes were shortly introduced afterwards.
It's time that we move on to something better, and the react foundation being controlled by private entities while not being an actual democratic foundation is a good omen of what to expect.
> Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time.
By weird happenstance I got a job writing in a half-dead, compiles-to-JS language 5 years ago. There's one way to handle state in it. My view on the libraries you need to handle everything-but-view in React has been "I'll come back to these when the dust settles" and it just never settles.
None of these have usage numbers that rival react, at least not in the US. I wish it were so because many react libraries can easily support other view libraries with minor modifications to decouple it from react.
Is that so bad though? The major alternatives to React are close enough to React that a competent React dev won’t have much troubling contributing. If you need to hire an expert in Vue or Svelte or even React, you should probably put that in the job description rather than hope that “FE dev” would somehow convey what you want.
Oh sweet summer child, you have no idea what is coming.
The second "happy to pay" becomes "we could hire a team of devs for what we pay vercel" you will realize you made a giant mistake.
Hopefully you will be suffering from success and have the runway to migrate away or just eat the costs, but many many startup die due to impossible unit economics driven by ridiculous hosting costs that platforms like vercel lock you into.
It's just that if I were using Vercel or Next.js (which I don't), I would be viewing my relationship with Vercel on a solely transactional basis. If they were giving away for free something that I needed (React or Next), I would take it. If they were selling something that I needed (Vercel hosting, if I were reckless enough to tie myself to it), I would pay for the service. If they charged too much for the service, I would investigate alternatives. It wouldn't enter my mind that I were "supporting" them. I would rather imagine that they were "supporting" me. And I wouldn't give a monkey's who they have for a CEO.
Do you think a person of Palestinian origin should also continue seeing their relationship with Vercel on a solely transactional basis? Given that their families are likely affected and Vercel's CEO publicly supports it? I'm just trying to point out why people might have a different view on this.
I can't, of course, pretend to know what goes on in the mind of such a person; and of course I accept that people have different views; this is very plain to see. What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
Let me give you a couple of different examples for comparison. Github blocked all users from Iran. Pnpm cut all traffic from Russian ips, whereas Linus Torvalds affirmed the removal of Russian maintainers of the Linux kernel. These are real adversarial actions, the like of which could impact my decisions about a company or a technology, if I were on the receiving end of those. Cowtowing to people in power and taking photos with hateful people is just an undignified behavior that is ultimately just noise.
> What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
It's only natural to think that way because these particular decisions are based on ones moral framework. It isn't like choosing a favourite tea. People will be pissed at each other when moral frameworks don't match.
> Cowtowing to people in power and taking photos with hateful people is just repulsive noise.
It comes down to what you said before. People have different views. It's noise to you. It isn't noise to others.
According to the React team page [0], five members of the team work at Vercel. This has been the case for several years. Vercel has been a major contributor in the development of React. How does the creation of the foundation make React more dependent on Vercel?
Vercel employs maybe half [correction, maybe a quarter] of the React core team. For example, at the keynote at React Conf 2025, it was mentioned that Andrew Clark, who, if I am not mistaken, is employed by Vercel, worked on resolving the rendering issue of React that was blocking the release of React 19 after it was discovered in the release candidate.
Vercel and Next.js have been the main testing ground during the development of React server components as well.
How much has Vercel contributed to the development of react over the past years?
Vercel is the primary driver of react SSR / server components, which has also led to an explosion of complexity in react and has made it less useful as a composable library imo.
The last truly useful react feature for me was error boundaries in React 16 (2017?) and I think hooks was react 16 too?
These days if I need ui components for an existing SSR app I just use web components or lightweight libs like mithril.
It's just a tool. Are the people that run Makita terrible? Who knows, I just use their tools to fix cars. I use tools to build apps for businesses that pay me. There is far too much ideology based decision making in tech. Just build stuff with it or not.
Far too many smart people are putting their energies into such discussions that add a lot of drag to the process of society and humanity moving forward for no net gain at all.
As someone who isn't too familiar with Next and Vercel (having primarily used Nuxt, the Vue equivalent), it's helpful for me to know what's going on in the React world. Discussions like the above are actually helpful in terms of helping people choose between the various frameworks and hosts.
that is your opinion, and is irrelevant to the choice. practically, vercel is a company which is heavily invested in react and react's future, so, they need to be present.
moreover, this entire initiative looks like a way to reduce vercel's influence, so if you want to be mad, then be mad in 5 yrs, not now.
It is also my opinion that 5 years from now Vercel will be out of business and their customers will have moved on the next hype driven VC cash laundry.
If there is only one thing you take from my post, then look up "NextJS middleware auth bypass" or something along those lines. Have fun reading about that and then never touch NextJS or anything Vercel ever again.
I won't repeat what the sibling poster said, but I can tell you, I've been using NextJS from v12-v15 and in that time we've had:
- The catastrophic (and, at the time, UNDOCUMENTED) "aggressive, opt-out caching of all fetch calls", which confused the living daylights out of everyone who suddenly couldn't retrieve updated data from their servers. Like, don't override a native JS function that's supposed to work in an expected way, with black-box magic that adds caching behaviour that then needs to be overriden _per route_ with directives on each route. Cache headers can be added to fetch calls and are easy to configure globally via axios if needed. If you're going to do black magic, call it "nextfetch" or something
- The app router / page router transition was shockingly badly handled, with so much missing documentation around dynamic routes
- I don't know how many different ways of fetching / setting metadata / <head>-related techniques I've had to learn by now. It seems to change all the time. BUT, that isn't the worst part....the worst part was / is:
- You couldn't, for the longest time, fetch metadata for a page without duplicating fetch requests. I think this is where their fetch-deduping thing came from. But again, black-box magic on a native JS function with very inconsistent behaviour, so for a while, all pages in our app just had to make two fetch calls per page that needed specific metadata added to the <head>
- Vercel as a platform not allowing to set billing limits (have fun with your DDoS that they don't recognise as such)
- Middleware is one file. That's what you get. No chaining, nothing. One god-function for everything. Just think about the anti-pattern that is
- I don't know whether it's clever or terrible, but if you want to add a sitemap, you do so by defining a route by creating a folder called sitemap.xml (yes, a directory), where you then put your route.ts which is in keeping with the way the new router should work. But somehow it just doesn't sit right with me. Folders with file extensions. But it also adds a lot of ability to make the sitemap highly customisable and dynamic, so maybe it's ok
- You suddenly needed to start awaiting url params, cookies, etc. which is sort of fine, but was a huge change causing warnings all over the compiler for months and months
Anyway, those are just a few things off the top off my head. I already find React to be quite counter-intuitive and non-deterministic, but NextJS just adds a layer of pain on top with very, very few advantages.
I am dying to get my hands on an alternative, but also don't want to rebuild all of the apps I built when I was still optimistic about NextJS.
As a mostly-backend dev I stumbled across the "metadata in <head>" issue in my first hour of using NextJS for a toy project.
I kept wondering if there's something wrong with me or if a framework recommended in so many places can really be this shitty, until I read your comment.
- fragile under load and very difficult to debug SSR issues
- inconsistent behavior between hosted and self hosted versions of the same code
- horrible build times, like laughably bad multi-minute builds for trivial code bases
- crappy directory based routing system with lots of weird gotchas
- schizo identity JAMstack -> serverless -> ssr -> now its microvms + ai
- multiple hilariously long running GH issues where the dev team is thrashing around trying to debug their own black box framework
- "framework" that barely provides any of the primitives necessary to build web apps
- major breaking changes around core features like routing that require painful migrations
- general sloppiness, churn, and insecurity that comes from being part of the nodejs ecosystem
Thats not even getting into all of the shady patterns vercel uses to lock you into their overpriced hosting.
I've been a part of multiple teams that decided to build apps using NextJS, and while the FE is not my responsibility I typically got pulled in to help troubleshoot random issues. It was a complete waste of time in almost every case, and in one case resulted in the entire FE team being let go because they were unable to ship anything on time.
Yeah matches my experience. It’s just so much complexity just to get SSR. I’ve worked at places that used it for b2b SaaS apps with no public web part, so the SSR is just a big liability… whyyyyy
I use it for my web site where SSR is critical for SEO. For app development I don’t use Nextjs. I think it is designed for web sites (as opposed to web apps) and it is great for this purpose
I think Meteor is finally starting to fully overcome the tech debt from the second half of the last decade. They're in a recent Node.js release, and the next version will integrate a modern bundler (Rspack) in its tooling.
Lots of apps are still stuck in Meteor 2.x hell because of the dependency on Fibers though.
I was pretty involved in their stack back in the day, it was a good alternative to Django at the time for simple plug and play admin apps, and to this day i think they had the simplest OAuth setup of any framework I've used.
The real issues were the super tight coupling with MongoDB and their decision to roll their own package ecosystem instead of just using npm from day one.
Not to mention their braindead decision to aggressively cache everything as much as possible, which they're now trying to undo, but still haven't shipped.
Used Astro for a pro bono project. Found it fantastic, well documented, provides solutions for the hard parts, gets out of the way for the easy parts. Documentation is well written, but I find I don't need it much because mostly it works how I would expect.
You lost me at React SSR. That is part of the complexity bs. React is a lib for mapping state to the DOM. There's no DOM on the server. So React on the server is 95% useless for that purpose and hence, overengineered to create a bit of HTML and send it down the wire.
I like the simplicity of Hono and use their html helper to write good old HTML that is send to the client.
Hono is a server-side framework like Express. So same way like you handle application state in most server-side multi-page web apps: You just fetch whatever you need from the DB per request.
"State management" really isn't that much of an issue on the server. Only on clients, when you need to map state changes to DOM updates.
I've heard good things, what would you say is the killer reasons to justify being the nodejs ecosystem vs something more purpose built for ssr like php?
I know Vercel has their fingers in a bunch of pies, but is there any significant vendor locking? I worked at a place where we just put nextJS in a docker container and hosted it ourselves, but maybe we would have got more on Vercel?
I often read that Next.js sucks. Meanwhile I and many other devs I've spoken to IRL find it does what we need it to do without any issues. Ya'll just some haters.
For all my criticisms of it, I built two commercial apps in it. I worked around the issues and it was fine.
I've also built commercial apps in other stacks and they also have their warts.
What I've noticed from the other stacks, however, is that the frequency of entirely unnecessary issues is simply lower. React and NextJS aren't going anywhere and one can hope that these things will improve over time.
Ultimately, it's also a great employment guarantee, as companies will need people to maintain the apps that are constantly changing.
I think applying scepticism to Vercel and its motives is healthy, still.
See the various other comments for concrete examples of why nextjs sucks and the team at vercel is incompetent when it comes to auth, middleware, caching, and just generally maintaining a usable framework without brutal migrations and api breakages.
They have made egregious mistakes that go far beyond "move fast and break things" and well into "we should have the lawyers join this call".
The people with money don't care, as the very next day Vercel got a series F. That is funny tho because I remember him being pretty anti-israel back in our High school on the long defunct semi-official foropelle.com.ar he owned and managed.
He is a programming prodigy, and that's it. Not a nice person.
Nevertheless, my anecdote should only be taken with a grain of salt... After all, the only person that probably has backups of foropelle is Rauch himself. And who cares what a teenager had to say back in 2006?
1. Vercel / Next are complete technical trash wrapped in egregious vendor lock-in. This directly influences their desire to steer the react foundation in a direction that aligns with their roadmap for Vercel/Next.
2. Their CEO thought it would be a good idea to have a photo op with perhaps the most controversial figure in world politics. This just means he's not nearly as smart as he thinks he is and likely needs a handler.
If he didn't want political commentary being brought into discussions about the company he leads he should have used his big CEO brain to determine that a photo op with a highly polarizing fascist world leader is not a good look.
What's a red flag is that there are 3 new accounts commenting on this reply and all are in agreement supporting your view.
Edit: apparently there's some confusion about my comment. I neither use, like, or support Next. I just found it suspicious that a bunch of new accounts showed up making generic comments in support of OP, which to me was a red flag.
Maybe people are afraid to speak up? I've gotten a fair bit of backlash on my negative complaints about NextJS on Reddit, someone even necro-posting on a months old reply then continuing "debating".
I think a somewhat neutral summary (of someone still annoyed by Vercel/Next) would be like this (Notice the distinctions between Site and App, not always clear cut but a dividing line imho):
- React was created by FB to solve real technical issues as their frontend became larger and more complex.
- Site creators liked it as it was one of the solutions of a real issue of reconcilliation of state and view (that often wasn't so bad in the big picture) but React was often a bit heavyweight, App creators really loved it as state reconcilliation took away that entire class of bugs that just became so much worse quickly as Apps grew (and React allowed for more people to create larger apps).
(Angular and Vue has always done this also, they are parallel developments)
- Pressure from those doing sites has always pushed development of React to be "simpler", often good for most parties (even if I think that Redux was mostly thrown overboard prematurely).
- Part of simplifications was bootstrapping, create-react-app became one of the recommended ways to start projects (and was also incorporated into other toolchains such as .NET templates)
- Heavy builds, disabled JavaScript and SEO issues was teetering issues (especially for public site builders), not entirely sure of the inspirations but Next did solve that (perhaps not always entirely elegantly initially)
- React internals start to change to better support these scenarios, nobody really has objections since changes in React has seldomly been for the worse (functional components, hooks, etc). Vercel gains traction as a "do-good" choice.
- After all troubles of OpenSSL, Node finally adopts OpenSSL 3.0 thus breaking create-react-app that had been "deprecated" by the React team (it's easily shimmable but it sent people looking).
- People looking for options find that the only "official" way to use React according to the site is to use Next, so many start adopting it out of fear of being left behind again.
- The Next model however is quite different and tailored to "site" builders and/or people running the full stack in JS
- React however is quite popular outside of the JS only world for enterprise SPA and/or mobile apps where trying to shoehorn in a Next "frontend-backend" becomes overkill and extra complexity. (We used it for one or two projects but have now abandoned it for our regular work).
- The React site is updated slightly, Vite and similar are now mentioned but the perception damage is there and hasn't let go (and last I checked using f.ex. Vite was not "recommended" as being an inferior option to Next for React usage)
- A very popular option for CSS-in-JS (styled) becomes deprecated due to React internals changing for Next and requiring significant rework that the original author had no interest in (no really clear successor with support across the board for Next, SPA and React-Native scenarios hadn't appeared last we checked).
Now this is my perception of events and I'm pretty sure that I'm not alone in this, the Next/React authors felt like it was the way forward due previous feedback for those that hurt (site builders) but probably misjudged or didn't appreciate how much React was used in other workloads(apps) that got disturbed while they were improving their thing.
That Vercel has managed to alienate people in other ways like billing (or politics?) certainly doesn't seem to have helped either.
> The React site is updated slightly, Vite and similar are now mentioned but the perception damage is there and hasn't let go (and last I checked using f.ex. Vite was not "recommended" as being an inferior option to Next for React usage)
The React site recommends a full-stack framework for most users getting started, but Next, React Router v7, and (for native apps) Expo are all highlighted options, and two other additional frameworks are also described as up-and-coming options.
The site also describes a from-scratch options for “if your app has constraints not well-served by existing frameworks, you prefer to build your own framework, or you just want to learn the basics of a React app”, with specific instructions for Vite, Parcel, and RsBuild.
There's a legitimate debate to be had, I guess, about the whether the getting started should be optimized toward the lowest-distraction approach to learning basic React or toward what is expected to be the most common production use case, but they seem currently to have decent coverage, concerns about order of presentation aside, of a range of options.
> The site also describes a from-scratch options for “if your app has constraints not well-served by existing frameworks, you prefer to build your own framework, or you just want to learn the basics of a React app”, with specific instructions for Vite, Parcel, and RsBuild.
Just that before those specific instructions is again a big "deep dive" box that recommends "consider using a framework".
And yes, I can get the arguments about a easy to get started focus but React is also a more foundational library that has many uses outside of frameworks. Should cppreference.com recommend using QT or MDN and Node.js homepages recommend using Next because "it's easier to get started" ? sure, a tad hyperbolic examples but on the same par.
My experience is that a lot of people on this forum are afraid to voice negative opinions on tools they use at work.
Seen a lot of people in my professional circles shit on Next/Vercel over beers, but then go to work every day and bang out Next because it's what their manager chose 5 years ago.
Vercel can only ride that wave until the people who hate their product are the decision makers.
