It works, it's beautiful, it's easy to use, and unlike many people here, I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.
It is a huge productivity boost for programmers at the expense of making computers slow. On my work computer I am used to run many apps, and with each Electron app added I feel it slowing down. (latest one to switch was Skype for me). What is the point of having such powerful computers when they feel like slugs crawling through a bog?
It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.
Meanwhile, in our universe, it's somehow considered reasonable to expend nearly six gigawatts (= 51 TWh per year) on a number-guessing game that will totally revolutionize global finance some day.
In the meantime, the invisible hand is doing it's thing. Time will tell what it's thing will look like.
This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.
And now Mac users get the same terrible Electron app. The problem is that companies are not just making Electron apps for Linux users. They are replacing native well-integrated Mac and Windows applications by Electron apps (Skype) or do not consider writing native apps (Slack).
So, we had nicely integrated applications with Automator workflows, consistent shortcuts, consistent look and consistent feel. And we are replacing them by things that do not fit into the platform at all. No thanks.
That’s a straw man argument. The parent said that Linux development might not be worth the cost. They didn’t say anything about the ability to pay.
«Team, M$ killed Skype for linux, I cannot use it anymore, let switch to something else, like Slack.»
But to be honest, I'd rather have no GUI app on Mac/Linux at all than have it basically be a requirement to waste resources on Slack or whatever other crap and to have developer energy tied up in an editor as shitty as Atom.
It's only 90 KB (!)
Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin.
I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.
Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.
Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.
VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable.
[1] https://twitter.com/id_aa_carmack/status/695013979807047680?...
Compare VSCode or Atom with Emacs or Gvim for something more native.
To pick some apps off my desktop right now:
- Emacs with a pile of extensions, 22 MB
- SpeedCrunch, 13 MB
- SumatraPDF, 19 MB
- MS Word, 101 MB
The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.
You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available.
But also if your logic were correct, we'd all still be writing C.
There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened.
I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well.
It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.
Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones?
If find it hard to believe React etc. are easier than .Net, for instance.
To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful.
This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things.
Stuff like interface designers shipped by MSFT are pretty great though.
Programming for the web makes me feel like I’m back in the 90s, no even Java/Swing was easier. I get making the sacrifice if it means I can run in the browser, but not otherwise.
I have fond memories of debugging C# with Msft tools, but I also suffered a decent amount on the debugging cycle in C/C++. Being able to just patch in some new code without going through a whole compile/set up the environment again is very useful.
I can understand thinking that the foundation of the web is bad, therefore web development is bad. But I would take the chrome debugger experience over C/PHP/Java debugging experience most days of the week.
(That being said, I could simply be unaware of some debugging tools in that space that make things nicer)
Doing UI in C/C++ sucks, but that was also true in the 90s.
Chrome is a horrible debugger from a UI design perspective. Debugging through VSCode is better, but I still miss simple things like auto toString displays. Surely the tools could get much better, that they haven’t is depressing.
There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it.
With "cloud services" they do not need to think about the servers sitting in racks doing the computing.
And with Electron, this kind of mental distance is making its way onto the desktop.
Can't I just as easily say that the JS/HTML/CSS people are the ones refusing to learn a new ecosystem?
I was once really into frontend web dev, and learned JS/HTML/CSS. Then I realized it mostly sucked, and went to school for EE. Now I get more upset than anyone I know about Electron apps.
It only takes one counter example.
I also don't notice my machine slowing down with Electron apps.
That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.
The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).
One example of a service that probably _could_ have a web version is Spotify, but they only offer their service via their Electron app.
Apps I care about are VSCode, Atom, Spotify, Slack.
There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.
Okay, maybe you have to use Slack or Discord at work.
Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software.
The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels.
What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes.
What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.
Electron is not a sensible trade off. It is not necessary to accept that level of inefficiency to get that productivity boost. It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.
And we end up with a ridiculous Frankenstein solution that is fractally wrong. But it is "Easy" because 90% of programmers are used to HTML,CSS,Javascript and so they can suddenly make 'desktop' apps now.
And no, we don't have a choice when almost every desktop application being made now is being made in electron. Its just awful, and you should quit dismissing the people telling you how much they hate the situation, its real.
And of course those of us that hate it should be aiming to help fix the situation, but of course it is difficult, since anything you propose that is not HTML/CSS/Javascript seems alien to so many modern programmers that they reject it out of hand.
While there is an ongoing trend to move towards web apps, I think you are mixing up the causality here a little bit. The main reason why developers are increasingly choosing to move towards web technologies for UI is the sheer pain of doing any kind of cross-platform development on the desktop.
Most of the nice desktop development frameworks (like the ones in C# or Swift) are not cross platform. Meanwhile, we have a decent cross-platform UI framework in Qt, but this requires dealing with C++, which doesn’t even have a good package manager behind it. You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.
Basically if you want to easy-to-use cross-platform desktop UI development, your choices boil down to Electron, and maybe pyQt.
Desktop developers have years to make this a better situation by perhaps promoting cross-platform UI standards or building better tooling, but nothing good has really gained much traction, so more developers are justifiably moving to Electron for now.
We are already a decade into neglecting native app technologies in favor of web app technologies, because web apps were much easier to write and deliver than cross-platform native apps (and largely still are). It’s to the point where even big companies with lots of resources are hiring web programmers and web designers to build their UIs.
It’s interesting to me that mobile changes the trade-offs. The quality gulf between web and native apps is greater. The web sucks more on mobile, and expectations for native apps (animations, touch, etc) are higher. Mobile OSes also make it much easier for users to install and manage native apps than it is on desktop (because of the app store, no custom installers, no users locked out of installing apps by their employers as far as I know). I’m excited about React Native for addressing the cross-platform part.
We’ve learned since Java that even if you don’t have “write once, run anywhere,” you can still have “learn once, write anywhere,” a la React. Also, we expect apps to come with their own systems of UI widgets these days, not necessarily “native look and feel.” It really changes the game.
Wx is using native widgets on every platform.
(I use native in quotation marks because we can probably not even agree on what that is.)
This attitude seems to be common here but everyone hating on electron seems to ignore any positive aspects of it and only focuses on the fact that it is slower and/or more resource intensive then had it been written in <native-language-of-choice>.
You can dislike Electron on a technical or principal level, that's fair, but until there is an alternative that would be considered better by most things will simply not change.
Until then, repeating the negatives over and over again only serves to de-value the efforts of those actually producing and shipping code and the only possible outcome is another "tabs vs spaces" holy war.
Generic reactions to negativity, saying there are two sides to every coin, do not really contribute to the discussion, IMO, so I disagree.
I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better.
I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else.
Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.
Having a web app + native app means a huge leap in cost.
Having no web app + native app means a huge loss in user reach.
The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.
https://github.com/Microsoft/react-native-windows
and http://reactdesktop.js.org/
The Windows one is from Microsoft, but is single platform. Nothing officially supported by react devs as far as I can tell.
at one point I don't care about multilayer super cute guis
btw turbo pascal had shadowed windows in TUI
Everything about the thing felt 1990s... in the best way. The IDE was clearly designed not for initial discovery by a novice, but for someone who they ultimately expect to become proficient and thus able to capitalize on the expert-friendly UI.
The reasulting binary felt like the 1990s too: A single small executable with instant load times :-)
End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in.
It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content.
Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.
Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.
I'd much prefer if these companies used open APIs (some do) and let the FLOSS crowd make clients if they cared for them. I've replaced the spotify application with librespot lately and it works very well, although it lacks a UI so I have to use my phone as a remote. I'm also currently using the signal electron client which works okay but uses an order of magnitude more RAM after a few minutes of runtime than my irssi that's been running for months. It also doesn't have better usability if you don't like clicking everywhere and prefer keyboard control.
I don't hate electron, it's just "okay". It's a symptom of the webification of the world as web technologies make a foray into the desktop and server space. I think a framework like Qt is objectively superior, both from a developer and user perspective but I'm sure these days it's probably easier and cheaper to find webdevs than Qt devs and it's all that matters.
I've looked into alternative Slack clients for example which seem to be doable, but the only ones I saw were dead and/or looked terrible.
I've yet to see FLOSS crowd come up with a remotely useful client for anything. Event in the days of much simpler APIs and apps like IRC FOSS apps were universally meh.
Super small footprint, I can do everything with the keyboard, I can script it, I can run it on a server in SSH, I can customize it any way I want.
Meanwhile on my large screen I can barely see 10 messages in the backlog of the signal desktop client because it feels the need to emulate an SMS UI (you can even select if you want it to emulate the Android or iOS UI, how cool is that?), I still haven't figured out if you can create groups in the desktop interface (given the very small number of options available I don't see how I could miss it, maybe it's simply not possible). The input box has english spell checking enabled by default which is pretty distracting when I'm typing an other language since everything gets underlined, I haven't found a way to disable it or change the language.
The other day I had to use the Discord webapp for something, what a joke. On my pre-quantum Firefox it was laggy as hell, there was a noticeable delay sometimes while I was typing text. Maybe you'll blame Firefox for being too slow but we're talking about an actual text chat here.
It does look better than a terminal window though, I grant you that. Maybe I should print it and frame it somewhere in my office.
9 times out of 10, a github project fixes my bug report very quickly.
Half the time I'll send an email to a closed source project and never hear back about it.
FOSS is also doing well in an era where proprietary clients mean crappy electron clients. That's a low bar to beat.
It's funny, I try Vim and I like it. HN convinces me to try Emacs and I like it. I'm not supposed to like Electron apps but I try VS Code on my 4+ year old chromebook with 2gb of ram and it runs just fine and I like it. Same goes with Slack. Seems pretty damn good to me. This all repeats itself when it comes to programming language debates too.
Is something wrong with me if I'm interested in vim, emacs, vs code, python, js, elm, go(!), haskell, rust, and racket? Am I just too inexperienced? Will I develop to have only one true religion or is there just something HN and r/programming brings out in people for these constant "one true correct way" debates.
I get mad about Electron because it seems that we should be able to solve the problem without running a web browser for every app. It's unfortunate that Electron is so much more appealing than more efficient alternatives. I wish we could end this trend of software efficiency declining to compensate for hardware improvements.
It probably does, if it's the only thing you're running. I know developers think their app is the best thing in the world but they have to realise it's not the only thing running on my machine. RAM is a scarce resource on my dev box.
Really ? Because rendering HTML/CSS is an extremely complex way to render a UI, and it was clearly never designed for it. HTML was intended to add markup to documents, not build user interfaces. It lacks the most basic layout primitives you want to use in a UI and a lot of behaviour is either not well defined or not well understood, mainly because it's unreasonably complex. It's easily the most complicated way to build a UI we have right now, which is why we need all those stupid frameworks built on top of it to make it somewhat usable.
HTML is and has alway been a huge mistake for building UI's.
I disagree completely. It's easy to get a 'hello world' type thing working in HTML, sure, but it's very hard to make something behave like you want. Traditional UI toolkits are much simpler and easier to understand.
If you don't need to support IE11 you can use CSS Grid and do the entire layout in one or two CSS properties.
Not by a long shot. It's one of the worst things to happen on the desktop, because people who would have built a proper desktop application just wrap their web app in Electron instead.
It's particularly bad for the Linux desktop, where people are used to small binaries that use the system-wide Qt or GTK so they load fast, and use little RAM.
There's no consistency between the dozen "toolkits", each one with its own way of doing things and a lack of interoperability. If you ever had to work with X11's concepts of drag'n'drop, windows, input etc. you probably know what I'm talking about. Dozens of toolkits, few of them talk to each other. It's a mess. Electron just works.
People who would have built a proper desktop application simply don't because the tooling, the environments, the standards (and lack thereof) are awful.
The whole concept of "toolkits" is what makes the situation a complete mess.
Unless you have a good reason (in which case, you'll know), you can just ignore everything other that Qt and GTK.
Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
Meanwhile, on Windows for example, there's a standard way to write GUI apps, standardized, well-known and consistent APIs to deal with GDI's toolkit etc. It's awful to write GTK apps just as it's painful to write in pure WINAPI GDI, but GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days.
Then comes the community: we have 20+ years of GUI programming happening on Windows, most people simply stick to GDI + self-made custom controls. The outcome is a huge knowledge base that helps get anything and everything done on Windows. Here in the UNIX world over the same time period the GUI developers are spread among different toolkits, so we have many "ok" people in a dozen toolkits and few experts on each one.
Qt is LGPL. So long as you dynamically link to Qt, it doesn't matter what license your app is under. If you don't dynamically link, you lose the integration benefits anyway, so there's no downside, really (Qt is backwards compatible within each major release, so just build against the earliest version of Qt 5 your app works with).
> GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days
History means we have two defaults on Linux: Qt and GTK. Qt integrates well in a GTK desktop though, so you can just use Qt.
No doubt it will be years before everything moves over, but at this point Qt is the clear winner: it's always looked better, its licensing issues are now solved, it's the only option that has remotely decent bindings for a remotely decent language. A month or so ago there was a new release of Wx and the comments here were universally "that still exists?"; GTK will go the same way.
There are other options, there are people who really like those options, but Qt has the momentum and has the knowledge base. Just use Qt and you'll be fine, or at least you'll be no less fine that you were with GDI on windows.
Just use Qt.. or GTK. They work and aren't difficult to use. Qt stuff works nicely on windows as well.
Orrrrrrrr - JavaScript/Typescript with the amazing Chrome debugger and get my work done in half the time?
You’re really really not selling Qt at all, least of all to people who might have NodeJS (lots of those) experience and want to get something done quickly.
Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings. Because even those guys want to get their job done quick.
So, basically - Electron seems like a really nice default choice.
So much like Electron then?
Use Qt, use Python, and get on with your life. Or use Electron if you prefer, that's fine too. But don't make out like it's the only reasonable option and everything else is too confusing. If you ask 10 developers the right way to do a simple GUI application on Linux, 9 of them will tell you: do it with Qt and Python.
No need to use their smart pointers either, I certainly never have. Never saw any reason to since C++11.
No issue at all mixing with C++11+.
Yes, I agree, Qt just works. My initial point was and still is about interoperability. They don't all speak well with each other and there are many good, useful applications in toolkits other than Qt or GTK.
We're talking about proper toolkits vs. Electron here. Good luck making Electron look native, yet alone "talk" with anything :P
With Qt I can use the clipboard, sockets, and so on, set an icon for the application. Linux applications have standards to follow, as long as they do they look the same to the desktop environment.
Are electron apps magically able to speak with other electron apps, in a simpler way (to implement) than Qt applications? I don't think so.
Frankly this is a complete bullshit argument. Qt in particular can be used with little to no code change across the platforms.
And some of the most successful programs on Windows have basically gone their own way in terms of look and feel.
You can't, for example, simply fire Spy++ and check what a given widget is doing, as you can with GDI. The lack of a basic widget building block in X11 makes each one implement the very basics their own different way. And when they need to talk to each other, it's at the very least an unpleasant ordeal.
Precisely, people will just use something else. The proliferation of Electron apps splits the user base, so there's less incentive to develop a proper desktop application.
Except no-one would have built clients for the linux desktop. Go back before Electron and count how many official clients for Linux there were from major software vendors, hell I'll even take massively feature incomplete answers like "Skype" just to help you.
I much prefer the ability to running a slightly inefficient program over not having that program at all.
One notable example is Skype: their Linux client sucked so much it was unusable until their Electron version made the Linux version just as good and modern-looking as the rest.
It's not that "HN hates Electron", but some competent programmers, especially ones who have experience creating desktop apps, point out that Electron apps are huge resource hogs. It's not about having an opinion, rather stating a fact.
Maybe these competent developers don't realize that lots of users don't care if their app use 100-200mo on an 8Go laptop. Nor do they realize that memory usage is one indicator among a few others that are as or more relevant to the various contexts: productivity, talent pool, cost, maintenance, etc. Trade-offs have to be made, Electron is one.
In the work environment (non-tech) I experienced several times that people complained about bad usability and apps slowing down the computer. More often than not, those were Electron apps. But the standard corporate solution is to just upgrade computers to 32gb ram and even faster processors. Not sure if the faster development speed in Electron still saves money then.
Don't get me wrong, I think Electron is generally a great idea. VSCode works great. Similar to websites, slow performance is rarely a fault of the underlying technology, it's a result of programmers not caring about performance.
Unless I've got Slack, Keybase, Spotify, etc open. Those just cripple the machine. Also Outlook, but I recently replaced it with Thunderbird and it seems to run much better. I find that my complaints are mostly met with accusations of being an old man (I'm 34...).
Native apps cost 10 times more and take a lot longer to build since you have to build 3 versions instead of 1.
So..?
I can't think of anything good that has come out of electron. Seriously. Maybe slack (haven't used it) but that is probably about the worst use case for electron imaginable and would be utterly trivial to implement in a proper language natively.
Have you tried to develop a cross-platform app for Windows, macOS and Linux recently recently? I do not know what you mean by "trivial", but using HTML/CSS/JS is the fastest way to develop UIs, and so, apps/programs. No contest. (about performances or resources management, that's a whole other story).
And using different techs for each platform to have a native app is not what I call trivial for developers in terms of complexity.
With javacript you have to constantly fight the language, the frameworks the performance etc. This will actually end up taking more time and effort than doing it properly in native languages once you get past the proof-of-concept stage.
Having a cross-platform core and then doing a platform specific GUI for each platform is a bit of work up front but hardly a big hurdle all things considered.
The advantages are that you actually get an app that looks and behaves the way it is intended on each platform. And an app that actually can be user friendly. Did we all just stop and say, hey, users suck. Why should we care about them? Let's give them an ugly mess that doesn't perform.
That by itself is a tragedy, but what is astonishing is that it is done for no good reasons.
Some of the appeal of electron is code-reuse and being able to use something other than javascript will make it easier to share code with native software rather than web pages. That would be a huge benefit in my eyes.
This makes it useless for any non-trivial app that is CPU bound - including, games, audio, video, 3D, and many many more.
Just because it's easy to build a house with Lego doesn't mean it's a good idea, or that it's going to compete with professional building materials.
1. Use current dev team to develop only the web version?
2. Hire X teams to develop for X platforms? (there goes your linux support)
3. Hire 2nd team to work on a cross platform native desktop client?
4. Open APIs and leave it to the wolves?
Everyone on here is acting like a few hundred meg of ram and barely 0.5% CPU usage is the end of the fucking world.
Also, you'd be surprised how fast 4gb gets used up by the time the OS, the browser, and various Electron apps take their cut. I can't browse the web while having Slack and Spotify open or things start thrashing. I think it's past the point of ridiculousness when a simple chat app takes more memory than a full featured IDE like IDEA.
If something like Slack is "utterly trivial to implement in a proper language natively", why was Skype so awful for so long, to the point that they've now switched to Electron?
Among terminal emulators for example, Hyper is the only one I can think of.
Don't forget HN is a bubble : Electron is very much appreciated outside of this particular community.
There might be tons, I just haven't seen anything usable.
Not seeing "anything usable" is pure bad faith.
But yes, VSCode is probably the exception. But they have had to spend a truly impressive effort to combat the shortfalls of electron and are to my knowledge the only ones that might have succeeded in making something relatively performant.
If that is what is required to make electron decent then few arguments in favor of it remains.
Yes I get that different sets of features on different platforms is an issue. But often that is half the point, if everything could be done on a website there is in the vast majority of cases no need for an electron "app".
The problem is that it isn't the solution to the UI problem. It's just yet another way in which developers can mindlessly fragment it even further.
For example, take Slack, Riot, Atom, VS Code, Keybase, etc. Not one of them makes an attempt to look like the host operating system. They don't use the native UI toolkit of the host platform. They don't even make any attempt to follow design conventions of the host platform.
Let's take macOS. In just about any text field in any application, you can right-click and get access to spell checking, substitutions and transformations. You can get macOS to read out the text you highlight by speech synthesis. Except for in Electron apps. Why? Because the text entry fields in Electron apps aren't typically native text entry fields. They're merely imitations and bad ones at that.
Also none of these Electron apps look or behave like each other either. Every developer has taken it upon themselves to play UI designer (almost always badly too) and to create their own buttons and their own sidebars and their own menus and their own controls and not a single one of them looks or feels like a first-class citizen in my operating system.
So the learned behaviour I've collected from 15 years of using Macs is now suddenly useless in Electron applications. Why? Because either developers want to cut corners, or some incompetent project manager wants 3 platforms supported by last week, and by the way, fuck your users, I need this done.
As with everything web-based, design and function are too closely intertwined and the result is consistently mediocre (if not terrible) user experience.
Of course there are some poor implementations (Slack) and some really good one's (VSCode). Criticism of the platform for the deficiencies of an implementation feels a bit lazy.
Beautiful is in the eye of the beholder. I much prefer consistent UI look and feel and Electron, may come close, it has it's nuances. It's probably my number one gripe. I'm on macOS though, so it could be different on your Linux desktop environment of choice or Windows. I still prefer TextMate 2.
If it is then we have failed horribly as an industry. We can do so much better, and we should strive to.
No, the best thing was flash.
second, Adobe AIR using 100% CPU is completely false
I'm not a system programmer by any means, but I consider myself well-rounded enough to be able to appreciate useful technology.
CSS grids and responsive @media, e.g. [1], are a useful addition to native applications design.
I don’t know what the goals of the electron team are (unless they have shares in power companies and thus want CPU’s running at 100% everywhere) but I doubt their goal was making “desktop apps that aren’t available on linux”.
That’s the only way this would be irony.