It kills me when I download a simple app to my phone that's 60 mb. When I was a child we built the world off 1.44 mb floppies. How did we stray so far from God's light?
Even 10years ago, I considered having an app over around 40mb to be huge, but now 60mb is kind of the norm
Isn't it about a web engine being roughly 60MB? 😕
Do you mean by that that many apps are just website wrappers? Or did I get it wrong?
Indeed many apps tend to be that, at least many of my apps are open source at least and they tend not to have trackers and other bloat😅
I think I was thinking about desktop apps when I answered, but I feel out of context now 😬
Ohhh, I was talking about android apps😆
Hmm, I havent checked much how big computer applications are on average
The Uber App on my phone is 1 GB!
The fuck? (Edit: Although, does it have a map?)
Hmm...
AliExpress has no right to be that large, neither Opera. No reason to store that much cache. (Edit: cache and cookies are only around 500MB total. Hmmm...) Also, I set F-Droid to keep cached apps for 1 hour, what the hell is this?
I kind of forgot to manage my storage, as I usually do until I have like 5GB left...
Data will always adapt to storage size.
Amen, we didn't have fancy "game engines" or "media assets" and we liked it.
Why is it in the 2000's it took 30-60 seconds to open, Word, Photoshop, Gimp or some other program. With today's computing power it still takes 30-60 seconds to open same said programs.... Also fuck MS Teams.
Fuck Teams, all my homies hate Teams
Gimp opens on linux pretty much in an instance though
Maybe I should give it another shot then, it's been a few years. But last time I used it as default to open pictures on my set up it would pop up with its image and take at least 10 seconds to load the image. I got to annoyed with it I change it to just open in my browser.
Cause they work better. Brand new ads, awesome new subscriptions. Flashy new AI features that definitely work super well and are definitely useful.
/s
ads, tracking, and the use of shitty bloated frameworks (like electron) so the tech bro owners can save time and money at the expense of ours.
There's sort of an unholy synergy between hardware companies wanting to sell more hardware and software shops wanting to cut development costs. The selection pressures are to build bloated software that needs fast hardware to run.
Because storage is cheap, so it's not worth optimizing that heavily for, because the optimization creates a huge amount of headaches.
There's a reason that today you can just download an app, and it just installs, runs, and uninstalls itself cleanly.
There's no fighting with dependencies, or installing versions of libraries or frameworks before you can install an app, or having apps conflict with other apps, or having bits of app installations lying around conflicting with things.
That's because we used to spend a lot of time and effort making sure that only a single copy of each dependency was installed on a system. If two apps both relied on the same library, one would install it, and the other would then be dependent on it as well and not install its own copy. If the original is removed you have a problem. If it thinks something else is dependent on its asset still and doesn't remove it when it should you've got a problem. If they were both dependent on different major versions of a library, you could run into conflicts and compatibility issues (hello dll hell). Either the apps would have to manage all that, or the OS would, or eventually the user often would.
Now every app just bundles all its dependencies with it. It means the app comes as a clean bundle, there's no conflicts, it can install cleanly, and there's so much less time spend on packaging apps and debugging various system configurations.
Quite frankly this makes way more sense as a model for distributing anything. Yes it costs more in storage, but it pays off massively in resiliency and time savings for everyone.
Also, unless everything is done with vectors, high def image / video assets are not small and can very quickly add up.
Except that it's not just storage, but also increased memory footprint and CPU usage in a lot of cases. Take something like Slack which is a huge resource hog.
Electron. Many apps nowadays are just headless browsers and browsers are huge and complex. It's nice from a development perspective, because you can (re)use web tools for desktop apps but it's very resource hungry.
It's worth noting that it doesn't have to be that way. Take Tauri as an example of leveraging the benefits of web stack development, and having an efficient runtime under the hood.
It's also because we started doing shit like using JS in places it really shouldn't belong. Half the programs on my PC are just webapps running in a sandbox environment, instead of using systems languages like C/C++ directly like was the case 15-20 years ago. Abstractions on top of abstractions on top of abstractions. JS was fine for embellishing elements of a web site and facilitating AJAX, it should have never been turned into an app language.
That'd be like if interpreted BASIC was taken seriously in the 80s as more than just a toy and the majority of popular software was written in it. We'd rightfully question WTF society was thinking.
Bingo!
No we wouldn't, and this is a crazy take when like half of Linux runs on interpreted python.
You're min/maxing for things that don't matter. You know what does matter? User facing features. You know what language in unquestionably the fastest to produce user facing features in? JavaScript/HTML/CSS.
If you want to optimize for performance you can do so after by moving things server side, writing them in web assembly, or offloading them onto other threads.
There's also massive opportunity cost in a) programming in low level languages, and b) having every developer have to learn a low level language. There's a reason that we don't all code in assembly any more.
It's also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.
For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn't even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.
All this (packaging dependencies, plus assets/asset handling) to say it isn't always malware, ads, electron, etc. Sometimes it's just trying to make something that looks nice and runs well (enough) on any machine.
I have bypassed this issue by exclusively using open-source terminal software. If my softwares aren't launching in 2-3 seconds, i usually try to find alternatives.
it gets hard to do this when my bank or other assorted corporation forces me to use their shitty shit.
npm
Electron is the devils own pile of shit
And then you have Arch Linux. [insert chef's kiss]
i hate that most of the modern desktop apps run a freaking separate chromium instance
Curious if this is so broadly true without bundled resources; obviously screens are higher DPI, so even buttons are now designed for at least 8K resolutions, even if most consumers are still on 1080p.
Orders of magnitude beyond 640x480 or pre Windows 3.1 resolutions.
A lot of that done using vector graphics though.
Many apps ship both vectors and raster images. It is worth nothing that vectors save space, but increase compute (the image now has to be rendered at runtime), contributing to slower startup times.
In practice, that cost of rendering the vectors vs images is negligible because rendering a raster image isn't free either. Especially, if you're going to package large images in your app.
Raster images do not need to be rendered - see Rendering:
Rendering is the process of generating a photorealistic or non-photorealistic image from input data such as 3D models...Today, to "render" commonly means to generate an image or video from a precise description (often created by an artist) using a computer program.
Note that "render" is a fairly generic term, and it is sometimes used like "render to the screen," to just mean to display something. Rasterisation may be a better term to use here, since it only applies to vector graphics, and is the part of the process I am referring to.
In any case, except for possibly reading fewer bytes from disk, the vector case includes all the same compute and memory cost as the raster image - it just has added overhead to compute the bitmap. On modern hardware, this doesn't take terribly long, but it does mean we're using more compute just to launch/load things.
Post funny things about programming here! (Or just rant about your favourite programming language.)
