Electron apps invariably make such kit feel slower than it actually is. You can get good performance out of even older hardware if you treat it well and load it with good software that respects the hardware.
No electron apps!
I don't know what these companies are doing. Clearly they're not paying attention though. This is not merely low-hanging fruit that's going ignored, it's watermelons.
That sounds like your problem. And I refuse to believe that the new steam UI uses 2gb of memory.
Apparently, they trade off still worth it, as many electron apps are popular despite these issues. Many times there is electron app or nothing.
I can make a great chat system that uses fast native client, but it won't change the fact that Corporation A paid for a slack license and won't switch to mine.
No need to hack it with taxes.
What?
We have customers who requires servers with 64GB+ memory, of single applications. This is running on VMs in VMWare. If a ESXi host crashes, you'd want VMWare to migrate your VM to another ESXi host, but that becomes somewhat tricky if you need to locate one with 64GB of available memory. Unless of cause you're way over-provisioned, which is actually pretty expensive. More realistically VMWare will start moving a ton of VMs around to put all those with little memory usage on other hosts, in an attempt to find 64GB for your VM. This takes time.
It can be difficult to explain to people that really this should look at their memory consumption, if nothing else to plan for fail-over.
At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant.
These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386.
People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.
I watched a lecture by Bjarne Stroustrup that he gave to undergraduate CS majors at Texas A&M where he coded a solution to a problem using linear scans and then a "better" solution using better algorithms with better big O performance.
Then he did something interesting. He did a test on a tiny data set to demonstrate that the solution with linear scans was faster, and he asked the audience to guess at what data size the more efficient algorithms would start to beat the linear scan. After the audience members threw out a wide range of guesses he confessed that he didn't know. He had tried to test it that afternoon, but the linear scans outperformed the "better" algorithms on any data set that he could allocate memory for on his laptop.
IIRC he finished by telling them that professionals often do performance optimization the opposite of how the books present it. Using an algorithm with optimal big-O scaling isn't the optimized solution. It's the safe answer that you start with if you aren't bothering to optimize. When you need better performance, you evaluate your algorithms using real data and real machines and qualify your evaluations based on the characteristics (size, etc.) of the data.
That being said... I know exactly what you are talking about and it was always strange to me, because it was actually iterating through every time to find a value first, so the iteration through the linked list would always kill the performance. Even so, basic linked lists are practically obsolete. This is not a good example of algorithmic complexity, because the complexities were actually the same.
Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go.
But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility.
If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort.
The correct choice depends almost entirely on the domain.
know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c"
For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code.
Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO?
Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least.
Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions.
Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code.
Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.
Let's not bring "in-house web app" into the picture just yet.
My mention of SQL was particularly deliberate. It's an especially successful high level declarative language with clear semantics. Implementations provide sophisticated execution engines for optimizing and efficiently running queries. It is quite a lovely separation of concerns that gives you great flexibility and good performance.
Obviously SQL would be a disastrous choice for, say, storing the pixel data in your video codec. Meanwhile, hand-coded C data structures and algorithms would be a disastrous choice for an inventory management system. Tradeoffs everywhere.
a well DESIGNED technological stack WILL allow for high-level control of low-level structures.
Electron and Browser-based apps make a deliberate tradeoff that may be suitable for some kinds of apps (Balena Etcher, as I mentioned. You click a button and some process starts and alerts you when it's done.)
I would simply say that the OP should reverse the question: "in which cases can an electron app suffice for a desktop application" and not presume the death of desktop apps.
The trouble with Electron apps though (and most Node apps) is the sheer number of dependencies. It's just infeasible to package them for a distro if you care about their dependencies being packaged as well - at least, not without the entire process being automated.
On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs.
And Ripcord (a native discord/slack client) is a mere 40.
How big is Spotify now?
$ pacman -Qi spotify
Name : spotify
Version : 1:1.1.10.546-4
Description : A proprietary music streaming service
Architecture : x86_64
...
Installed Size : 272.79 MiB
If you want to see how it’s done search the package name and AUR and you can see the build script right on the website.
Unfortunately it's proprietary, but there's another native client called gtkcord3 [0] that seems to be progressing well.
The core task Slack is charged with WAS done 2 decades ago with significantly lower resource usage?
Why does this matter? because Slack is not your main productivity app (I HOPE) it's just a background process, effectively, most of the time, a communication channel you keep open and check in with from time to time.
Being able to keep an app open while you run your main productivity suite is a clear win. Slack loses in this respect.
But go on, downvote and flag me some more for speaking truth to power... it's rather obvious, i would say...
> OTOH, if you are using Slack, you probably deserve it :P
then you say:
> not saying you have any choice in the matter of using Slack or not
Now, I don't actually run Slack nowadays. I run Teams, which sounds like it's efficient since it only uses 600 MiB RAM rather than a full gigabyte.
But the choice between Slack, Teams, and any other product we might use is determined not by the user, but by the company we work for. Companies have a tendency to decide what works without respect to empirical data. Business people are unconcerned with mere technical matters; they optimise for purchase processes.
I think you got downvoted for saying we have any choice in the matter. When you made a valid criticism, your comment fared much better.
I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks.
I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.
Code reusability between browser/desktop/mobile is one. Easier to find developers, faster development speed due to ecosystem, previous experience/familiarity etc. I guess.
And currently taking < 300 MB RAM
"memory are cheap"
"cpus are cheap"
Say the same people who spend a million on AWS every year