- cross-posted to:
- programmer_humor@programming.dev
- cross-posted to:
- programmer_humor@programming.dev
You must log in or register to comment.
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 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.
ads, tracking, and the use of shitty bloated frameworks (like electron) so the tech bro owners can save time and money.
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.
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.
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.
Fuck Teams, all my homies hate Teams
npmElectron is the devils own pile of shit
Cause they work better. Brand new ads, awesome new subscriptions. Flashy new AI features that definitely work super well and are definitely useful.
/s
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.
Yes, and now you can’t test your application before shipping it because who knows what browser engine will actually run it.
You could develop it on Windows and have it completely break for every single Mac user when it executes in Safari and have literally no way of knowing or testing that ahead of time.
I mean you would just test on each platform, which you should be doing regarding of what you’re developing with. Also worth noting that web standards are a thing, and vast majority of apps aren’t so complex that they would run into edge cases between browser engine implementations.
However, this isn’t an inherent problem since you could build something like Tauri and package its own lean rendering engine with it. Sciter-js is an example of this approach. Other examples can be seen with React Native and Proton. The main point here is that the bloat the Electron brings to the table is wholly unjustified, and far more efficient approaches are possible.
I mean you would just test on each platform, which you should be doing regarding of what you’re developing with.
Yes, except the platform your developing for with Electron is the browser engine you ship alongside it, so you are constantly testing it and it will always work.
With Tauri the platform your developing for is now whatever the underlying OS chooses to use to render it’s WebView. It is flat out impossible to test for every os and WebView so you have no guarantee that your application will even render once it’s installed.
And again, if you develop on a Windows or Linux machine, there is flat out no way to test on Safari without buying a Mac, but you can reliably expect your Electron app to just work.
Also worth noting that web standards are a thing, and vast majority of apps aren’t so complex that they would run into edge cases between browser engine implementations.
Lmao. Bruh, I’d like to introduce you to this little known WebView called Safari.
The vast majority of web apps will run into compatibility issues between safari, Firefox, and chrome. There is nowhere close to enough standardization for that.
However, this isn’t an inherent problem since you could build something like Tauri and package its own lean rendering engine with it. Sciter-js is an example of this approach. Other examples can be seen with React Native and Proton. The main point here is that the bloat the Electron brings to the table is wholly unjustified, and far more efficient approaches are possible.
Lol, you’ve clearly never installed a React Native app if you think there’s no bloat.
No, the point is that you want it to be unjustified but it’s not. Electron works great, is incredibly easy to setup and ship with extremely little overhead beyond storage. The opportunity cost of solutions that don’t bundle dependencies are almost never worth it.
There’s a reason the most popular IDE used by virtually every software developer these days is built using Electron.
Lmao. Bruh, I’d like to introduce you to this little known WebView called Safari.
Bruh, I’ve been developing web apps for over a decade now. You don’t have to introduce me to anything. The reality is that most apps aren’t that complex and if you’re using something like React, a lot of the details are already handled for you.
The vast majority of web apps will run into compatibility issues between safari, Firefox, and chrome. There is nowhere close to enough standardization for that.
Sounds like skills issue there bud.
Lol, you’ve clearly never installed a React Native app if you think there’s no bloat.
We’re comparing with Electron here lmfao.
No, the point is that you want it to be unjustified but it’s not. Electron works great, is incredibly easy to setup and ship with extremely little overhead beyond storage. The opportunity cost of solutions that don’t bundle dependencies are almost never worth it.
If by works great you mean hogs resources like no tomorrow and is able to bring modern hardware to its knees to render a simple crud app, then sure.
There’s a reason the most popular IDE used by virtually every software developer these days is built using Electron.
Vast majority of apps people make aren’t nearly as complex as an IDE.
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.
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.
A good package manager like those commonly used on Linux solves this problem
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.
I meant render in a sense of displaying the encoded data as pixels on the screen. I understand how different kinds of rendering work. My point is that reading and displaying image data isn’t free. It can be cheaper than drawing vectors, but there is still a cost and it grows with the size of the image. Images also end up eating up more memory as a rule.
Bigger monitors, smaller phones, higher color depth, lower latencies, customizable window decorations, chronal themes, AI, blockchain, more devices, trackers, architectures, platforms, malwares, internet protocols, programming languages, human languages, ads, ads, ads, ads, doom, power saving, content, content moderation and I’m sure there’s plenty more reasons that might contribute to the growth.
Not saying I like or want all those things, simply that they might be contributing to size increases. Part of me wishes we could go back, then i fire up windows xp pro sp3 on an eee pc netbook i have that miraculously still works and i remember why i prefer to stay in the present, at least until AI kills us all.
Not IT though, I’m just a guy.
You can thank the hackers for bloating our stuff with security patches (among others)!
And by that you mean spyware, trackers, and ad platforms baked into the apps?
Nah its mostly nuget packages. And everything has more dependencies now, including all the dependencies 😅
nuget packages? is that what we can node_modules these days?
Nuget is dotnet’s package manager
Lmao, I guess I wasn’t too far off.
C# is usually used server-side. How would nuget bloat affect client-side applications that users use?
I meant node packages 😅. C# can be used in front end too though, but probably quite rarely used 😅
