I use Discord and like it, but it is incredibly slow at starting, switching rooms, and even just loading new messages.
But the most aggravating thing is that I can't type a message on mobile if I don't have internet connection. It requires connection to load the input field. Affects me every day in elevators. Most native apps just lets you write your message and sends it when connection is back.
Fine, Discord is useful, but I must respectfully disagree that their app is good. And it is definitely possible to make natively.
Telegram on mobile is Android native, while Discord is based on "React Native". Telegram for desktop is based on Qt while Discord uses Electron.
It seems to me that most apps are written in Electron for two reasons: it lets you write apps in JavaScript that are conceptually very similar to web apps, so you're not learning a new weird-to-you language like C# or Swift, and it lets you go cross-platform with far less effort--you're writing one app rather than three. But this doesn't mean that you're not making tradeoffs in both performance and usability when you choose to go this route.
There may come a point in time when a well-written native app won't trounce an Electron-based app in terms of memory footprint, startup time, and integration with the host platform. But that time is not now, and it's silly to pretend otherwise.
Which is the case with Chrome itself too...a pretty unpleasant experience on the Mac if you have finger memory or want to use your apps together. Sigh.
I wish and hope that MS moving Edge to chromium is to provide a single host level run time for PWAs. It's a space they have flirted with and seem to be inching towards more quickly.
Also note that there is nothing keeping developers from adhering to Mac UI conventions that I know of. That's not a fault of Electron at all.
tl;dr - If Javascript and electron are winning it's because others are continually _failing_.
I presume this is true for other platforms/toolkits as well, and it's a tradeoff that doesn't get talked about as often as it probably should be. I'm not using a Mac because I woke up one day fifteen years ago and said, "You know, I'd love to pay a lot more for hardware than I probably should just so I can get minimalist industrial design, too few ports, and dubious keyboards." I use them because I like Mac UX conventions. I've talked to many people who actively prefer Windows UX conventions, or KDE or Gnome. I am not thrilled with the notion of a world where everything is a pseudo-native PWA.
It's also silly to pretend that users will notice or care, assuming a well written electron app. Again, look at VS Code. Now assume that the app is aimed at a non-technical audience who aren't going to be examining their resource monitors and who would never describe anything as a Mac citizen. If the customer doesn't notice or care, then the superiority of native apps does not exist.
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Try using the global search feature on Slack and tell me how that already existed in IRC circa 1995.
Isn't that particular feature mostly implemented server side?
On the other hand, yes, I agree that modern messengers has a lot of features that my IRC clients missed (voice comes to mind). Also they are easier for mainstream users to use and administer, and, compared to old IRC, safer in a number of ways (although I'd add that we are seeing a number of new threats now).
Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
Heck my Digital Ocean dashboard tab is consuming 155MB of memory right now (WTF DO?)
That said, I am blown away whenever I install an "old school" native Win32 app. The 90s APIs may have sucked to program for, but the end results stood the test of time.
Windows 2000 or higher Internet Explorer 6.0 or higher 128MB RAM/512MB for enhanced multimedia features (TOTAL RAM in the system!!!!!) Macromedia Flash Microphone and speakers/headset for voice/audio chat
Who are all these masochists using Tkinter? There are a ton other APIs to consider, and even more if one wouldn't mind updating an old one to be current (think XUL). I think this is the second or third thread where that particular toolset has been named as if it were the only alternative to Electron
I hate Electron too but is everyone really so new to the game that they do not remember desktop programming?
There's Swing, GTK, QT, JavaFX (maybe), WinForms....
embarassed hand raise
It's not that bad, just pretty bad.
The issue with memory consumption is definitely there.
But the issue for us is that if you're doing ANYTHING with 'content' you just have to use the web platform.
You need CSS, HTML and with pdf.js we have somewhat first class PDF support (though a few features are missing).
If it's a calculator app, then sure. Don't use Electron. It would be too bloated.
One feature in Polar that simply wouldn't be possible is support for web content caching.
We support downloading web pages for offline usage to allow annotation and to prevent bit rot.
It wouldn't be possible without some sort of web control but having full chromium (plus a webserver) means that you can setup a near perfect clone of the web but on the desktop.
I have a theory that the loudest complainers about this are the leftovers of the computer ricer era, who liked to display a bunch of metrics on their screen that mostly amounted to fluff. Electron solves real problems.
Signed, someone who's built and shipped native apps on the various platforms, and groans anytime he has to do a basic chart or whatever because it'd be 10000x easier in a web browser.
Edit: furthermore, the browser handles caching things like images and what not, which bloats up the memory in Electron. There is a way to force the browser to flush that stuff out, but nobody does it. If you have a local image cache for a native app and you don't flush it, you will get the exact same situation.
This application's purpose is to show text and little pictures (and occasionally process a few low-bit rate audio streams).
It is amazing that modern application developers are turning well solved problems for 90s computers into tasks modern computers can barely process.
Back when I had four megabytes of ram I wouldn’t have been furious over a 50kb editor. 200mb isn’t a lot when most developers are working on systems with 16gb or more of memeory.
Yes, I hate Electron with a passion. It's a slow, wasteful framework for lazy developers who can't be bothered learning Qt or something else non-silly. IMHO.
If a dev is working on a less capable machine I guess I can see why this is a problem, but a rather simple one to solve, close Slack, it’s a distraction to focused work anyways :)
(Creative Cloud is using 234.9MB and that's nothing more than a damn launcher!)
Now it is 164MB + 104MB + 85MB! And these measurement were not under high memory pressure! This isn't small by any means, still a total of ~350MB for a simple tool, but it is similar to Telegram which is a native Mac App. The two WhatsApp helper were previously using 700MB each!
And the major major improvement is compressed memory. Previously it didn't compress much at all. It was the same 700MB. Now it is 4.6MB + 5.2MB + 8.5MB, that is total of 18.3MB!!!!
I have no idea what happened, but in terms of compressed memory that is nearly 99% reduction in memory!
( Actually I am really interested in what happened, I wish they have changelog or blog post on the fix )
Right now (20181223T1031Z) WhatsApp (87.5MB) + WhatsApp Helper (149.9MB) + WhatsApp Helper (171.7MB) are using a total of 408.5MB.
Everyone's system is different. Everyone's WhatsApp is different. Everyone's memory usage will be different.
Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.