Computer users fight 'bloatware' (1998)
cnn.com
cnn.com
We used to get real work done on a 10 MB HDD. We had space for DOS, Windows 3.11, Lotus, and Wordperfect, and there was room left over for Doom. Now computers are many orders of magnitude "faster," yet I find that I'm waiting for things to render on my $4,000 laptop. It's infuriating at times.
But LogiOptionsMgr and LogiOverlay are together using 116 MB of RAM. This is a thing that these two apps could defer to the OS, probably by setting some registry keys, and that would make them obsolete, except for when I need to do some reconfiguration.
Can you do that with the Logitech MX Anywhere S2?
Also, do you know some good trackballs with extra buttons?
So this LogiOptionsMgr.exe is not really needed, but it gets loaded anyway.
I've never used trackballs.
Scrolling is excellent, works on any surface, can be paired to three devices (also via Bluetooth), the battery lasts really long on one charge and it's relatively small.
You'll find uses for the thumb buttons, like CTRL + Shift + T to reopen the last closed tab in the browser.
I would say that issue is not Electron itself. Issue is other GUI frameworks which are so terrible that developers prefer Electron despite its objective issues.
I spent good amount of time learning WinAPI, learning MFC, learning Delphi, learning Swing, learning JavaFX, learning a little bit of WinForms. I wrote few native Android apps and iOS apps. I'm not an expert, but I saw enough APIs.
I'm mostly backend developer. I know JS, but only enough to be able to read the code and do some modifications.
If I would need to write GUI, I'd write it with HTML/CSS/JS any day. It's infinitely easier than whatever native tech there is.
I did not try Flutter or SwiftUI though. Those are most modern frameworks, may be they improved.
Yes, but it's relegated to the UI. Not much different from many products that used Visual Basic GUIs to talk with embedded systems in the 90s through serial ports: VB could not touch the critical code, and if the interface bombed they would just reload it. That didn't make VB good for mission critical software though.
Electron aside, I find the use of touch screens in these applications one of the stupidest choices ever: operating it while the spacecraft is shaking due to an emergency would be problematic, then it would need just a small crack in the touch sensitive layer to render the entire control panel inoperable. Luckily they know that and have the most critical functions replicated to real buttons.
I'd never write desktop UI toolkit code by hand. I tried with Java Swing and it sucked, and the one time I was forced to use Qt Quick via code it was just JSON/JS anyway.
Even in early 90s we had excellent (amazingly excellent +++ compared to web) desktop gui design tools, that were easy drag and drop things..
10 year old me made his first windows executable with a gui and buttons on his windows 95 machine..
So I don't think the struggle against bloatware is hopeless. We have the tools now to create and easily distribute many forms of conventional software without the cosmetic complexity. One morning we could wake to see trendsetters using it and things will change.
Native applications.
That, or an entirely new approach to application platform than the HTML+CSS+JS/wasm abomination that we have today, an api and underlying platform that is actually built for making graphical user interfaces for interactive computer programs, rather than glorified newspaper pages.
I want a platform that allows for the creation of tools that are easy and convenient to use to create nice looking, performant, unbloated UI, tools like the winforms designer or JFormDesigner or qt designer or glade.. What do they have in common ? They produce fairly unbloated code for their target language/platform, are nice and convenient to use and are not able to generate good html/css/js output.
I would really like to read more about this, do you have an links or material where they discuss the use of Electron as part of their tech stack?
The alternative to "everything but the kitchen sink" software is Unix style "do one thing well" focused tools. Which is fine if you are a programmer who knows how to select and string tools together (with a bit of scripting thrown in) to solve a task.
That still is an insufficient apologia for Word, and paints the wrong picture: 95% of the features that everyone uses are the same, but the remaining 5% are different.
Never mind the bloat in the implementation of the 95% and the bad UI of presenting these various features.
I have hopes that structured shell (PowerShell/Nushell) is going to take us in this direction.
Also, with a project like Nushell specifically, it would be very interesting to explore zero-copy piping. Rust's memory model and mutability rules sound very adapted to making such optimizations in a safe way. Some mutating functions may clone the data at some point to mutate it, but for example filtering could be applied by chaining filtering iterators without requiring ownership.
We've come up with clever ways to make it appear simpler, e.g. virtualization. Aha, you've used tools to shrink the whole cluster into a single process! It's a degenerate form of abstraction that yields the illusion of simplicity, while not just not simplifying, but adding considerable complexity itself.
My point is that small software matters, always mattered, and will always matter, just not for the reason you'd expect.
Well said, I would go further and say that smaller, simpler more efficient programs are more efficient, I mean even from a purely energy consumption viewpoint, 1 gigabyte of whatever will always cost more (in money or electricity) than 1 megabyte (even if not 1 thousand times, still a lot of times).
Most of our bloat is due to duplication (literal copy and paste) of UI components and patterns. And also to hasty architectural decisions, especially around error handling.
Other than that, there is a general attitude of removing unpopular features that cause more trouble than they're worth, or at least moving them to totally separate services.
It really doesn't go down well. Most developers love it.
EOL'ing Windows 10 is going to create so much e-waste, because people are so lazy and would just pay for a new computer rather than learn Linux, so, thanks, Microsoft for helping us reach a 1.5 degree world sooner than 2040!
That's not what goes on in the real world though, where not everyone is technically minded. Those people (and there's really a lot of them, way more than there are people who would actually succeed in getting a linux distro installed and running) just want something which powers on and enabes them to browse the web and use office tools. Which theoretically can be done by any OS, but practically: not so much. While it's way better now than e.g. 2 decades ago, the just works factor of linux still isn't on the level of OSX or Windows.
Corparations for some reason seem to rotate computers every three years on a lease. Trashing perfectly good computers.
I have a hard time imagining any consumer care about some EOL date at all. And rightfully so.
I guess/hope there'll be a Windows 11 Light or something like that to keep these old computers going.
There also are alot of antivirus software users could get.
And as scripting languages like Python and JS becomes popular, do we just consider the binary size for bloatware? What about their dependencies?
Even above average workstations still have constraints. Those above average specs will eventually be adopted by the masses and a chat app will only function on a system with 16GB of RAM.
> Even above average workstations still have constraints. Those above average specs will eventually be adopted by the masses and a chat app will only function on a system with 16GB of RAM.
Android is really bad. 1.8 Ghz and 4 GB Ram and has difficulties drawing the screen and switching screens .