Why Electron Is a Necessary Evil(federicoterzi.com)
federicoterzi.com
Why Electron Is a Necessary Evil
https://federicoterzi.com/blog/why-electron-is-a-necessary-evil/
129 comments
I believe this community fully understands everything in your post, and believes Electron is a bad decision anyways. Why? Because when we're talking about these things, we're *users*. As a user, I don't care how easy it was for a developer to write the software. I care that it respects common UI conventions. I care that it's secure. I care that it doesn't use unnecessary resources. I care that it integrates well with the rest of my operating system. I care that it supports i18n and accessibility controls.
Electron is approachable because it eschews all of these things in favor of convenience to the developer, but these things are important to the user, and the user is who we should care about. We write software to serve users. We need to be asking ourselves if the benefit of the barrier to entry on producing applications be so low as to give up all the benefits of more traditional ways of application development (I'd argue no) and whether it's worth trying to bridge the approachability divide with easier APIs for developers and making the development experience as user friendly as possible (I'd argue yes).
Electron is approachable because it eschews all of these things in favor of convenience to the developer, but these things are important to the user, and the user is who we should care about. We write software to serve users. We need to be asking ourselves if the benefit of the barrier to entry on producing applications be so low as to give up all the benefits of more traditional ways of application development (I'd argue no) and whether it's worth trying to bridge the approachability divide with easier APIs for developers and making the development experience as user friendly as possible (I'd argue yes).
As a user I care about having the features I want, working the way they're supposed to. And, as someone who uses all of Windows, macOS, and Linux in a typical day, I want these features to work consistently across platforms. There is really nothing worse than a "cross platform" application that fucks you when you try to move back and forth, and the Electron applications I've used consistently do better at this than anything else. If Electron itself is the reason these teams are able to focus on features and let compatibility "just work" for the most part, that is IMO a huge point in its favor.
More broadly, I think the popularity of Electron apps is evidence that users are actually very happy with them. There's an argument to be made that modern software is in general bad for users, but plenty of Electron applications (e.g. vscode, Obsidian) are IMO relatively unimpeachable in terms of offering real useful functionality with a minimum of dark patterns and/or other sketchy practices.
More broadly, I think the popularity of Electron apps is evidence that users are actually very happy with them. There's an argument to be made that modern software is in general bad for users, but plenty of Electron applications (e.g. vscode, Obsidian) are IMO relatively unimpeachable in terms of offering real useful functionality with a minimum of dark patterns and/or other sketchy practices.
Using all of Windows, macOS, and Linux in a typical day makes you an extreme outlier.
Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
Do you claim Electron apps have fewer sketchy practices?
Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
Do you claim Electron apps have fewer sketchy practices?
> Using all of Windows, macOS, and Linux in a typical day makes you an extreme outlier.
Another extreme outlier here, so according to the 100/10/1 rule of 100 readers/10 voters/1 commenters we have 200 extreme outliers just in this thread ;-)
(Although I should note that I don't use all of them every day. Mac is a Mac mini in our office at home, Linux is both on a work laptop and also on an old personal laptop that gets used for personal learning and personal projects, Windows is a work laptop. Telegram an Joplin gets used across all of them.)
Another extreme outlier here, so according to the 100/10/1 rule of 100 readers/10 voters/1 commenters we have 200 extreme outliers just in this thread ;-)
(Although I should note that I don't use all of them every day. Mac is a Mac mini in our office at home, Linux is both on a work laptop and also on an old personal laptop that gets used for personal learning and personal projects, Windows is a work laptop. Telegram an Joplin gets used across all of them.)
> Using all of Windows, macOS, and Linux in a typical day makes you an extreme outlier.
Sure? I just wanted to make note of something I think is great and underrated about Electron. The outlier-y nature of that something is exactly why my next paragraph starts with "More broadly,".
> Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
> Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
VS Code and Discord are the big ones that come to mind as both widely used and widely preferred by their users.
I don't think the fact that it's possible to build shitty applications in Electron is very interesting, since that's true of every other UI framework. Neither does the fact that some people actively dislike e.g. VS Code contradict the fact that a great many people like it very much and independently choose to use it.
> Do you claim Electron apps have fewer sketchy practices?
I'm not sure where you think I claimed this, but since you asked: I think sketchy practices are common throughout the consumer software industry, and I don't think there's anything about Electron that forces developers using it to implement sketchy practices.
If they do, that's on them. And since Electron is so common in consumer software these days, I'd caution you to remember that correlation does not imply causation.
Sure? I just wanted to make note of something I think is great and underrated about Electron. The outlier-y nature of that something is exactly why my next paragraph starts with "More broadly,".
> Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
> Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
VS Code and Discord are the big ones that come to mind as both widely used and widely preferred by their users.
I don't think the fact that it's possible to build shitty applications in Electron is very interesting, since that's true of every other UI framework. Neither does the fact that some people actively dislike e.g. VS Code contradict the fact that a great many people like it very much and independently choose to use it.
> Do you claim Electron apps have fewer sketchy practices?
I'm not sure where you think I claimed this, but since you asked: I think sketchy practices are common throughout the consumer software industry, and I don't think there's anything about Electron that forces developers using it to implement sketchy practices.
If they do, that's on them. And since Electron is so common in consumer software these days, I'd caution you to remember that correlation does not imply causation.
Electron app developers and extreme outliers bring it up all the time. It seems over rated to me.
Discord is free and has network effects. Lots of users complain about it. It competes with another Electron app mostly.
VS Code is free and has network effects. And high overhead and lots of custom UI are the norm for IDEs. I don't think anyone meant Electron is suitable for nothing.
Arq users didn't hate the Electron version because it was shittier than other Electron apps. They hated it because it was the normal level of shitty for Electron apps. Teams, Slack, and Spotify show many users doesn't mean happy users.
I didn't say you claimed Electron apps have fewer sketchy practices. But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
Discord is free and has network effects. Lots of users complain about it. It competes with another Electron app mostly.
VS Code is free and has network effects. And high overhead and lots of custom UI are the norm for IDEs. I don't think anyone meant Electron is suitable for nothing.
Arq users didn't hate the Electron version because it was shittier than other Electron apps. They hated it because it was the normal level of shitty for Electron apps. Teams, Slack, and Spotify show many users doesn't mean happy users.
I didn't say you claimed Electron apps have fewer sketchy practices. But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
> network effects
Unless you have a true captive market or some crazy sales-focused enterprise business, you can't get network effects without first achieving that critical mass of users more or less on your product's own merits, and if your software is shitty and/or pointless then you are not going to get there.
> Lots of users complain about it
Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
> But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
I'm not praising them for any such thing—I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms. I don't think Electron "apps" are on average better or worse, and if (looking at data) they did turn out to be better or worse in this regard then I would attribute that to the widespread adoption of Electron "apps" in certain market segments that tend toward abuse, rather than some inherent property of the framework that encourages it.
In other words, the baseline for modern consumer software is to abuse the user, and I don't believe there is some inherent property of Electron that encourages (or discourages) that trend.
Unless you have a true captive market or some crazy sales-focused enterprise business, you can't get network effects without first achieving that critical mass of users more or less on your product's own merits, and if your software is shitty and/or pointless then you are not going to get there.
> Lots of users complain about it
Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
> But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
I'm not praising them for any such thing—I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms. I don't think Electron "apps" are on average better or worse, and if (looking at data) they did turn out to be better or worse in this regard then I would attribute that to the widespread adoption of Electron "apps" in certain market segments that tend toward abuse, rather than some inherent property of the framework that encourages it.
In other words, the baseline for modern consumer software is to abuse the user, and I don't believe there is some inherent property of Electron that encourages (or discourages) that trend.
> you can't get network effects without first achieving that critical mass of users more or less on your product's own merits
No one said VS Code and Discord had no merits at all.
Discord's core users were gamers. People who can afford to run much more demanding software for fun. People who don't care about accessibility mostly. It's free like I mentioned. It competes with Slack mostly. Slack has the same problems mostly. And 1 of Slack's merits on its way to critical mass was compatibility with other apps.
VS Code's early merits were it was faster than Atom and free unlike Sublime Text.
> Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
A large fraction in my experience. "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize."[1]
> I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms.
Who said anything about abuse before you?
[1] https://news.ycombinator.com/newsguidelines.html
No one said VS Code and Discord had no merits at all.
Discord's core users were gamers. People who can afford to run much more demanding software for fun. People who don't care about accessibility mostly. It's free like I mentioned. It competes with Slack mostly. Slack has the same problems mostly. And 1 of Slack's merits on its way to critical mass was compatibility with other apps.
VS Code's early merits were it was faster than Atom and free unlike Sublime Text.
> Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
A large fraction in my experience. "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize."[1]
> I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms.
Who said anything about abuse before you?
[1] https://news.ycombinator.com/newsguidelines.html
> As a user, I don't care how easy it was for a developer to write the software
Most users only care about features which is directly connected to speed of software development.
You are speaking for all users but I'm certain that things you are saying are not true for example, users don't care if an app uses "unnecessary resources" unless it's fast enough. Users definitely do not care about UI conventions, most probably don't even know there are conventions. As for security, if you are using anything written in C or C++ you already lost there.
Most users only care about features which is directly connected to speed of software development.
You are speaking for all users but I'm certain that things you are saying are not true for example, users don't care if an app uses "unnecessary resources" unless it's fast enough. Users definitely do not care about UI conventions, most probably don't even know there are conventions. As for security, if you are using anything written in C or C++ you already lost there.
> Most users only care about features which is directly connected to speed of software development.
Considering that the average user refuses to wait longer than 2 seconds for a webpage to load, it's clear that people do care about more than just features. To dismiss that reality seems like a very "let them eat cake" attitude to take. Users care very much when an application makes their computer run sluggishly, and despite your disbelief, users actually do notice when an application looks different from their other applications, and they may or may not care about that. You say that users don't even know that there are UI conventions, but let me ask you this: if you created an application on a mac and moved the three buttons to close/minimize/maximize the application window from the upper left to the lower right, what percentage of users do you think would notice that UI convention change? I'm willing to bet about 100% of them. UI conventions are more than just a pretty facade, they provide hints about functionality using symbols and patterns that we've grown accustomed to, and don't even think about consciously. As for security, it's never a good look to point out how bad one thing is to justify another thing being bad also. Just because we've already lost doesn't mean we should give up.
Considering that the average user refuses to wait longer than 2 seconds for a webpage to load, it's clear that people do care about more than just features. To dismiss that reality seems like a very "let them eat cake" attitude to take. Users care very much when an application makes their computer run sluggishly, and despite your disbelief, users actually do notice when an application looks different from their other applications, and they may or may not care about that. You say that users don't even know that there are UI conventions, but let me ask you this: if you created an application on a mac and moved the three buttons to close/minimize/maximize the application window from the upper left to the lower right, what percentage of users do you think would notice that UI convention change? I'm willing to bet about 100% of them. UI conventions are more than just a pretty facade, they provide hints about functionality using symbols and patterns that we've grown accustomed to, and don't even think about consciously. As for security, it's never a good look to point out how bad one thing is to justify another thing being bad also. Just because we've already lost doesn't mean we should give up.
I think it is already about such basic, intuitive things like the order of buttons, is it [OK][Cancel] or [Cancel][OK]?
Will pressing Alt+F4 close the entire window? (See MS Teams, if you open the settings dialog and and to close it).
You can find probably dozens of such examples
Will pressing Alt+F4 close the entire window? (See MS Teams, if you open the settings dialog and and to close it).
You can find probably dozens of such examples
> As a user, I don't care how easy it was for a developer to write the software.
Users care transitively since there is a correlation between the amount of effort it takes to write a piece of software and the price required to sustain the development of said software. In my experience, many users care more about price than consistency or speed.
In cases where users are willing to pay more (such as with some professional software) you'll often find a lot more native applications.
Users care transitively since there is a correlation between the amount of effort it takes to write a piece of software and the price required to sustain the development of said software. In my experience, many users care more about price than consistency or speed.
In cases where users are willing to pay more (such as with some professional software) you'll often find a lot more native applications.
> I care that it doesn't use unnecessary resources.
I have never heard a non nerd say anything like that.
I have never heard a non nerd say anything like that.
You’ve never heard a non-nerd complain that their computer is sluggish or unresponsive? Or that they can’t figure out how to do something because the way they’ve always done it no longer works on some new app?
Funnily enough programmers care about resource usage yes. Why would the user care, it's not their job? You're glad that the person who engineers your car cares about resource usage I'm sure!
> You're glad that the person who engineers your car cares about resource usage I'm sure!
Is that necessarily true? Fuel economy is only where it is because of government regulation.
Is that necessarily true? Fuel economy is only where it is because of government regulation.
I think it's partly true at least yep. At least in the mind of any engineer worth their salt. Any problem is solved with tradeoffs though, eg. no regulatatory compulsion to achieve some mandated benchmark might lead to less of a focus on optimising something to cut costs. It's not a really a zero sum thing and is very context dependent I'd imagine.
People who aren't "nerds" don't know whether an application is using unnecessary resources. They just think their computer is slow and they need a new one.
[deleted]
> so many people fail to realize the success of Electron is in making desktop applications so much more approachable for those that are mainly front-end focused developers/hackers.
I don't know who failed to realize this. I rarely see comments refusing to admit that "building one electron app is easier than building 3 native apps for Windows/Mac/Linux". Most of people criticize the use of electron when megacorps undervalue user experience and make all sorts of excuses to use electron for the sake of cost saving in software development.
In many HN posts, as users who are technical enough to understand the impact of electron apps on their computers, I think the general idea is that native apps simply feel better and electron should not be encouraged.
I don't know who failed to realize this. I rarely see comments refusing to admit that "building one electron app is easier than building 3 native apps for Windows/Mac/Linux". Most of people criticize the use of electron when megacorps undervalue user experience and make all sorts of excuses to use electron for the sake of cost saving in software development.
In many HN posts, as users who are technical enough to understand the impact of electron apps on their computers, I think the general idea is that native apps simply feel better and electron should not be encouraged.
> At the end of the day, so many people fail to realize the success of Electron is in making desktop applications so much more approachable for those that are mainly front-end focused developers/hackers
Front end focused? It makes desktop apps accessible period. Someone inevitably mentions QT in these conversations. Find me a single successful QT based app. Electron is really the only cross platform option.
Front end focused? It makes desktop apps accessible period. Someone inevitably mentions QT in these conversations. Find me a single successful QT based app. Electron is really the only cross platform option.
> Someone inevitable mentions QT in these conversations. Find me a single successful QT based app.
Let me start with Telegram. The ux is universally liked (yes, even by the Mac crowd!)
> Front end focused? It makes desktop apps accessible period.
If someone just wanted to create cross platform applications quickly and push them upon people who don't have a choice (i.e. in an enterprise) there always used to be Java Swing as well.
Far easier than Electron, even approaching VB6-simplicity in GUI design, but with a sane language behind.
So, GP was right: It makes it easier for frontend devs.
Edit: yes, a lot.
Let me start with Telegram. The ux is universally liked (yes, even by the Mac crowd!)
> Front end focused? It makes desktop apps accessible period.
If someone just wanted to create cross platform applications quickly and push them upon people who don't have a choice (i.e. in an enterprise) there always used to be Java Swing as well.
Far easier than Electron, even approaching VB6-simplicity in GUI design, but with a sane language behind.
So, GP was right: It makes it easier for frontend devs.
Edit: yes, a lot.
>Find me a single successful QT based app
What?
https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
What a weird thing to say. Ableton, 3ds Max, Photoshop Elements, Google Earth, Mathematica... Qt probably has a longer list of success stories than any other cross platform UI toolkit.
What?
https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
What a weird thing to say. Ableton, 3ds Max, Photoshop Elements, Google Earth, Mathematica... Qt probably has a longer list of success stories than any other cross platform UI toolkit.
One might wonder if this comes up because qt is a good cross-platform toolkit... which is to say, it promptly fades into the background and you don't notice you're using it.
Musescore? Wireshark? Transmission? TeXStudio?
I don't want to be dismissive and those apps are definitely successful and good at what they do but they all look like they were designed in the early 2000s. And I'm pretty sure some were.
And that's good. Early 2000s had a consistent no-nonsense look made for real work, instead of this fad with every application trying to mimic a phone app or a startup landing page.
Good? I wouldn't say it's good, it's completely neutral and unrelated to morality. There is so much emotional and moral language that goes on in every discussion about electron that is just not relevant. People talk about "wasted resources", we aren't talking about plastic bags here. Electron apps aren't bitcoin or fossil fuels. If we were to take a look at things contributing to climate change electron would be irrelevant to the future of our planet.
No-nonsense? Why does software have to be no-nonsense? I'd prefer for software to be beautiful.
No-nonsense? Why does software have to be no-nonsense? I'd prefer for software to be beautiful.
I would say that there is an indirect consequence to wasteful resource usage: e-waste. I have a pile of old laptops and cell phones that are still perfectly functional hardware-wise but are basically useless because of the bloat of modern software. Sure, one electron app using hundreds of MB of RAM doesn't seem like that big of a deal, but when you run 6 of them and your machine only has 2 GB of RAM, now more than half your RAM is gone. And for what? A "beautiful" software experience? I'd take a functional and fast program over a "beautiful" one any day, no question.
Good means many things. Pleasing. Useful. Not just virtuous.
People complaining about resources mean the limited resources of their computers usually. But it does lead to wasted natural resources by making hardware obsolete faster. And wasted financial resources. And slow and inconsistent interfaces waste cognitive resources.
No nonsense means functional. Not ugly.
People complaining about resources mean the limited resources of their computers usually. But it does lead to wasted natural resources by making hardware obsolete faster. And wasted financial resources. And slow and inconsistent interfaces waste cognitive resources.
No nonsense means functional. Not ugly.
Keep in mind that there are maybe 100 or more users with electron apps for each cryptocurrency miner.
You just show how disconnected this discussion is from reality.
The goalpost was
> Find me a single successful QT based app.
And you've been provided a long list. Please don't move the goalpost.
> Find me a single successful QT based app.
And you've been provided a long list. Please don't move the goalpost.
If you are into 3d printing or design, Fusion 360 is another application you might encounter.
[deleted]
Because the worst abusers of Electron can afford to have dedicated teams for platforms.
Do you think Slack can't hire enough developers to build native platforms for Mac/Windows/Linux? Spotify? Discord?
I get it for small dev teams to build a cross platform app - but at a certain size, I don't understand why they can't go build native apps that aren't garbage.
Do you think Slack can't hire enough developers to build native platforms for Mac/Windows/Linux? Spotify? Discord?
I get it for small dev teams to build a cross platform app - but at a certain size, I don't understand why they can't go build native apps that aren't garbage.
I absolutely believe Slack can’t hire enough developers to build native platforms for Mac/Windows/Linux without hilariously extensive & expensive retraining.
Have you tried to hire developers with eg AppKit experience in the past 5 years? I have, twice. Neither were small companies. Both routes went electron because 95% of the native Mac developer pool works in Cupertino or China, and it’s a kiddy pool at that.
Have you tried to hire developers with eg AppKit experience in the past 5 years? I have, twice. Neither were small companies. Both routes went electron because 95% of the native Mac developer pool works in Cupertino or China, and it’s a kiddy pool at that.
:shrug:
They're a business so the question is not whether they technically have the cash available to do a thing, the question is whether doing that thing will yield the best return on investment compared to all the other things they could do.
Specifically, if Slack created new development teams to build native clients for Mac and Windows, would that effort eventually yield enough additional revenue to be worthwhile?
(Mind you, I don't know the answer to that question because I don't know Slack's financials, just pointing out that it's the real question governing whether they should use Electron.)
Specifically, if Slack created new development teams to build native clients for Mac and Windows, would that effort eventually yield enough additional revenue to be worthwhile?
(Mind you, I don't know the answer to that question because I don't know Slack's financials, just pointing out that it's the real question governing whether they should use Electron.)
Correct, but I'm also not saying that isn't true? They aren't mutually exclusive. Electron can still be good/useful for many people, and companies like Spotify/Discord/Slack can still get criticized for not hiring devs to make dedicated teams to build native apps. Just because some companies are choosing the technology in ways people don't like, doesn't make the technology itself bad. I hardly ever see anyone phrase it that way, though. It's only "ELECTRON BAD", not "SLACK IS BAD FOR USING ELECTRON."
It's a crutch so big companies can cheap out and ship subpar, lowest common denominator software that is bloated and slow.
It is good for small teams to be able to rapidly build cross platform apps that are good for MVP.
Slack is bad for using electron.
It is good for small teams to be able to rapidly build cross platform apps that are good for MVP.
Slack is bad for using electron.
Easier?
You can get a functional, graphical, Hello World! WinForms app running in like 10 seconds, ok, perhaps 20 seconds if your computer is slow
I can teach anybody with very basic programming skills to build something fancy in like 2 hours
No idea about Mac environment, but I guess it must be similar.
You can get a functional, graphical, Hello World! WinForms app running in like 10 seconds, ok, perhaps 20 seconds if your computer is slow
I can teach anybody with very basic programming skills to build something fancy in like 2 hours
No idea about Mac environment, but I guess it must be similar.
I’m not trying to ship hello world, I’m trying to ship a 100k line frontend with 60fps animations, PDF export, video and audio recording, and 3rd party html rendering. Try doing that with WinForms - the batteries are very much not included. Windows APIs are just a mess.
And if I succeed then my prize is what? I get to do it again on two other platforms?
And if I succeed then my prize is what? I get to do it again on two other platforms?
For some reason Windows apis are like hieroglyphs to me — coming from Mac Storyboard/ UIKit conventions…
Any advice?
Any advice?
The WinApi is too low level for most developers and situations.
Usually, you won't need to directly call any API function to build even a complex program.
.NET comes with everything included
Usually, you won't need to directly call any API function to build even a complex program.
.NET comes with everything included
> the success of Electron is in making desktop applications so much more approachable for those that are mainly front-end focused
Enabling more sht being shipped is not a badge of honor for a technology. Same goes for Visual Basic and Go, and for all those effort to dumb down software development when what the world needs is for quality* in software to be valued over quantity.
Enabling more sht being shipped is not a badge of honor for a technology. Same goes for Visual Basic and Go, and for all those effort to dumb down software development when what the world needs is for quality* in software to be valued over quantity.
Many people fail to realize that the user just does not care. Does the app work? Non nerds do not care that it's not elegant under the hood or that it eats memory and storage.
> Are there better ways to build native apps?
Depends. Is it a choice between using Electron or drowning in complexity and not shipping anything at all? An app is better than no app.
> Are there better ways to build native apps?
Depends. Is it a choice between using Electron or drowning in complexity and not shipping anything at all? An app is better than no app.
As one of those haters, I would have so much less of a problem with it if it wasn't a sledgehammer of a platform, and a resource hog. IMO it's just plain disrespectful to users to inflict them with this crap
Also, I'm pretty sure it's easier to fire of Visual Studio and start clicking-and-dragging controls onto a form in C#, and you get a better programming language with it to boot. It's just too bad WinForms/WPF aren't cross-platform...
Why are so many people slobbering over web developers and front end people any way?
Also, I'm pretty sure it's easier to fire of Visual Studio and start clicking-and-dragging controls onto a form in C#, and you get a better programming language with it to boot. It's just too bad WinForms/WPF aren't cross-platform...
Why are so many people slobbering over web developers and front end people any way?
99.999% of what Electron does may be achieved bundling your content into a single HTML file on your desktop. For the remaining .001% you are paying a ridiculous prize in terms of performance and space utilization.
Electron does not solve a "massive problem". It solves a very minor problem. But web developers are precisely the people who rather than studying the target's platform or studying their own platform (you probably don't need Electron) would just do the most nonsensical thing that comes to mind.
Electron does not solve a "massive problem". It solves a very minor problem. But web developers are precisely the people who rather than studying the target's platform or studying their own platform (you probably don't need Electron) would just do the most nonsensical thing that comes to mind.
> I always get a chuckle at all the hate Electron gets on HN, or in very technical communities.
Oh so true. It is such an indicator of lack of experience, too. Clearly they have never tried to support a cross-platform application, because Electron is utterly seamless from Win10 to Mac to Linux, even for USB and serial hardware. It has shaved literal man-years off development of our primary application at my company.
It's like haters are just admitting how junior they are.
Oh so true. It is such an indicator of lack of experience, too. Clearly they have never tried to support a cross-platform application, because Electron is utterly seamless from Win10 to Mac to Linux, even for USB and serial hardware. It has shaved literal man-years off development of our primary application at my company.
It's like haters are just admitting how junior they are.
> I always get a chuckle at all the hate Electron gets on HN, or in very technical communities
I, too, can tear down a straw man. But there are economical factors at play here and it's strange that you think that technical workers are oblivious to them.
Electron is compounding a problem that is not going away soon, or ever. People will not buy more expensive laptops to do their work (many simply can't). In the era of remote work the costs more laptops that can take the load that an Electron app introduces, is swallowed by employers -- and some don't want to do it.
This pressure is mounting, I assure you. Employers keep complaining there are no employees -- and what they actually mean is "we can't find people with laptops good enough for Slack and Discord and Excel and we don't want to buy them those". And I am not talking about programming jobs -- there it's usually very well understood that you have to buy the staff good machines (although I've been issued some pretty average machines but hey).
So employers keep screaming that they need more and better workers. The potential workers are like "eff this crap, I am not getting paid enough to buy a MacBook", plus many people have enough common sense not to reinvest their income in tech that company should have bought them in the first place.
How do you think this tug of war is going to end? By proclaiming "coding with Electron" (or PHP / WordPress since you mentioned them) is a basic human right? (lol) At one point something will give out and I can assure you it's not going to be society. It's going to be the tech companies who can't ever be bothered to invest a little bit in creating a cross-platform GUI toolkit.
So yeah, keep going on and on about how the technical people don't understand important things. From where I am standing it looks like that it's you who doesn't get it -- you are only bringing up ease of development, and there are much more factors in this situation.
I, too, can tear down a straw man. But there are economical factors at play here and it's strange that you think that technical workers are oblivious to them.
Electron is compounding a problem that is not going away soon, or ever. People will not buy more expensive laptops to do their work (many simply can't). In the era of remote work the costs more laptops that can take the load that an Electron app introduces, is swallowed by employers -- and some don't want to do it.
This pressure is mounting, I assure you. Employers keep complaining there are no employees -- and what they actually mean is "we can't find people with laptops good enough for Slack and Discord and Excel and we don't want to buy them those". And I am not talking about programming jobs -- there it's usually very well understood that you have to buy the staff good machines (although I've been issued some pretty average machines but hey).
So employers keep screaming that they need more and better workers. The potential workers are like "eff this crap, I am not getting paid enough to buy a MacBook", plus many people have enough common sense not to reinvest their income in tech that company should have bought them in the first place.
How do you think this tug of war is going to end? By proclaiming "coding with Electron" (or PHP / WordPress since you mentioned them) is a basic human right? (lol) At one point something will give out and I can assure you it's not going to be society. It's going to be the tech companies who can't ever be bothered to invest a little bit in creating a cross-platform GUI toolkit.
So yeah, keep going on and on about how the technical people don't understand important things. From where I am standing it looks like that it's you who doesn't get it -- you are only bringing up ease of development, and there are much more factors in this situation.
We get all that and we're saying that it comes with massive tradeoffs. The cost is massive resource footprints, inflexibility, sluggish performance, harder to reason about from a security or performance point of view because of the tower of software and abstraction you're building on top of. Many reasons.
I'm not saying it's not useful but I'm not falling over myself to argue we should all be using this stuff.
I'm not saying it's not useful but I'm not falling over myself to argue we should all be using this stuff.
True. I also get a chuckle, when people say housing, medicine, healthcare, daycare college is too expensive. Imagine if these good things simply did not exist. It would be much worse.
So whiner need to shut up already and buy a new computer annually where electron run normally.
So whiner need to shut up already and buy a new computer annually where electron run normally.
The anti-Electron crowd understands the reasons Electron has taken off just as you understand that there are benefits to native apps. It's just a matter of different priorities.
I don't think anybody is on a particularly high horse.
I don't think anybody is on a particularly high horse.
I only have so many gb of ram which means i am limited in the number of electron apps i can run on my system
Sorry, but no. Electron is the absolute worst piece of technology that I have come across in at least the last 20 years. It's not only that it is bloated, ridiculously resource hungry and terribly inconsistent because every program has it's own set of UI controls, but it's also just absolutely plain terrible to work with:
The APIs are a complete mess, half of them are not working properly, things constantly get broken between even minor version revisions, the documentation is usually outdated and incorrect and you need to plaster your code with OS-specific if-else statements all over the place because many of Electron's APIs behave differently on different OSes. The whole thing is just a complete disaster.
The APIs are a complete mess, half of them are not working properly, things constantly get broken between even minor version revisions, the documentation is usually outdated and incorrect and you need to plaster your code with OS-specific if-else statements all over the place because many of Electron's APIs behave differently on different OSes. The whole thing is just a complete disaster.
Agreed completely. In terms of the absolute worst piece of technology, there have been no applications that have even been shipped successfully with it, and every developer who uses it is probably encountering some form of s=Stockholm syndrome, or they're inexperienced enough as developers to not see the value of native applications.
Yes, just no.
Fair points on downsides and upsides of using Electron in development. But there's huge gaping hole in this logic: the points are given from the perspective of software developers, not software users. Users, given the choice between native and Electron, would overwhelmingly choose the former.
Speaking as a user I don’t care about your production costs and your programming knowledge. I care about my experiences. That’s why many Electron-based programs are marketed to managers as “solutions”, not to the actual end users.
As a macOS user let me add to the list of complaints mentioned by the author. Despite having fully functioning native iOS apps, some companies will not allow installing those directly on M1 based Macs, nor would they produce a rather simple ports for macOS. They will insist for you to use Electron-based client, like everyone else does. Teams, Slack, Discord. So I do agree that at least in this case Electron is evil.
Speaking as a user I don’t care about your production costs and your programming knowledge. I care about my experiences. That’s why many Electron-based programs are marketed to managers as “solutions”, not to the actual end users.
As a macOS user let me add to the list of complaints mentioned by the author. Despite having fully functioning native iOS apps, some companies will not allow installing those directly on M1 based Macs, nor would they produce a rather simple ports for macOS. They will insist for you to use Electron-based client, like everyone else does. Teams, Slack, Discord. So I do agree that at least in this case Electron is evil.
> Users, given the choice between native and Electron, would overwhelmingly choose the former.
I think tech people tend to assume this way too much without having any kind of evidence.
I actually prefer electron apps. They usually have a nice looking, modern design and are more consistent with web where I spend most of the time anyway. I doubt I am alone in this.
I think tech people tend to assume this way too much without having any kind of evidence.
I actually prefer electron apps. They usually have a nice looking, modern design and are more consistent with web where I spend most of the time anyway. I doubt I am alone in this.
> Users, given the choice between native and Electron, would overwhelmingly choose the former.
They might choose the former but then what? I would too, as a user, but in practice as the article mentions the alternatives aren't yet that great. So quite often the user can choose between the Electron app... or nothing. Many users accept the drawbacks and in fact it's mostly developers or technical people in general who complain about Electron. Most users don't even know about any of this.
They might choose the former but then what? I would too, as a user, but in practice as the article mentions the alternatives aren't yet that great. So quite often the user can choose between the Electron app... or nothing. Many users accept the drawbacks and in fact it's mostly developers or technical people in general who complain about Electron. Most users don't even know about any of this.
That's a great point. Choice is often between Electron or nothing. Why? Because even when they can afford it, software development corporations prefer to save money on the development. Even if they save peanuts, as in my example regarding apps on M1.
Obviously, this can exists only when there's no or minimum competition for the end users.
Obviously, this can exists only when there's no or minimum competition for the end users.
If a user had to choose between a native app and their top 10 most anticipated features, which would they choose?
As an end-user I love Electron because it allows products to evolve quicker and across all platforms. I would choose an Electron app (or if it runs in a browser, even better) over a native one.
Would you mind providing the sources for the claim that "would overhelmingly choose the former"? I'd love to read a report or study about that.
I made a couple of basic CRUD apps with it and it was pretty cool. I could build a React app and then build the electron app based on React's build folder and it just works.
I'm still working on learning C++/something like QT but I was able to deploy an app to Win/Lin/App.
For reference
Cross platform CRUD app (desktop, Android RN app) https://github.com/jdc-cunningham/cross-platform-app
Basic news slider app but it was transparent https://github.com/jdc-cunningham/frameless-electron-news-re...
I'm still working on learning C++/something like QT but I was able to deploy an app to Win/Lin/App.
For reference
Cross platform CRUD app (desktop, Android RN app) https://github.com/jdc-cunningham/cross-platform-app
Basic news slider app but it was transparent https://github.com/jdc-cunningham/frameless-electron-news-re...
A lot of people hate electron but frankly, it's the future of desktop applications and probably the future of mobile applications. The browser is currently the best implementation of a true cross platform framework. People complain about nebulous concepts like "bloat" but I think fragmentation across platforms is just as if not more harmful and bad. For mobile for example, I exclusively build native iOS apps because the ecosystem is superior and I simply do not have the bandwidth as an individual to maintain software for 3 unique platforms (web, iOS, and Android) so I just don't build Android apps because the android market is just not valuable.
Also as a user of many electron based apps, I currently use apple silicon native electron apps on my m1 macbook air and they are extremely snappy with only 16gb of ram (go download the canary version of discord which is compiled to apple silicon if you want to see the difference). If there is one entity that I'm truly angry at it is intel for completely mishandling and holding back the desktop processor ecosystem for the past decade (or longer).
Also as a user of many electron based apps, I currently use apple silicon native electron apps on my m1 macbook air and they are extremely snappy with only 16gb of ram (go download the canary version of discord which is compiled to apple silicon if you want to see the difference). If there is one entity that I'm truly angry at it is intel for completely mishandling and holding back the desktop processor ecosystem for the past decade (or longer).
> There might be a chance to dynamically link the LGPL version and avoid paying for the complete license, but that’s not always possible.
This is such FUD. The normal way to use Qt is dynamically linked, it is not difficult to use the LGPL version, you most likely don't use the premium features, and the restrictions are about using Qt to create embedded devices.
There are good reasons not to use Qt, like that many teams don't have the discipline to maintain a large C++ gui application. There are plenty of crap broken Qt apps because it is easy to screw up. There are few responsive electron apps because it is difficult to make fast.
Easier to make a mediocre app in electron -> classic worse is better in action.
This is such FUD. The normal way to use Qt is dynamically linked, it is not difficult to use the LGPL version, you most likely don't use the premium features, and the restrictions are about using Qt to create embedded devices.
There are good reasons not to use Qt, like that many teams don't have the discipline to maintain a large C++ gui application. There are plenty of crap broken Qt apps because it is easy to screw up. There are few responsive electron apps because it is difficult to make fast.
Easier to make a mediocre app in electron -> classic worse is better in action.
As of sizes ...
For Sciter Quark ( https://quark.sciter.com ) I've measured size of minimal "Hello World".
- Electron: 50 MB on disk, 200 MB of RAM and at least 2 processes running.
- QT: 5 MB (and 30 MB if + QtWebKit) and ~70 MB (200 MB if QtWebKit) of RAM.
- Sciter Quark (standalone Sciter executable): 5 MB on disk, 32 MB in RAM. That includes HTML/CSS UI, JS engine, NodeJS alike runtime.
Out of the box Sciter works on same platforms as Electron.
For Sciter Quark ( https://quark.sciter.com ) I've measured size of minimal "Hello World".
- Electron: 50 MB on disk, 200 MB of RAM and at least 2 processes running.
- QT: 5 MB (and 30 MB if + QtWebKit) and ~70 MB (200 MB if QtWebKit) of RAM.
- Sciter Quark (standalone Sciter executable): 5 MB on disk, 32 MB in RAM. That includes HTML/CSS UI, JS engine, NodeJS alike runtime.
Out of the box Sciter works on same platforms as Electron.
If it didn't say "Electron" in the title, I'd have thought he was describing Java. I don't see why Electron itself is a necessary evil - Java has been able to do all of this (just as badly) for over 20 years.
At least java is actually typesafe
And has a rather stable ecosystem. I've been doing front-end development for almost 10 years now and have started moving into more Java based projects recently and after living through the "flavor of the week" hellscape that is the JS community, I'll take Java's stability any day of the week. And I say this as someone who does actually love JavaScript.
I would definitely recommend the author look at Flutter again now. The comment there was back in July. The desktop experience has greatly improved. I have been building out a desktop-first set of components and it's been a real joy to work with.
Dart / Flutter lacks essential libraries: you can't do ssh / sftp on desktop for example.
As a side question, Do you parse JSON in your apps? If yes what package do you use? I tried built_value, I suspect the people that developed this really hate me personally ;)
As a side question, Do you parse JSON in your apps? If yes what package do you use? I tried built_value, I suspect the people that developed this really hate me personally ;)
For sure there are alot of things missing like you mention.
Another I find personally frustrating is so many libraries assume you are using the Material stack.
RE: JSON--I have used json_serializable in the past: https://pub.dev/packages/json_serializable. For my current project, I am using a data format I created call Traindown (https://traindown.com) and it's all local so I haven't hit JSON or SSH/SFTP issues personally.
Sorry I don't have a silver bullet suggestion for ya! I'm sure they don't hate you personally. Maybe all of us as collective "users" but not YOU! haha
Another I find personally frustrating is so many libraries assume you are using the Material stack.
RE: JSON--I have used json_serializable in the past: https://pub.dev/packages/json_serializable. For my current project, I am using a data format I created call Traindown (https://traindown.com) and it's all local so I haven't hit JSON or SSH/SFTP issues personally.
Sorry I don't have a silver bullet suggestion for ya! I'm sure they don't hate you personally. Maybe all of us as collective "users" but not YOU! haha
Sadly json_serializable seems to use code generation like built_value. I'll check it anyway, it can't be worse than built_value!
Thanks for the suggestion.
Thanks for the suggestion.
"Did you notice that most desktop apps that feel snappy don’t include any animation?"
well, this is patently false. https://developer.apple.com/design/human-interface-guideline...
well, this is patently false. https://developer.apple.com/design/human-interface-guideline...
He talks about short-lived applications, but on my Mac, it's rare that I launch a new application. I have most of my apps running all the time.
And I can't do that with any of the Electron apps that I use with the exception of Nota which just sits in the background not doing anything since it is a text editor.
If I keep Tabby open for too long it starts to spike the CPU and I suspect that this would be the case for any active Electron apps.
If I keep Tabby open for too long it starts to spike the CPU and I suspect that this would be the case for any active Electron apps.
The problem with Electron is that it shouldn't be necessary. We all already have web browsers installed. Why does each application need to bundle its own? Because browser vendors refuse to provide useful APIs?
I wish writers would stop using overdone intros like this
"Unless you’ve been living under a rock for the past 5 years..."
I see this sort of thing and I just want to stop reading. Only worse is
"This isn't your father's..."
"Unless you’ve been living under a rock for the past 5 years..."
I see this sort of thing and I just want to stop reading. Only worse is
"This isn't your father's..."
My major annoyance with Electron is every app shipping its own version of it, particularly on Linux where most distros tend to ship electron in the repositories. I'd really rather not have 5 different chromium versions - that are lacking security updates - on my system. I wish packagers were more aggressive about not bundling them.
Especially, most of these chat apps have functionally similar web/PWA apps. In those cases, I prefer to install them as desktop PWAs or use Chrome's "Create shortcut" feature to get them into my Dock/Taskbar.
One little bonus is that my browser extensions also apply to these installed PWAs. For example, the Todoist PWA now shows me the Toggle icon next to each task as an easy shortcut to start the time tracker.
In my case, I have these running as Chrome PWAs:
One little bonus is that my browser extensions also apply to these installed PWAs. For example, the Todoist PWA now shows me the Toggle icon next to each task as an easy shortcut to start the time tracker.
In my case, I have these running as Chrome PWAs:
- Raindrop.io
- Grammarly Editor
- Todoist
- Discord
- Element
- Whatsapp
- Twitter
- 1Password
- Obsidian
- VSCode
- Gitkraken
- Slack
- Spotify
I can't believe the 32bit Spotify thing, I have had it happened to me a few times where it exceeded that 4GB threshold and I had to restart it.
It is interesting that you say that. This is fact already exists. An unbundled version of electron, that can be used by multiple applications, is called a web browser. Applications using it are called websites (or PWAs if you must)
Unfortunately, certain applications are gimped if you don't use the electron version. A notable example of this for me is Discord where push-to-talk doesn't function in the web version due to API limitations.
Another app I use that has this problem is Spotify. While it isn't electron, it is using CEF (chromium embedded framework) and can be dynamically linked to a distro one with some effort. Using the web version means I dont have my music available offline for listening.
Another app I use that has this problem is Spotify. While it isn't electron, it is using CEF (chromium embedded framework) and can be dynamically linked to a distro one with some effort. Using the web version means I dont have my music available offline for listening.
I love how he takes a huge, highly custom (custom widgets and things everywhere) and unoptimized Qt application (Telegram Desktop), that as of late has started shipping with a version of WebKit for some functionality related to payments, without mentioning it's unreasonably huge for a Qt application. Apps like qbittorrent are a third of its size, and this is not mentioning that platforms like linux have Qt installed as a system-wide library, making the whole size comparison moot. (you cannot install and use a system-wide version of electron for most electron apps).
He also fails to consider that there's bindings for all native platform UIs for a ton of languages. You could write gtk code in javascript or C# if you wanted, and this is especially relevant when mentioning WxWidgets. You don't have to write your business logic in C++ these days.
He also fails to consider that there's bindings for all native platform UIs for a ton of languages. You could write gtk code in javascript or C# if you wanted, and this is especially relevant when mentioning WxWidgets. You don't have to write your business logic in C++ these days.
As an amateur programmer, it really does feel like Electron would be one of those things that's absolutely garbage except for literally everything else which is even worse.
I am able to do and automate all sorts of very cool and amazing things that wow friends and family, mostly through bash as well as some Python.
And then there's GUIs. It makes no sense that they are this hard to program. If it's the tiniest bit more complex than something that can be done with Zenity, it's probably not going to happen. Nothing comes close to being as easy as some web-type GUI, which aren't themselves that easy.
I am able to do and automate all sorts of very cool and amazing things that wow friends and family, mostly through bash as well as some Python.
And then there's GUIs. It makes no sense that they are this hard to program. If it's the tiniest bit more complex than something that can be done with Zenity, it's probably not going to happen. Nothing comes close to being as easy as some web-type GUI, which aren't themselves that easy.
Furniture made by a very skilled craftsperson is often beautifully finished even on the surfaces you don't normally see. Quick and easy may often be the best way to do something, but sometimes you end up doing things the hard way because you care about making the best thing you can.
This is a great point. I have a few pieces of furniture hand-made by skilled craftspeople and they're lovely.
But most of my furniture still comes from Ikea and the like because it costs at least an order of magnitude less to build and ship.
Electron will continue to grow in popularity for similar reasons.
But most of my furniture still comes from Ikea and the like because it costs at least an order of magnitude less to build and ship.
Electron will continue to grow in popularity for similar reasons.
Electron will continue to grow for sure.
There is, however, a big difference in the effects of scale.
The marginal cost for another piece of high quality (or even low quality) furniture is high.
The marginal cost for one more copy of Microsoft Teams is almost nothing no matter which technology Microsoft uses to make it.
There is, however, a big difference in the effects of scale.
The marginal cost for another piece of high quality (or even low quality) furniture is high.
The marginal cost for one more copy of Microsoft Teams is almost nothing no matter which technology Microsoft uses to make it.
But what about productivity lost by not using something better like Discord sorry couldn't help it
I don't buy this argument for software in the least; it presumes this zero-sum tradeoff between "effort to build" and "quality of outcome" that I just don't believe actually necessarily exists in a medium of infinite reproduceability like software.
In my experience what's really happening here is the "hypercard" problem. Namely, there is a tendency, perhaps subconscious, for programmers (or perhaps meta-programmers) to NOT make "tools for building" too easy because they're scared of writing themselves out of a job or a market -- or they're trying to create or retain some exclusivity. I'm not necessarily saying this is always evil, but it's always a thing to consider and is likely happening all the time.
In my experience what's really happening here is the "hypercard" problem. Namely, there is a tendency, perhaps subconscious, for programmers (or perhaps meta-programmers) to NOT make "tools for building" too easy because they're scared of writing themselves out of a job or a market -- or they're trying to create or retain some exclusivity. I'm not necessarily saying this is always evil, but it's always a thing to consider and is likely happening all the time.
Electron exists because cross platform native desktop development is a terrible experience, and many developers (some who even frequent HN!) prefer going with the easy and fast route (due to a variety of pressures) over the native route.
It’s the same reason why people gravitate towards MIT and Apache licenses over things like lGPL. It doesn’t require a developer to think as hard if they are in violation of the license with their project. Though plenty of developers still screw this up even with those licenses (see the devs of sonic colors ultimate and the violation of the Godot Engine’s MIT license)
It’s the same reason why people gravitate towards MIT and Apache licenses over things like lGPL. It doesn’t require a developer to think as hard if they are in violation of the license with their project. Though plenty of developers still screw this up even with those licenses (see the devs of sonic colors ultimate and the violation of the Godot Engine’s MIT license)
Great article. It starts by setting forth a good basis, that I think covers almost all of the primary Electron complaints. There's a very outraged comment decrying these plus also a difficult messy dev story[1], but generally I think the article starts by outlining the criticism fairly well.
After enumerating the problems with Electron, the article outlines a wide range of alternatives. This is such a great exploration! I love love love for example the idea of localhost http servers. The article discusses them! I feel differently than the author, but great & honest review:
> I know this is highly subjective, but I really appreciate having a separate window for each application, along with good OS integrations such as native menu bars and dialogs.
Covering up & coming webview embedders like Tauri really won me over. The author showed a deep & expansive knowledge of up & coming alternatives, that still make use of the wonderful great web platform so many folks know & enjoy:
> Many projects are trying to overcome Electron’s drawbacks using this approach, such as Electrino, webview, Tauri, and many more.
And it highlights that these alternatives still lack a lot of standard native integration, that it's not yet baked in anywhere near as well as Electron does:
> You see, if you choose this approach, you will need to do a lot of “plumbing” yourself, as you don’t have access to any of the convenient APIs exposed by Electron. Do you want a menu bar? You have to write the low-level bindings yourself, often multiple times depending on the number of platforms you are looking to support.
I'm hoping some of these up & comers continue to advance, continue to make inroads. Electron has been 100% a magic bullet for countless great apps, big and small. Is it 100% painless? No. But it's pretty damned good, and it marries good UX development to the power & capabilities of server-side technology, in pretty excellently & unique cross-platform way, and that's a really great combination.
[1] https://news.ycombinator.com/item?id=29420450
After enumerating the problems with Electron, the article outlines a wide range of alternatives. This is such a great exploration! I love love love for example the idea of localhost http servers. The article discusses them! I feel differently than the author, but great & honest review:
> I know this is highly subjective, but I really appreciate having a separate window for each application, along with good OS integrations such as native menu bars and dialogs.
Covering up & coming webview embedders like Tauri really won me over. The author showed a deep & expansive knowledge of up & coming alternatives, that still make use of the wonderful great web platform so many folks know & enjoy:
> Many projects are trying to overcome Electron’s drawbacks using this approach, such as Electrino, webview, Tauri, and many more.
And it highlights that these alternatives still lack a lot of standard native integration, that it's not yet baked in anywhere near as well as Electron does:
> You see, if you choose this approach, you will need to do a lot of “plumbing” yourself, as you don’t have access to any of the convenient APIs exposed by Electron. Do you want a menu bar? You have to write the low-level bindings yourself, often multiple times depending on the number of platforms you are looking to support.
I'm hoping some of these up & comers continue to advance, continue to make inroads. Electron has been 100% a magic bullet for countless great apps, big and small. Is it 100% painless? No. But it's pretty damned good, and it marries good UX development to the power & capabilities of server-side technology, in pretty excellently & unique cross-platform way, and that's a really great combination.
[1] https://news.ycombinator.com/item?id=29420450
Most software today is bad, Electron is worse. Tolerating such concepts leads to mainstream software abominations like the Epic Games Launcher. In a world ever so dependent on technology.
This. Good software can be made even when using Electron - just take a look at Visual Studio Code. It pains me during my work as a software developer how many times we have to cut edges, because companies want to minimize their expenses (and developers get in a habit of doing so even when they don’t have to).
> Code once, deploy on Windows, macOS, and Linux
This is a major pain point of electron. Sure you can save some costs, as you only have to write one GUI, but the result is always really bad.
The only electron application that is even remotely usable is VSCodium. MS Teams is a slow dumpsterfire and a mess of UI (Why do they even implement own "Close Window" buttons?)
Furthermore it is simply annoying if an application does not look like the rest of my desktop
This is a major pain point of electron. Sure you can save some costs, as you only have to write one GUI, but the result is always really bad.
The only electron application that is even remotely usable is VSCodium. MS Teams is a slow dumpsterfire and a mess of UI (Why do they even implement own "Close Window" buttons?)
Furthermore it is simply annoying if an application does not look like the rest of my desktop
I worked on a cross-platform C# application that ran on both Mac and Windows. I really liked the language and most of the experience. The biggest problem was that the C# toolchain was very glitchy on Mac. (I did have to write shims in C so that Objective C could call into C#.)
In our case, C# was the right choice because of what the application did. (There was no way we could be web based.) For many applications, Electron (or similar) is the right choice.
We did have two native UIs: WPF and Cocoa. The Mac developers eventually figured out how to use C# models and controllers from Objective C.
Again, I would only recommend such an approach if you need close integration with the UI. We had tray/taskbar icons, filesystem watchers, drivers... Things that really don't make sense to do in something like Electron.
I'd also like to point out one advantage of Electron, if you can do it: Garbage collection. I personally find memory management in C/C++/Rust a chore, so if Electron is "good enough," you get all the advantages of V8's garbage collector.
In our case, C# was the right choice because of what the application did. (There was no way we could be web based.) For many applications, Electron (or similar) is the right choice.
We did have two native UIs: WPF and Cocoa. The Mac developers eventually figured out how to use C# models and controllers from Objective C.
Again, I would only recommend such an approach if you need close integration with the UI. We had tray/taskbar icons, filesystem watchers, drivers... Things that really don't make sense to do in something like Electron.
I'd also like to point out one advantage of Electron, if you can do it: Garbage collection. I personally find memory management in C/C++/Rust a chore, so if Electron is "good enough," you get all the advantages of V8's garbage collector.
Hopefully, we'll start more commonly getting the benefits of Electron in a leaner package as with Tauri[1] or Wails[2]
[1] https://tauri.studio/en/ [2] https://wails.io
[1] https://tauri.studio/en/ [2] https://wails.io
Some sample experiences:
At my workplace I'm using Electron to build a data heavy application (bill of material, 3D visualization). Performance is spectacular, especially 3D visualization of very large models (threejs). I'm using agGrid for the tables. Also extremly fast and powerful.
The users don't care at all that the app is 93 MB and takes 3-5 seconds to start. They love the app for the performance, features and ease of use. I consider Electron as a great success in this case.
I'm using VS Code, Obsidian and Todoist daily. I love them and don't care that they're Electron apps.
At my workplace I'm using Electron to build a data heavy application (bill of material, 3D visualization). Performance is spectacular, especially 3D visualization of very large models (threejs). I'm using agGrid for the tables. Also extremly fast and powerful.
The users don't care at all that the app is 93 MB and takes 3-5 seconds to start. They love the app for the performance, features and ease of use. I consider Electron as a great success in this case.
I'm using VS Code, Obsidian and Todoist daily. I love them and don't care that they're Electron apps.
I get the feeling that we could all just copy and paste our comments from the last Electron post.
I doubt anyone is going to chance their mind about it. It is the jQuery of cross-platform development.
I doubt anyone is going to chance their mind about it. It is the jQuery of cross-platform development.
I think the hidden reason many hate Electron is because they are forced to use software written in Electron by the choice of their companies. For example I'm forced to use Teams at work but I don't even have Teams on my personal laptop.
I would give soo much for a native GTK MS Teams client
Simply, a lot of software that makes people's lives easier wouldn't exist without Electron. So yes, Electron is good.
The same amount of effort spent in Electron wouldn't get you a better native app. It would more likely get you no app.
The same amount of effort spent in Electron wouldn't get you a better native app. It would more likely get you no app.
Unless you’ve been living under a rock for
the past 5 years,chances are you have used
an Electron-based application at least once
in your life.
I have never used an Electron app because all my needs are covered by termial applications, Firefox, LibreOffice and Gimp.
Which rock do I live under?
> What does it mean to "live under a rock"?
"Living under a rock" is an idiom used to describe one who is/has been cut off from the mainstream.
> Which rock do I live under?
The rock of literally never having used any of the ubiquitous communications tools built on Electron (Discord, Slack, Teams off the top of my head), or any of the very popular^[1] code editors built on it, or any of the countless other applications that use it.
I'm sure you get your work done just fine, and this is not a value judgment. It's just an observation that, at least in the set of people likely to read (or "read") this article, you are a member of a (presumably) small and ever-shrinking class. Electron is everywhere.
^[1] https://insights.stackoverflow.com/survey/2021#section-most-...
"Living under a rock" is an idiom used to describe one who is/has been cut off from the mainstream.
> Which rock do I live under?
The rock of literally never having used any of the ubiquitous communications tools built on Electron (Discord, Slack, Teams off the top of my head), or any of the very popular^[1] code editors built on it, or any of the countless other applications that use it.
I'm sure you get your work done just fine, and this is not a value judgment. It's just an observation that, at least in the set of people likely to read (or "read") this article, you are a member of a (presumably) small and ever-shrinking class. Electron is everywhere.
^[1] https://insights.stackoverflow.com/survey/2021#section-most-...
Some common and widely used electron applications are VSCode, Spotify, and Slack. I think Microsoft teams might also be electron based but I'm not sure. There are many more as well.
Isn't Spotify for Linux in C++ with GTK?
$ ldd /usr/bin/spotify | grep gtk
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f06b545d000)
I believe Teams just switched to Edge WebView instead of Electron. The point remains that native applications are starting to only be specialty applications like games, CAD/CAM, Creative Suite, etc where you need a lot of access to compute power.
I think we will see more web based versions of those speciality applications. There is already an Autocad running in browser.
You know, I forgot about WebGPU. If you have GPU Compute support I could see a full featured web version being technically possible. AutoCAD Web is really limited compared to the native application.
The Web is just fulfilling Java's 'Write Once Run Everywhere' promise.
The Web is just fulfilling Java's 'Write Once Run Everywhere' promise.
Sure. But I don't use those.
Have you used any of them "at least once in your life"?
Not the OP, but no, I have not. Nor do I intend to. Ever.
I don't have a dog in this fight but I think it is safe to say it is rare to never have used it, if only out of curiosity.
No
> Which rock do I live under?
Linux, apparently.
Linux, apparently.
None of the listed software is exclusive to Linux.
Exactly, a most electron apps work on the browser or have good non electron alternative
I have tried some but that's about it
I have tried some but that's about it
Keyword being "chances".
The main computing constraint isn't the hardware that the software is running on, but is instead the wetware that creates the software
npm install --save electron
npm install --save electron
I have played around with Electron in the past for fun "nothing" projects, and also tried to understand what many on HN would want as the "correct" way to build native apps. It's an indescribable difference how much easier Electron is to get up and running from my experience, as someone who primarily does front-end work.
Are there better ways to build native apps? Of course. Electron still solves a massive problem for many developers and end-users that I don't understand why so many here get on their high horse refusing to acknowledge. It's similar to PHP hate to me. Of course there are better languages to use, but things like WordPress using PHP are so much more approachable for so many developers.