alt Hacker NewsI 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.
OP really focused on payload size, is why I was curious.
> On a clean page load [of nextcloud], you will be downloading about 15-20 MB of Javascript, which does compress down to about 4-5 MB in transit, but that is still a huge amount of Javascript. For context, I consider 1 MB of Javascript to be on the heavy side for a web page/app.
> …Yes, that Javascript will be cached in the browser for a while, but you will still be executing all of that on each visit to your Nextcloud instance, and that will take a long time due to the sheer amount of code your browser now has to execute on the page.
While Nextcloud may have a ~60% bigger JS payload, sounds like perhaps that could have been a bit of a misdirection/misdiagnosis, and it's really about performance characteristics of the JS rather than strictly payload size or number of lines of code executed.
On a Google Doc load chosen by whatever my browser location bar autocompleted, I get around twenty JS files, the two biggest are 1MB and 2MB compressed.