I stopped using Nextcloud when the iOS app lost data.

For some reason the app disconnected from my account in the background from time to time (annoying but didn't think it was critical). Once I pasted data on Nextcloud through the Files app integration, it didn't sync because it was disconnected and didn't say anything, and it lost the data.

Recently people built a super-lightweigt alternative, named copyparty[0]. To me that looks like it does everything people tend to need without all the bloat.

[0]: https://github.com/9001/copyparty

For your specific use case of photos, Immich is the front runner and a much better experience. Sadly for the general Dropbox replacement I haven't found anything either.

For photos, you can't beat Immich.

I’ve tried every scheme under the sun and Immich is the only thing I’ve ever seen that actually works for this use case

I switch to FolderSync for the upload from mobile. Works like a charm!

I know, it sucks that the official apps are buggy as hell, but the server side is real solid

This also happened to me with my nextcloud, thankfully I did not lose any photos. I transitioned to Immich for my photos and have not looked back.

I use syncthing, I've got a folder shared between my phone, laptop and media center, and it just syncs everything easily.

SyncThing

The next cloud android app is particularly bad if you use it to back up your cameras DCIM directory then you delete the photos on your phone. It overwrite the files on Nextcloud as new photos are taken. I get why this happened but it is terrible.

I was going to say... The size of the JS only matters the first time you download it unless there's a lot of tiny files instead of a bundle or two. What the article is complaining about doesn't seem like it's root cause of the slowness.

When it comes to JS optimization in the browser there's usually a few great big smoking guns:

    1. Tons of tiny files: Bundle them! Big bundle > zillions of lazy-loaded files.
    2. Lots of AJAX requests: We have WebSockets for a reason!
    3. Race conditions: Fix your bugs :shrug:
    4. Too many JS-driven animations: Use CSS or JS that just manipulates CSS.

Modern mobile network connections have plenty of bandwidth to deliver great big files/streams but they're still super slow when it comes to round-trip times. Knowing this, it makes perfect sense that Nextcloud would be slow AF on mobile networks because it follows the REST philosophy.

My controversial take: GIVE REST A REST already! WebSockets are vastly superior and they've been around for FIFTEEN YEARS now. Do I understand why they're so much lower latency than REST calls on mobile networks? Not really: In theory, it's still a round-trip but for some reason an open connection can pass data through an order of magnitude (or more) lower latency on something like a 5G connection.

The thing that kills me is that Nextcloud had an _amazing_ calendar a few years ago. It was way better than anything else I have used. (And I tried a lot, even the calendar add-on for Thunderbird. Which may or may not be built in these days, I can't keep track.)

Then at some point the Nextcloud calendar was "redesigned" and now it's completely terrible. Aesthetically, it looks like it was designed for toddlers. Functionally, adding and editing events is flat out painful. Trying to specify a time range for an event is weird and frustrating. It's better than not having a calendar, but only just.

There are plenty of open source calendar _servers_, but no good open source web-based calendars that I have been able to find.

Sync Conf is next week, and this sort of issue is so part of what I hope maybe can just go away. https://syncconf.dev/

Efforts like Electric SQL to have APIs/protocols for bulk fetching all changes (to a "table") is where it's at. https://electric-sql.com/docs/api/http

It's so rare for teams to do data loading well, rarer still we get effective caching, and often a products footing here only degrades with time. The various sync ideas out there offer such an alluring potential, of having a consistent way to get the client the updated live data they need, in a consistent fashion.

Side note, I'm also hoping the js / TC39 source phase imports proposal aka import source can help let large apps like NextCloud defer loading more of it's JS until needed too. But the waterfall you call out here seems like the real bad side (of NextCloud's architecture)! https://github.com/tc39/proposal-source-phase-imports

This is my theory as well. NC has grown gradually in silos almost, every piece of it is some plugin they've imported from contributions at some point.

For example the reason there's no cohesiveness with a common websocket bus for all those ajax calls is because they all started out as a separate plugin.

NC has gone full modularity and lost performance for it. What we need is a more focused and cohesive tool for document sharing.

Honestly I think today with IaC and containers, a better approach for selfhosting is to use many tools connected by SSO instead of one monstrosity. The old Unix philosophy, do one thing but do it well.

Two things:

1. Did you open back port request with these basic patches? If you have orders of magnitude speed improvements it would be aswesome to share!

2. You definitively don't need an entire sysadmin team to run nextcloud, in my work (large organisation) there's three instances running (for different parts/purposes of which only one is run by more than one person, and I run myself both my personal instance and for a nonprofit with ~100 persons, it's really not much work after setup (and other systems are plenty of a lot more complicated systems to set up, trust me)

It downloads a lot of JavaScript, it decompresses a lot of JavaScript, it parses a lot of JavaScript, it runs a lot of JavaScript, it creates a gazillion onFoundMyNavel event callbacks which all run JavaScript, it does all manner of uncontrolled DOM-touching while its millions of script fragments do their thing, it xhr’s in response to xhrs in response to DOM content ready events, it throws and swallows untold exceptions, has several dozen slightly unoptimized (but not too terrible) page traversals, … the list goes on and on. The point is this all adds up, and having 15MB of code gives a LOT of opportunity for all this to happen. I used to work on a large site where we would break out the stopwatch and paring knife if the homepage got to more than 200KB of code, because it meant we were getting sloppy.

Agreed. Plus if it truly downloads all of that every time, something has gone wrong with caching.

Overeager warming/precomputation of resources on page load (rather than on use) can be a culprit as well.

> I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.

With the disclaimer that I've never used Filerun, I think this can be replicated with copyparty by means of the "shares" feature (--shr). That way, you can create a temporary link for other people to upload to, without granting access to browse or download existing files. It works like this: https://a.ocv.me/pub/demo/#gf-bb96d8ba&t=13:44

On the topic of self-hosted file manager apps, I've really liked "filebrowser". Pair it with Syncthing or another sync daemon and you've got a minimal self-hosted Dropbox clone.

* https://github.com/filebrowser/filebrowser

* https://github.com/hurlenko/filebrowser-docker

Copyparty can't (and doesn't want to) replace Nextcloud for many use cases because it supports one-way sync only. The readme is pretty clear about that. I'm toying with the idea of combining it with Syncthing (for all those devices where I don't want to do a full sync), does anybody have experience with that? I've seen some posts that it can lead to extreme CPU usage when combined with other tools that read/write/index the same folders, but nothing specifically about Syncthing.

rewriting in a lower-level language won't do too much for NC, because it's mostly slow due to inefficient IO organization - things like mountains of XHRs, inefficient fetching, db querying etc. - None of that will be implicitly fixed by a rewrite in any language and can be fixed in the PHP stack as well. I think one of the reasons that helped OC/NC get off the ground was precisely that the sysadmins running it can often do a little PHP, which is just enough to get it customized for the client. Raising the bar for contribution by using lower level languages might not be a desirable change of direction in that case.

The thing I don't get is that based on the article the front-end is as bloated as the back-end.

That said there's an Owncloud version called Infinite Scale which is written in Go.[1] Honestly I tried to go that route but it's requirements are pretty opinionated (Ubuntu LTS 22.04 or 24.04 and lots of docker containers littering your system) but it looks like it's getting a lot of development.

[1] https://doc.owncloud.com/

I recently needed to show a pdf file inside a div in my app. All i wanted was to show it and make it scrollable. The file comes from a fetch() with authorzation headers.

I could not find a way to do this without pdf.js.

> Nobody likes the web apps because they're slow.

Web apps don't have to be slow. I prefer web apps over system apps, as I don't have to install extra programs into my system and I have more control over those apps:

- a service decides it's a good idea to load some tracking stuff from 3rd-party? I just uMatrix block it;

- a page has an unwanted element? I just uBlock block it;

- a page could have a better look? I just userstyle style it;

- a page is missing something that could be added on client side? I just userscript script it

My NextCloud server completely borked itself with an automatic update sometime in the last ~10 months. It's completely unresponsive.

I haven't bothered to fix it.

I gave up updating Nextcloud. It works for what I use it for and I don't feel like I'm missing anything. I'd rather not spend 4+ hours updating and fixing confusing issues without any tangible benefit.

> Even low-band 5G gives you 30–250 Mbps down.

On paper. In practice, it can be worse than that.

I've spent the past year using a network called O2 here in the UK. Their 5G SA coverage depends a lot on low band (n28/700MHz) and had issues in places where you'd expect it to work well (London, for example). I've experienced sub 1Mbps speeds and even data failing outdoors more than once. I have a good phone, I'm in a city, and using what until a recent merger was the largest network in the country.

I know it's not like this everywhere or all the time, but for those working on sites, apps, etc, please don't assume good speeds are available.

Such underrated comment. You can really have 500MB of dependencies for your app because you're on MacOS and it's still gonna be fast because memory use have nothing to do with performance.

Pretty much the same with JavaScript - modern engines are amazingly fast or at least they really not depend on amount of raw javascript feed to them.

> low-band 5G gives you 30–250

First and foremost, I agree with the meat of your comment.

But I wanted to point about your comment, that it DOES very much matter that apps meant to be transmitted over a remote connection are, indeed, as slim as possible.

You must be thinking about 5G on a city with good infrastructure, right?

I'm right now having a coffee on a road trip, with a 4G connection, and just loading this HN page took like 8~10 seconds. Imagine a bulky and bloated web app if I needed to quickly check a copy of my ID stored in NextCloud.

It's time we normalize testing network-bounded apps through low-bandwidth, high-latency network simulators.

> You really consider 1 MB of JS too heavy for an application with hundreds of features? How exactly are developers supposed to fit an entire web app into that? Why does this minimalism suddenly apply only to JavaScript? Should every desktop app be under 1 MB too? Is Windows Calculator 30 MB binary also an offense to your principles?

Yes, I don't know, because it runs in the browser, yes, yes.

Immich is a night and day improvement for photos vs nextcloud. You could roll it in addition if you wanted to try.

Fantastic recommendation, it's like exactly what the doctor ordered given the premise of this thread. Does Bewcloud play nice with DAV or other open protocols or (dare I hope) nextcloud apps? I wouldn't mind using nextcloud apps paired with a better web front end.

> I use PhoneTrack on road trips a lot

If every aspect of Nextcloud was as clean, quick and light-weight as PhoneTrack this world would be a different place. The interface is a little confusing but once I got the hang of it it's been awesome and there's just nothing like it. I use an old phone in my murse with PhoneTrack on it and that way if I leave it on the bus (again) I actually have a chance of finding it.

No $35/month subscription, and I'm not sharing my location data with some data aggregator (aside from Android of course).

Take a look at OpenCloud. It's a Go-based rewrite of the former OwnCloud team.

It works very well, has polished UI and uses very little resources. It also does a lot less than Nextcloud.

https://github.com/opencloud-eu

I made one such lightweight alternative frontend: https://github.com/mickael-kerjean/filestash

Just compare comparable products.

Nextcloud is an old product that inherit from Owncloud developed in php since 2010. It has extensibility at its core through the thousands of extensions available.

So yaaay compare it with source hut ...

I know this post is more about nextcloud...but can i just say this one feature from Vikunja "...export task summaries and comments..." sounds great!!! One of the features i seek out when i look for a task, project management software is the ability to easily and comprehensivelt provide for nice exports, and that said exports *include comments*!!

Either apps lack such an export, or its very minimal, or it includes lots of things, except comments...Sometimes an app might have a REST api, and I'd need to build something non-trivial to start pulling out the comments, etc. I feel like its silly in this day and age.

My desire for comments to be included in exports is for local search...but also because i use comments for sort of thinking aloud, sort of like an inline task journaling...and when comments are lacking, it sucks!

In fact, when i hear folks suggest to simply stop using such apps and merely embrace the text file todo approach, they cite their having full access to comments as a feature...and, i can't dispute their claim! But barely any non-text-based apps highlight the inclusion of comments. So, i have to ask: is it just me (who doesn't use a text-based todo workflow), and then all other folks who *do use* a text-based tdo flow, who actually care about access to comments!?!

<rant over>

I'm not sure why you feel like it is abandoned. There is a steady release cadence and the changelog[0] clearly shows that much is being worked on.

[0]: https://nextcloud.com/changelog/#latest32

Wow, that's a lot. Our local installation zero cache request (to not suffer their slooooow cloud):

82 / 86 requests 1,694 kB / 1,754 kB transferred 6,220 kB / 6,281 kB resources Finish: 11.73 s DOMContentLoaded: 1.07 s Load: 1.26 s

I just checked google calendar it's under 3mb download for js (around 8mb uncompressed).. it's also a lot more responsive than nextcloud web. Even then, it's not necessarily the size, I think that's mostly a symptom of the larger issues likely at play.

There are a lot of requests made in general, these can be good, bad or indifferent depending on the actual connection channels and configuration with the server itself. The pieces are too disconnected from each other... the NextCloud org has 350 repositories on Github. I'm frankly surprised it's more than 30 or so... it's literally 10x what would be a larger expectation... I'd rather deal with a crazy mono-repo at that point.

gmail should be server sided, with as much JS as you want to use. Unless they moved away from the philosophy they started with GWT (Google Web Toolkit) for Gmail, and perhaps even Inbox (RIP)

Been running NC on my home server and basically maybe update it once a year or so? Even less probably, so definitely not a must to update every time. Plus via snap it's pretty simple.

The linuxserver.io image for Nextcloud requires considerably less babysitting for upgrades: https://docs.linuxserver.io/images/docker-nextcloud

As long as you only upgrade one major version at a time, it doesn't require putting the server in maintenance mode or using the occ cli.

Might also consider Vaultwarden/Bitwarden as a self-host alternative. Yeah it's client-server... that said, been pretty happy as a user.

Check if your router has an option to add custom DNS entries. If you're using OpenWRT, for example, it's already running dnsmasq, which can do split DNS relatively easily: https://blog.entek.org.uk/notes/2021/01/05/split-dns-with-dn...

If not, and you don't want to set up dnsmasq just for Nextcloud over LAN, then DNS-based adblock software like AdGuard Home would be a good option (as in, it would give you more benefit for the amount of time/effort required). With AdGuard, you just add a line under Filters -> DNS rewrites. PiHole can do this as well (it's been awhile since I've used it, but I believe there's a Local DNS settings page).

Otherwise, if you only have a small handful of devices, you could add an entry to /etc/hosts (or equivalent) on each device. Not pretty, but it works.

> The major shortcoming of NextCloud, in my opinion, is that that it's not able to do sync over LAN.

That’s an interesting way to describe a lack of configuration on your part.

Imagine me saying: "The major shortcoming of Google drive, in my opinion, is that that it's not able to sync files from my phone. There is some workaround involving an app called 'Google drive' that I have to install on my phone, but I haven't gotten around to it. Other than that, Google drive is absolutely fantastic.

Or just use ipv6!

You could also upload directly to the filesystem and then run occ files:scan, or if the storage is mounted as external it just works.

Another method is to set your machines /etc/hosts (or equivalent) to the local IP of the instance (if the device is only on lan you can keep it, otherwise remove it after the large transfer).

Now your rounter should not send traffic to itself away, just loop it internally so it never has to go over your isps connection - so running over lan only helps if your switch is faster than your router..

I had a similar issue with a public game server that required connecting through the WAN even if clients were local on the LAN. I considered split DNS (resolving the name differently depending on the source) but it was complicated for my setup. Instead I found a one-line solution on my OpenBSD router:

    pass in on $lan_if inet proto tcp to (egress) port 12345 rdr-to 192.168.1.10

I use it on LAN without a problem (using mDNS). Sure it runs with self signed certificates, but that’s ok with me.

The complete Doom 2, including all graphics, maps, music and sound effects, shipped on 4 floppies, totalling 5.76MB.

The article suggests that it takes 14MB of Javascript to do just the calendar. I doubt that all of my calendar events for 2025 is 14MB.

Or the same number of 64k intros[1][2][3]...

[1]: https://www.youtube.com/watch?v=iXgseVYvhek

[2]: https://www.youtube.com/watch?v=ZWCQfg2IuUE

[3]: https://www.youtube.com/watch?v=4lWbKcPEy_w

Sure, but what people leave out is that it’s mostly C and assembly. That just isn’t realistic anymore if you want a better developer experience that leads to faster feature rollout, better security, and better stabilty.

This is like when people reminisce about the performance of windows 95 and its apps while forgetting about getting a blue screen of death every other hour.

Not paying attention.

1. Indiscriminate use of packages when a few lines of code would do.

2. Loading everything on every page.

3. Poor bundling strategy, if any.

4. No minification step.

5. Polyfilling for long dead, obsolete browsers

6. Having multiple libraries that accomplish the same thing

7. Using tools and then not doing any optimization at all (like using React and not enabling React Runtime)

Arguably things like an email client and file storage are apps and not pages so a SPA isn't unreasonable. The thing is, you don't end up with this much code by being diligent and following best practices. You get here by being lazy or uninformed.

I think, some of the issues here is that first nextcloud tries to be compatible with any managed / mutualized hosting.

They also treat every "module"/"apps" whatever you call it, as completely distinct spa without proving much of a sdk/framework. Which mean each app, add is own deps, manage is own build, etc...

Also don't forget that app can even be a part of a screen not the whole thing

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)

PHP is super-fast today. I've built 2 customer facing web products with PHP which made each a million dollar business. And they were very fast!

https://dev.to/dehemi_fabio/why-php-is-still-worth-learning-...

If dav works best for you, you're using it right.

I would assume that the people for whom a slow web based calendar is a problem (among other slow things on the web interface) are people who want to be using it if it performed well.

They wouldn't just make a bad slow web interface on purpose to enlighten people as to how bad web interfaces are, as a complicated way of pushing them toward integrated apps.

Their calendar plugin provides CalDAV, so you could just use your local calendar app that syncs with the server over that protocol.

Any good file syncing/drive replacements? My Synology exists pretty much because Synology Drives works so well syncing Mac and iOS.

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.

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

Nope. Php is sufficiently fast.

It felt unnecessarily complex for such a simple task as file synchronization. I prefer unison. Unfortunately, it is a blast from the past written in ocaml and there is no Android app :-(

Syncthing has been very "set it and forget it" for me. It updates itself occasionally but I haven't had to fix anything yet.

Do you have any tips and tricks to share? I'm running a self-hosted instance on an old desktop PC in my basement for me and a couple family members. Performance is kinda meh, and I don't think it's due to resource constraints on the server itself. This is after following the performance recommendations in the admin console to tweak php.ini settings.

Could more diligence in the codebase solve this?

> Could ignoring the problem solve this ?