>So I'd rather thanks all developers involved in nextcloud than whine about bloated js.

Good news! You can do both.

That's not quite right. There are features that are only available to enterprise customers, or require proprietary plug-ins like Sendent.

Do I need them for my home server? No. Do I need them for my company? Yes, but costs compared to MS 365 are negligible.

Nextcloud, and before it Owncloud, have been "in production" in my household for nearly a decade at this point. There have been some botched updates and sync problems over the years, but it's been by far the most reliable app I've hosted.

In terms of privacy & security, like everything it comes down to risk model and the trade-offs you make to exist in the modern world. Nextcloud is for sharing files, if nothing short of perfect E2EE is tolerable it's probably not the solution for you, not to mention the other 99.999% of services out there.

I think most of the problems people report come down to really bad defaults that let it run like shit on very low-spec boxes that shouldn't be supported (ie raspi gen 1/2 back in the day). Installing redis and configuring php-fpm correctly fixes like 90% of the problems, other than the bloated Javascript as mentioned in the op.

End of the day, it's fine. Not perfect, not ideal, but fine.

the question is, what's your use case?

for me it's a family photo backup with calendars (private and shared ones) running in a VM on the net.

its webui is rarely used by anyone (except me), everyone is using their phones (calendars, files).

does it work? yes. does anyone other than me care about the bugs? no. but noone really _uses_ it as if it was deployed for a small office of 10-20-30 people. on the other hand, there are companies paying for it.

for this,

Kinda. In the long run you will definitely stumble upon a ton of bugs, but they mostly have some workarounds. Mostly.

While I tend to agree... I've been on enough relatively modern web apps that can hit 8mb pretty easily, usually because bundling and tree shaking are broken. You can save a lot by being judicious.

IMO, the worst offenders are when you bring in charting/graphing libraries into things when either you don't really need them, or otherwise not lazy loading where/when needed. If you're using something like React, then a little reading on SVG can do wonders without bloating an application. I've ripped multi-mb graphing libraries out to replace them with a couple components dynamically generating SVG for simple charting or overlays.

Preact have been fairly faithful to being <10k (compressed)! (even though they haven't updated the original <3k claim since forever)