91–100 of 140 posts
Earlier quoted context omitted.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
> What´s the problem with this? It's 120 MB for literally a fucking color picker.
Earlier quoted context omitted.
Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers. For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility wou…
I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware. Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for…
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
Earlier quoted context omitted.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
> What´s the problem with this? The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
Earlier quoted context omitted.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
There is no problem. It is just like flying with a helicopter to the supermarket. You just need a supermarket with a large enough parking lot.
In total, the app is 122 MiB large. Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker. The actual app itself is in the resources directory which is 1.8 MiB large. This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (…
Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed.
As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673
However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
Doesn't seem to fucking work. On Linux it seems confused with a muti-monitor setup, the orbit button does nothing. On Windows, in a VM, the orbit button opens a web browser to https://www.tonymccoy.me/orbit/#ffffff and gets a 404 Not Found
https://doc.qt.io/qt-5/qcolordialog.html
KDE's KColorChooser is simply a wrapper around this and is less than 100 lines of code, mostly setting up the about box.
https://kde.org/applications/graphics/kcolorchooser/
This could have trivially been made into a cross-platform color chooser that uses significantly less resources.
On my Linux box Fucking Color Chooser spawns 4 fucking processes uses 128 MB of RAM and 4% CPU.
KColorChooser uses 15 MB in one process and near zero CPU.
Please stop making everything a web application.
Earlier quoted context omitted.
Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves. I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones." Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could…
Hehe, kinda funny when an application comes with more security vulnerabilities than it has lines of code for its own logic ;-) EDIT: edited to make it less ambiguous
Earlier quoted context omitted.
Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers. For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility wou…
I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware. Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for…
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
If you wonder about linux: gcolor2 ( http://gcolor2.sourceforge.net/ ) does the job. And for size fetishists: it weights 42KB.
One good option for Windows is COPI, 88 KB .exe: https://www.heise.de/download/product/copi-colorpicker-65782
And the EXE is only 32 KB when UPX is applied on it. And uses only 1 MB of RAM when running.
In total, the app is 122 MiB large. Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker. The actual app itself is in the resources directory which is 1.8 MiB large. This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (…
Nice breakdown of wasted resources.. It's frustrated me for a long time how people are carelessly bundling unused code, which is unfortunately common in JavaScript-land. Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed. As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime -…
Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious.
I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.