The answer: Electron and this new breed of lazy "developers" who can't be bothered to actually make decent native apps.
The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM), while GVim or Sublime or any native editor is subsecond. Granted, it does perform well enough once it's up and running. But startup time is probably an order of magnitude worse, and ongoing resource consumption even far less competitive.
Code shows that it's possible for a good Electron app to be better than a bad Electron app. But that's not a proof statement that Electron is in the same league is native.
There's some truth to this, but I also prefer it to (my previous workhorse) Sublime. Which is a 100% native app, unlike Atom.
> The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM)
Something is wrong there, it really shouldn't. 1 second, maybe, if you're loading a large complex folder or something but unless you've got a crap ton of extensions I've never seen it be that slow.
I only run Slack in a Chrome tab now.
I would love to see Electron abandoned...
pyGTK is a good toolkit.
On the JVM side of things there's JavaFX
Almost anything is better than bundling webkit really... even WinForms. And the above list is mostly new stuff for new devs. For the real programmers amongst us there's QT, GTK, JVM's Swing...
People that aren't afraid of the hard stuff, and don't need software to wipe their ass?
As for software... IntelliJ IDEA (Swing), we use internal pyGTK stuff that runs on Win/Mac/Lin, Wireshark (QT), Mozilla Firefox (XUL ... another brilliant UI markup language which died for no good reason), pgAdmin III (wxWidgets)
On the music plugin side of things there is a lot of VSTs written in JUCE framework, another good cross-platform UI kit which focused on audio software.
You're just hating on something new and praising some old things, but in the past, those same things were also hated on for the same reasons (e.g. so many people hated on swing and java in general early on for wasting memory; "real programmers don't use Java")
Each electron app spawning up separate instances of chrome is totally wasting memory. Argue about that, instead of "real programmer" bs
And to follow-up edit, of course theres no one true scotsman. The assembly-reciting graybeards look down at GUI programmers, who look down on the webdevs, who really don't have anyone to look down upon because they still have so much to learn.
And why does the argument always have to be about resource consumption? Does anybody actually even truly care? I hate Electron because it is an incredibly poor use of existing resources and that it leverages tools very inappropriate for the task of creating cross-platform GUI applications. Entire industries are built out of this unholy Frankenstein of duct tape and chicken wire. Now, for the job of quickly banging out an app so the business fucks can make their $$$$$.... now that's different
… because there aren't better tools.
If you think there are a plethora of amazing tools out there that people are using to build cross-platform apps, then you're wrong.
Real audio programmer here.
I used nw.js (essentially like Electron without the necessity to do IPC for intra-window communication) to port the frontend for a realtime audio engine written in C. Frontend and business logic speak over a socket.
No need for JUCE because the UI has no need for JUCE's audio tools.
Port could happen extremely fast because of the brilliance of Chromium devtools-- introspection and real time updating of styles/DOM state was a life saver. This was a port from tcl/tk which had (has?) a half-baked theme-ing engine and no easy way to introspect the contents of a Tk Canvas.
Qt would have been nice but the frontend is a visual diagram with boxes connected by Bezier curves. QML doesn't have an easy way to do that without the performance scaling with the size of the logical canvas (which is unacceptable because users sometimes want enormous logical canvas sizes).
Exactly the sort of shitty attitude that will get us nowhere.
I have seen a plethora of QT, GTK and other cross-platform applications that weren't only laggy as shit, but riddled with UI bugs.
I fucking hate that Electron is now an accepted way to build applications, believe me – but the reason we ended up in this situation is because "real programmers" failed to develop a framework that effectively dealt with developer and user needs.
Anyways, it shouldn't be the job of the toolset to prevent bad users from shooting themselves, therefore you are always going to have bad, laggy programs in any UI paradigm. It is the job of the toolset, and those that built it, to not take any one piece of tech too far (in this case, HTML rendering engines) when there are so many acceptable and superior substitutes.
This does not match my experience. Sublime + Plugins to bring it to parity with VSCode === much slower than VSCode. Especially with larger files.
Damnit, HTML and JavaScript were never meant for this kind of abuse.
Same for someone writing a UWP application for Windows 10, or an Android app. You don't win by degrading the experience on all of your target platforms because it's "easier", you win by carefully considering the people who actually will be using your software and the circumstances under which your application will run.
Except for that time when it was constantly using 13% CPU to display the blinking cursor: https://github.com/Microsoft/vscode/issues/22900
One game I remember was a 2D space game that had pretty good graphics, digging into it's folders and being surprised at seeing pygame and python everywhere. But it's probably been 10 years since I've played it so I can't remember the name. The rest is google.
Edit: Removed commentary about most desktop apps based on https://news.ycombinator.com/item?id=14869864
In my own personal experience, these applications have almost never provided me with a more pleasant experience than eg a Qt application.
Plus I've had Slack's CSS mess up giving me a weird messed up UI. This has NEVER happened with an actually native application. I've also had Slack consume 4 gigs of RAM, which is ridiculous for something that is never the main thing I use my computer for.
Quicker time to market perhaps, but "reliable cross platform experience".. not in my opinion, at least, unless you mean that its reliably equally bad on all platforms ;-)
EDIT: Cross platform is easy when you don't need a platform-native look and feel, which web-as-native often doesn't do anyway (or not perfectly at least)
Most by number of apps? Consider all little enterprise things built in Java or whatever.
Most by time spent? Browsers, AAA games and file managers aren't web apps, surely?
Most by HN hype and VC funding?
Electron or not, you need a web browser to display content. Unless you want to replicate a browser's layout engine, poorly. History and the rich interface are the main appeals of Slack.
I guess you could create a QT app or something and embed a web widget inside. Not sure how much that would help.
Slack could easily use native widgets, without embedding any HTML.
Rich interface doesn't mean HTML and CSS. Have you seen good iOS apps? Their interface is just as rich and yet it's pure Swift/Objective-C compiled down to native code.
For instance GTK apps in the earlies 2000s were easily displaying content as rich.
Point is, native or not native, this should not matter for a well optimized code. We are not talking about a AAA game here, it's just a chat app. It should not be burning cycles when inactive.
You can replicate it with native widgets. Heck, you can draw everything yourself if you want. But why bother, if you already have a perfectly good way to display that sort of content?
The problem is not "lazy developers using Electron". The problem may actually be lazy developers, but not because of Electron alone.
To me it's like sending a word doc attachment because you want to use bold type in a mail, and you already know how to use word.
Actual issues aside (yes slack takes up way too much memory and it's due to the platform they chose which is hugely bloaty but will undoubtedly get smaller/faster over time just as everything does) why would you choose to attack the developers for building a tool that millions of people use with great success? They're not lazy. They used the best tools available to them to deliver their product and they're reaching the limits of said tools. Now they have to address those limits. This is exactly how software is supposed to work.
At the end of the day I don't care which technology is used as long as the end product is good, however a chat client that uses 1,5GB of memory is the total opposite of good. Come on, it's a f'ing chat client - a solved problem and existing implementations (look at any IRC client) take like 100MB's max. I would have no problems with Electron if they somehow managed to get the resource usage similar to a native app.
The answer is likely multifaceted, but part of it is undoubtedly the usability of the client - which may be resource intensive, but that was likely a trade off for speed/ease of development.
However Electron takes this to a new extreme - the memory usage of an Electron app is like 15x of that of a native app, and yet I can't buy a Macbook with 100GB of RAM.
Is it user-focused to allow that bug to remain? How do you judge the importance of your users' time?
Slack - often Electron-based apps in general - are fast for the developers to create, but cause problems for the users. There are many more users than developers, and a good question is, is the value of users' time and money less than the developers, or the user's resources (such as memory) the developers' to freely use? Developers can't write their whole app in assembly, but at what point do the problems their choice of technology cause for users overbalance a reasonable standard of consideration for their users and user experience? An app with the problems Slack has is one that has largely prioritised the developer's time and resources over their users.
So your "real developers" comment is a straw man ;) But you're close, I think: better is to consider the balance of value developers ascribe to themselves vs their users and what use of Electron, and app behaviour like this, says.
The question then becomes, once established, do they improve the app?