161–170 of 359 posts
>For context, I consider 1 MB of Javascript to be on the heavy side for a web page/app. I feel like > 2kb of Javascript is heavy. Literally not needed.
Earlier quoted context omitted.
Why should Germany be wasting public money on a private company who keeps shoveling more and more restrictions on their open-source-washed "community" offering, and whose "enterprise" pricing comes in at twice* the price MS365 does for fewer features, worse integration, and with added costs for hosting, storage, and maintenance? * or same, if excluding nextcloud talk, but then missing a chat feature
Could you expand on what restrictions they have placed on the community version?
IIRC they also display a banner on the login screen to all users advertising the enterprise license, and start emailing enterprise ads to all admin users.
Their "fair use policy"[1] also includes some "and more" wording.
I'm curious how much Javascript eg gmail and google docs/drive give you, in comparison.
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…
> 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.
Earlier quoted context omitted.
Look into syncthing for a dropbox replacement, have been using it for years, very satisfied.
Syncthing is under my "want to like" list but I gave up on it. I'm a one person show who just wants to sync a few dozen markdown files across a few laptops and a phone. Every time I'd run it I'd invariably end up with conflict files. It got to the point where I was spending more time merging diffs than writing. How it could do that with just one person running it I have no idea.
For reference, 20 MB is three hundred and thirteen Commodores.
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.
All said... I actually like TypeScript and React fine for teams of developers... I think NextCloud likely has coordination issues that go beyond the language or even libraries used.
Earlier quoted context omitted.
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.
Windows 2000 was quite snappy on my Pentium 150, and pretty rock solid. It was when I stopped being good at fixing computers because it just worked, so I didn't get much practice.
Currently using Pop + Cosmic.
Earlier quoted context omitted.
I'd say Ente-photo is at least as good if not better than Immich. https://github.com/ente-io/ente
I would say the opposite. Ente has one huge advantage and that it is e2ee so it's a must if you are hosting someone else photos. But if you are planning to run something on your server/NAS for yourself then Immich has many advantages (that often relate to the e2ee). For example... your files are still files on the disk so less worry about something unrecoverably breaking. And you can add external locations. With Ente…
It makes a little more sense when you’re using their cloud version, because otherwise you’re storing the data twice.
Earlier quoted context omitted.
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.
The html object tag can just show a pdf file by default. Just fetch it and pass the source there. What is the problem with that exactly in your case?
Earlier quoted context omitted.
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 a general file sharing / storage solution there is also OpenCloud: https://opencloud.eu/de It's what I want to try next. Written in go, it looks promising.