Yes, but this is my point.

https://github.com/tauri-apps/tauri/discussions/3162

> FabianLars, 3 hours ago, Collaborator

> ...for example my somewhat simple app uses ~120MB

> But only ~5MB is the actual tauri/rust process, the rest is WebView2.

So, if 60MB is a large download, surely a simple app using 120MB of ram is pretty outrageous too?

> There is no reason why hello world UI should be 60MB.

Absolutely, but you can't have everything. Fast. Small. Doesn't use any memory. Easy to develop for. Free. Consistent cross platform behaviour.

You can't have them all.

So... the question isn't "is 60MB ok?"

The question is: What do you care about the most? Is it really the download size?

It's not the download size for me.

I’d encourage you to rethink whether the “all” you describe is desirable. I couldn’t care less whether an app is consistent across platforms - in fact I consider that a strict negative since apps should be consistent with the platform on which they are running not with themselves on other platforms.

I don't think that "consistent" always necessarily refers to pixel-perfect equality. When using this term in web dev, most would refer to browser standards as in spacing, layout, JS apis, availability of native elements etc. In this context, consistency is rather the opposite of negative. I don't think anyone really cares about how date picker looks on Firefox vs. on Chrome.

Maybe you are referring to Gtk/Qt vs. win32 etc. with their integrations in the operating system. I agree that they look and feel the best for their respective OS, but eventually require you maintain multiple unrelated codebases. It is understandable and necessary for this approach to die. A middle ground would be best, say, Qt support on all existing platforms. Or more likely, prettier browser defaults for standard elements like lists and tables, with browsers themselves respecting the underlying OS theme. Probably never gonna happen...

I'm not that interested in using lower common denominator software on any platform - for my purposes I am only interested (and willing to pay for) software written to integrate with macOS in a first party manner. That means I want all of the accessibility controls to work, all of the system integration to work and so forth. I'd expect anyone serious about software to want the same on whatever platform they use. Lowest common denominator crap is the thing that needs to die.

I can remember using 56k dialup and downloading ISOs around 650MB.

A 60MB download would have been fine.

Indeed, with the annoying habit of proprietary software to install "Download managers" that download the actual software, I would be happy for just a 60MB runtime for the actual program itself.

I'm not sure you really remember. With 56k dialup, downloading 650MB could easily take days. Downloading 1MB could have taken 3 to 4 minutes.

60MB, even today, is really big when you have to download it while boarding a train or with poor connectivity (even in rich countries, just being in a metallic building is enough for 60MB to be painful to download.

I remember leaving the computer on to download 650MB overnight, which used to be an ISO for an operating system. It was usually finished sometime the next day.

And 60MB would have been a couple of hours, not bad to wait for some software.

It wasn't prohibitive to do this.

Indeed, I seem to be back at square one, as downloading a AAA game for me once again takes about a day.

Add a little line noise for the average 30-70y/o house wiring and you get 43 hours for 33.6 or 50 hours for 28.8. It took running a brand new line in order for me to get 56k. So, the parent comment is accurate.

It was absolutely prohibitive for the average person with a shared line, and the direct comparison to shared line today is a metered connection. Even in the US it can be as much as $30 per gigabyte which would make that 60MB download cost $1.80.

650,000 kb / 5 kb/s = 36 hours

You download desktop apps while boarding a train?

I also remember using 56k dialup, and we paid per minute. A 60 Mb download would take several hours.

Arguably both Slack and Spotify (and Visual Studio?) have reached significant scale with Electron apps - so at the end of the day it seems to be less of an issue for end consumers.

Spotify is built on Chromium Embedded Framework, not Electron. Common misunderstanding.

Lots of things are popular, but that doesn't imply quality. McDonald's does not make the best hamburger in the world.

VSCode is Electron, not VS.

I would add Discord to that list.

While true, you pay the price to download a program once, but the price to run the program, every day.

But you don’t pay RAM usage fees.

You would be surprised but that is exactly what you do when you access VMs on clouds.

To be short: if you can make your app less greedy - do it.

In some cultures we have a concept of "engineering conscience" (ru: "инженерная совесть"). Are we loosing all that?

Oh sure, not just VM, but in all rented server instances. But we’re talking about home machines here.

Don't give them any ideas.