I prefer running web apps in my standard browser over the electron apps 100% of the time, and one of the reasons is that I, as the end user, am empowered with choice that way that electron denies me. And the general user experience is generally better, with better integration in my desktop (which you might not expect from a web app, but it is true because my browser is better integrated than their browser) and controls the other one might deny me.
It hasn’t been much of a compatibility problem either, everything ive wanted to use has worked fine, so I don’t buy the line about needing separate downloads for version control either.
uBlock is also very helpful for thwarting some of the dark patterns in web app design. For example, it is trivial to block the “recommendations” sections on YouTube to avoid falling in to rabbit holes there.
As another example, I’ve personally blocked almost the entire “home page” of GitHub with its mix of useless eye-grabbing information and AI crap. Ideally I’d just not use GitHub, but the network effect is strong and being able to exert my will on the interface to some extent makes it more tolerable for now.
Indeed, and this is a legit reason for users to prefer the web apps… but if you use their browser instead of your browser, you throw those sandbox benefits away. (as well as the actually kinda nice ui customization options you have in the web world)
Sure, but since Electron apps are usually just wrapped web apps anyway, might as well use them in a browser where you get to block unwanted stuff. At least if that’s a concern for you.
It’s a bit surreal to me that a guy who maintains electron and works at notion tries to tell me that I’m wrong about electron while their app is so broken that I can’t even log in in it because the input fields don’t work for me.
It exists in a lot of cases to get past gatekeepers at larger companies. Buyers in these organizations use checklists for product comparison, so the lack of a desktop app can rule a product out of contention. A PWA would likely suffice, but these get surprisingly negative feedback from large organizations where the people with the control and giving the feedback are somewhat distant from the usage.
Developers respond by doing minimal work to take advantage of the desktop. The developers know they could do deeper desktop integration, but product management only want to check the box and avoid divergence from the web experience (along with a dose of MVP-itis). End users could get more value from an otherwise cruddy Electron app, if it exploited helpful desktop integrations.
Clearly, it’d be better to have a native app that exploits the desktop, but this is unlikely to happen when the customer is checking boxes (but not suggesting solid integration use cases) and PMs are overly focused on MVPs (with limited vision and experience with how desktop apps can shine.) It’s funny how these things change when it comes to native mobile apps because cross-platform apps can get dinged on enterprise checklists while PMs are willing to commit heavily.
This does not seem to engage with the actual underlying disagreement, which is the tension between making economic sense and making technical sense.
As noted in the article, Electron is a very successful technology, it solves an existing issue, but I believe it is an economic issue that is being solved, not a technical one. The software industry is nowadays highly biased towards web technologies (because most software being written are written as web applications) and we have loads of developers familiar with that, Electron makes it possible to take existing web developers and have them write desktop applications with minimal training, this is a huge gain for companies compared to hiring native developers and dealing with multiple platforms.
When people complain about Electron, they usually do so on technical grounds, not economic ones. Using HTML and Javascript for the web was an (happy ?) accident, at least the way we end up using them is pretty far from the original use case they were designed for, but we do not really have any alternative. For native applications, its hard to argue web technologies are appropriate from a purely technical standpoint, they require an enormous amount of extra code on top of the operating system (a web renderer and a javascript engine), require heroic efforts to be made acceptably fast, and lack easy access to operating system services (which is usually the reason for a native app nowadays).
I find it notable that Electron seems to be mostly used for company developed software, where economic pressure is strong, and seldomly used for spare-time open source software, where economic pressure is much less present.
To expand a little on the economic argument, it’s not just a glut of web developers, but we now have to make apps that work on Windows, Android, iOS, and the web (and if you can get it working on a few popular Linux distros, that’s gravy). Maintaining a different app for every platform is costly, and the web largely solves this compatibility problem.
I find it notable that Electron seems to be mostly used for company developed software, where economic pressure is strong, and seldomly used for spare-time open source software, where economic pressure is much less present.
I do too, and it makes a certain kind of sense to me. When I’m scratching my own itch in my spare time, I don’t really ever need native and web. If web makes sense for whatever gadget I’m building, I just make a web site. If I need lots of local native functionality, I’ll go native, frequently with wxWidgets. But if a web stack is well-suited for what I’m building, just letting people point a browser at it is generally good enough for spare time projects for me.
The main time I’ve been tempted in a desktop-y direction for my web things is when I’ve had a django app that I wanted to also use offline. For my own use, starting it on the command line and pointing at localhost suits me. But I’ve got one now that I’d like to share with a few friends who decidedly won’t be able to git clone and make runserver. They’re not dumb, but telling them to open a terminal is a complete non-starter. And they’ll want to use it in an environment where they won’t have wifi.
For that one, I’m considering building a local app with tauri. It seems lighter than electron, seems to have some facilities to let you spawn a python server, and would give a download-and-double-click experience to these. My other option is to learn how to use ServiceWorkers to build a PWA, but I haven’t enjoyed exploring that so far, I think I’d have to tell the Mac user to install it using Firefox instead of their normal Safari browser, and I don’t have a good read on how well PWAs work on Mac even with Firefox.
Since most of this comment is negative, I’ll preface it by saying I appreciate you engaging with criticism about the project, and don’t think Electron is inherently bad.
I do avoid it when I can because of bundle size, RAM usage, and security*.
That being said, I think the misconceptions you try to address are misrepresented.
Electron pits JavaScript versus native code
However, the entire point of Electron is that you can pair your web app with any native code you want to write—specifically with C++, Objective-C, or Rust. Some apps (like mine) only reach for native code when I want to use native UI components.
Yes it’s a possibility, but most apps don’t do it. Most apps use Electron as a shell for their website, with some extra hooks to look a tad native.
Web apps are bad
The argument: All native apps are better than all web apps. Any given web app would be better as a native app.
The more nuanced argument is that given a small amount of devs and time, it’s likely easier to get a Web/Electron app out of the door. Especially with the web eating the world as you put it. Given more time, or more/different devs, then I believe native leads to a better UX (let me say “in most cases” explicitly, this is not an absolute statement).
And nowadays companies expect to invest much less in “apps,” combined with less investment in native toolkits, it tips that scale further.
However, assertions that web apps are inherently inferior and that web apps are only written by people who couldn’t bother to learn native technologies is at best ignorant and at worst lacking empathy with the requirements and constraints, and in turn with end users empowered with choice.
I agree some people are assholes about it, but again, this is presenting things in absolute terms.
Also, claiming “empowered with choice” doesn’t sit well with me. There’s heavy network effects at play both with using official Electron apps compared to third party native ones, and developer mindshare is already focused on Web things. Both of those often make user choice moot: I have to deal with Electron because it’s the only functional choice.
Operating System WebViews are more performant
That’s not a claim I’ve heard much. At least for me, it’s mostly about reducing dependency duplication and attack surface.
Bundle size matters
Users, both in the consumer and business space, do not care. One hour of Netflix at 4K is roughly 7 GB, a typical Call of Duty update regularly clocks in more than 300 GB.
Bandwidth is temporary. Disk space is forever.
Electron should be called… Dark Matter.
Defeating Electron
Electron isn’t here to compete with anyone. It’s a free open source community effort filling a gap.
I think this also fails to acknowledge Electron’s status and position. It’s not a tiny side project. At that scale, you, IMO, need to be conscious about impact on the ecosystem. You don’t need to help out others, but at least acknowledge your project is not on an even playing field anymore.
* On the new Why Electron docs it gives security as a reason to use it. But in my experience, Electron apps don’t get updates as often as my browser, so that possibility is not realized.
I’m not sure the author realises why companies use Electron. It’s not economically doable for most companies to write one decent native app, let alone three. Electron is their way around that.
With that kind of economic incentive, none of the arguments listed anywhere are relevant.
Your bandwidth cap is temporary, but less so, if you’re unlucky enough to live somewhere rural enough that the internet sucks. This is better than a few years ago I believe, but certainly not solved. That being said…
Electron should be called… Dark Matter.
I like this idea a lot. After all, Electron apps do all contain black holes (or at least, something comparable…).
I have to react to this one and I don’t know how to say that nicely.
People totally lost track about how a good application is supposed to be.
Electron apps are slooow to load like a molasse on a 64GB multi GB/s NVME 32 core workstation, they have weird desktop UX, drag and drop works half of the time, Wayland support is basically the worst of all, they don’t play well with the KDE app bar most of the time.
Slack? Horrible, so slow.
Zoom? Absolute garbage good luck sharing any screen with it, graphic glitches everywhere.
Discord? Wants to self update, game over… When it is a glorified webpage!?
I feel insulted as a user: Laptop battery life ? Who cares! Hogging the resources from stuff you actually wants to do? Not my problem!
Now please compare that to way way more complex applications like inkscape, kdenlive, blender, krita, etc… they insta load, their UX is coherent, copy paste works, they are responsive, they support Wayland very well and they don’t duplicate an incompatible web browser runtime install for each one.
Seriously waiting 5s for a stupid chat application to load with 4GB/s of IO, combined 100GHz of super scalar CPU is just outrageous PERIOD. I still remember Borland pascal load and compile 100k lines of code in less time on a 486 at 66Mhz, this is completely absurd.
It feels like so many components are web based I thought it was an electron app :P.
I mean the name of the process is literally “ZoomWebviewHost” :shrug:
It kind of just converges to the same thing…
People totally lost track about how a good application is supposed to be.
100% agree with your point. Even with the valid objection from @wezm about Zoom, I still think you’re right.
It feels to me like there are multiple non-overlapping definitions of what constitutes a “good app”.
An app may be a good app on a phone, but bad on a tablet. It may be good on a tablet in landscape and bad in portrait. It could be good on both tablet and phone but still terrible on a desktop PC or laptop.
Computers are not phones. Phones are not computers except in a trivial and irrelevant dictionary-definition sort of sense. A good UI on a keyboardless device can be a very bad one on a keyboard-driven device and vice versa.
I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.
WHY this is the case is a respactable topic for sure, but since I already know the outcome I’m more interested in other topics.
I believe in your perception, but I wonder how people determine this sort of thing.
It seems like an availability heuristic: if you notice an app is bad, and discover it’s made in Electron, you remember that. But if an app isn’t bad, do you even check how it was built?
Sort of like how you can always tell bad plastic surgery, but not necessarily good plastic surgery.
On macOS, there has been a shift in the past decade from noticing apps have poor UIs and seeing that they are Qt, to seeing that they are Electron. One of the problems with the web is that there’s no standard rich text edit control. Cocoa’s NSTextView is incredibly powerful, it basically includes an entire typesetting engine with hooks exposed to everything. Things like drag-and-drop, undo, consistent keyboard shortcuts, and so on all work for free if you use it. Any app that doesn’t use it, but exposes a way of editing text, sticks out. Keyboard navigation will work almost how you’re used to, for example. In Electron and the web, everyone has to use a non-standard text view if they want anything more than plain text. And a lot of apps implement their own rather than reusing a single common one, so there isn’t even consistency between Electron apps.
In Electron and the web, everyone has to use a non-standard text view if they want anything more than plain text. And a lot of apps implement their own rather than reusing a single common one, so there isn’t even consistency between Electron apps.
The is probably the best criticism of Electron apps in this thread that’s not just knee-jerk / dogpiling. It’s absolutely valid and even for non-Electron web apps it’s a real problem. I work at a company that had it’s own collaborative rich-text editor based on OT, and it is both a tonne of work to maintain and extend, and also subtly (and sometimes not-so-subtly) different to every other rich text editor out there.
I’ve been using Obsidian a fair bit lately. I’m pretty sure it’s Electron-based but on OSX that still means that most of the editing shortcuts work properly. Ctrl-a and ctrl-d for start and end of line, ctrl-n and ctrl-p for next and previous line, etc. These are all Emacs hotkeys that ended up in OSX via NeXT. Want to know what the most frustrating thing has been with using Obsidian cross platform? Those Emacs hotkeys that all work on OSX don’t work on the Linux version… on the Linux version they do things like Select All or Print. Every time I switch from my Mac laptop to my Linux desktop I end up frustrated from all of the crap that happens when I use my muscle memory hotkeys.
This is something that annoys me about Linux desktops. OPENSTEP and CDE, and even EMACS, supported a meta key so that control could be control and invoking shortcuts was a different key. Both KDE and GNOME were first released after Windows keys were ubiquitous on PC keyboards that could have been used as a command / meta key, yet they copied the Windows model for shortcuts.
More than 50% of the reason I use a Mac is that copy and paste in the terminal are the same shortcut as every other app.
More than 50% of the reason I use a Mac is that copy and paste in the terminal are the same shortcut as every other app.
You mean middle click, right? I say that in jest, but anytime I’m on a non-Linux platform, I find myself highlighting and middle clicking, then realizing that just doesn’t work here and sadly finding the actual clipboard keys.
X11’s select buffer always annoyed me because it conflates two actions. Selecting and copying are distinct operations and need to be to support operations like select and paste to overwrite. Implicitly doing a copy-like operation is annoying and hits a bunch of common corner cases. If I have something selected in two apps, switching between them and then pasting in a third makes it unclear which thing I’ll paste (some apps share selection to the select buffer when it’s selected, some do it when they are active and a selection exists, it’s not clear which is ‘correct’ behaviour).
The select buffer exists to avoid needing a clipboard server that holds a copy of the object being transferred, but drag and drop (which worked reliably on OPENSTEP and was always a pain on X11) is a better interaction model for that. And, when designed properly, has better support for content negotiation, than the select buffer in X11. For example, on macOS I can drag a file from the Finder to the Terminal and the Terminal will negotiate the path of the file as the type (and know that it’s a file, not a string, so properly escape it) and insert it into the shell. If you select a file in any X11 file manager, does this work when you middle click in an X11 terminal? Without massive hacks and tight coupling?
If you select a file in any X11 file manager, does this work when you middle click in an X11 terminal?
There’s no reason why it shouldn’t on the X level - middle clicks to the same content negotiation as any other clipboard or drag and drop operation (in fact, it is literally the same, asking for the TARGETS property, then calling XConvertSelection with the format you want, the only difference is that second argument to XConvertSelection - PRIMARY, CLIPBOARD, or XdndSelection).
If it doesn’t work, it is probably just because the terminal doesn’t try. Which I’d understand; my terminal unconditionally asks for strings too, because knowing what is going on in the running application is a bit of a pain. The terminal doesn’t know if you are at a shell prompt or a text editor or a Python interpreter unless you hack up those programs to inform it somehow. (This is something I was fairly impressed with on the Mac, those things do generally work, but I don’t know how. My guess is massive hacks and tight coupling between their shell extensions and their terminal extensions.)
need to be to support operations like select and paste to overwrite
Eh, I made it work in my library! I like middle click a lot and frequently double click one thing to select it, then double click followed by middle click in another to replace its content. Heck, that’s how I do web links a great many times (I can’t say a majority, but several times a day). Made me a little angry that it wouldn’t work in the mainstream programs, so I made it work in mind.
It is a bit hacky though: it does an automatic string copy of the selection into an internal buffer of the application when replacing the selection. Upon pasting, if it is asked to paste the current selection over itself, it instead use that saved buffer. Theoretically pure? Nah. Practically perfect? Yup. Works For Me.
If I have something selected in two apps, switching between them and then pasting in a third makes it unclear which thing I’ll paste (some apps share selection to the select buffer when it’s selected, some do it when they are active and a selection exists, it’s not clear which is ‘correct’ behaviour).
You know, I thought this was in the spec and loaded it up to prove it and…. it isn’t. lol, it is clear to me what is the correct behavior (asserting ownership of the global selection just when switching between programs is obviously wrong - it’d make copy/paste between two programs with a background selection impossible, since trying to paste in one would switch the active window, which would change the selection, which is just annoying), I’d assert the selection if and only if it is an explicit user action to change the selection or to initiate a clipboard cut/copy command, but yeah the ICCCM doesn’t go into any of this and neither does any other official document ive checked.
tbh, I think this is my biggest criticism of the X ecosystem in general: there’s little bits that are underspecified. In some cases, they just never defined a standard, though it’d be easy, and thus you get annoying interop problems. Other cases, like here, they describe how you should do something, but not when or why you should do that. There’s a lot to like about “mechanism, not policy” but… it certainly has its downsides.
Fair points and a difference of opinion probably driven by difference in use. I wasn’t even thinking about copying and pasting files, just textual snippets. Middle click from a file doesn’t work, but dragging and dropping files does lead to the escaped file path being inserted into the terminal.
I always appreciate the depth of knowledge your comments bring to this site, thank you for turning my half-in-jest poke at MacOS into a learning opportunity!
More than 50% of the reason I use a Mac is that copy and paste in the terminal are the same shortcut as every other app.
You know, I’m always ashamed to say that, and I won’t rate the % that it figures into my decision, but me too. For me, the thing I really like is that I can use full vim mode in JetBrains tools, but all my Mac keyboard shortcuts also work well. Because the mac command key doesn’t interfere ever with vim mode. And same for terminal apps. But the deciding feature is really JetBrains… PyCharm Pro on Mac is so much better than PyCharm Pro on Linux just because of how this specific bit of behavior influences IdeaVim.
I also like Apple’s hardware better right now, but all things being equal, this would nudge me towards mac.
Nothing to be ashamed of. I’m a diehard Linux user. I’ve been at my job 3 years now, that entire time I had a goal to get a Linux laptop, I’ve purposefully picked products that enabled that and have finally switched, and I intend to maintain development environment stuff myself (this is challenging because I’m not only the only Linux engineer, I’m also the only x86 engineer).
I say all this to hammer home that despite how much I prefer Linux (many, many warts and all), this is actually one of the biggest things by far that I miss about my old work Mac.
Plus we live in a world now where we expect tools to be released cross-platform, which means that I think a lot of people compare an electron app on, say, Linux to an equivalent native app on Linux, and argue that the native app would clearly be better.
But from what I remember of the days before electron, what we had on Linux was either significantly worse than the same app released for other platforms, or nothing at all. I’m thinking particularly of Skype for Linux right now, which was a pain to use and supported relatively few of the features other platforms had. The election Skype app is still terrible, but at least it’s better than what we had before.
Weird, all the ones I’ve used have been excellent with great UX. It’s the ones that go native that seem to struggle with their design. Prolly because xml is terrible for designing apps
I’d really like to see how you and the parent comment author interact with your computer. For me electron apps are at best barely useable, ranging from terrible UI/UX but with some useful features and useless eye candy at the cost of performance (VSCode), to really insulting to use (Slack, Discord). But then I like my margins to be set to 0 and information density on my screen to approximate the average circa-2005 japanese website. For instance Ripcord (https://cancel.fm/ripcord/static/ripcord_screenshot_win_6.png) is infinitely more pleasant for me to use than Discord.
But most likely some people disagree - from the article:
The McDonald’s ordering kiosk, powering the world’s biggest food retailer, is entirely built with Chromium.
I’m really amazed for instance that anyone would use McDonald’s kiosks as an example of something good - you can literally see most of these poor things stutter with 10fps animations and constant struggles to show anything in a timely manner.
I’d really like to see how you and the parent comment author interact with your computer. For me electron apps are at best barely useable, ranging from terrible UI/UX but with some useful features and useless eye candy at the cost of performance (VSCode), to really insulting to use (Slack, Discord).
IDK, Slack literally changed the business world by moving many companies away from email. As it turns out, instant communication and the systems Slack provided to promote communication almost certainly resulted in economic growth as well as the ability to increase remote work around the world. You can call that “insulting” but it doesn’t change the facts of its market- and mind-share.
Emoji reactions, threads, huddles, screen sharing are all squarely in the realm of UX and popularized by Slack. I would argue they wouldn’t have been able to make Slack so feature packed without using web tech, especially when you see their app marketplace which is a huge UX boon.
Slack is not just a “chat app”.
If you want a simple text-based chat app with 0-margins then use IRC.
I could easily make the same argument for VSCode: you cannot ignore the market- and mind-share. If the UX was truly deplorable then no one would use it.
Everything else is anecdotal and personal preference which I do not have any interest in discussing.
If you want a simple text-based chat app with 0-margins then use IRC.
I truly miss the days when you could actually connect to Slack with an IRC client. That feature went away in… I dunno, 2017 or so. It worked fabulously well for me.
Yeah Slack used to be much easier to integrate with. As a user I could pretty easily spot the point where they had grown large enough that it was time to start walling in that garden …
This is not a direct personal attack or criticism, but a general comment:
I find it remarkable that, when I professionally criticise GNOME, KDE and indeed Electron apps in my writing, people frequently defend them and say that they find them fine – in other words, as a generic global value judgement – without directly addressing my criticisms.
I use one Electron app routinely, Panwriter, and that’s partly because it tries to hide its UI. It’s a distraction-free writing tool. I don’t want to see its UI. That’s the point. But the UI it does have is good and standards-compliant. It has a menu bar; those menus appear in the OS’s standard place; they respond to the standard keystrokes.
My point is:
There are objective, independent standards for UI, of which IBM CUA is the #1 and the Mac HIG are the #2.
“It looks good and I can find the buttons and it’s easy to work” does not equate to “this program has good UI.”
It is, IMHO, more important to be standards-compliant than it is to look good.
Most Electron apps look like PWAs (which I also hate). But they are often pretty. Looking good is nice, but function is more important. For an application running on an OS, fitting in with that OS and using the OS’s UI is more important than looking good.
But today ISTM that this itself is an opinion, and an unusual and unpopular one. I find that bizarre. To me it’s like saying that a car or motorbike must have the standard controls in the standard places and they must work in the standard way, and it doesn’t matter if it’s a drop-dead beautiful streamlined work of art if those aren’t true. Whereas it feels like the prevailing opinion now is that a streamlined work of art with no standard controls is not only fine but desirable.
Confirmation bias is cherry picking evidence to support your preconceptions. This, is simply having observed something (“all Electron apps I’ve used were terrible”), and not being interested in why — which is understandable since the conclusion was “avoid Electron”.
It’s okay at some point to decide you have looked at enough evidence, make up your mind, and stop spending time examining any further evidence.
Yes, cherry picking is part of it, but confirmation bias is a little more extensive than that.
It also affects when you even seek evidence, such as only checking what an app is built with when it’s slow, but not checking when it’s fast.
It can affect your interpretation and memory as well. E.g., if you already believe electron apps are slow, you may be more likely to remember slow electron apps and forget (if you ever learned of) fast electron apps.
Don’t get me wrong, I’m guilty of this too. Slack is the canonical slow electron app, and everyone remembers it. Whereas my 1Password app is a fast electron app, but I never bothered to learn that until the article mentioned it.
All of which is to say, I’m very dubious that people’s personal experiences in the comments are an unbiased survey of the state of electron app speeds. And if your data collection and interpretation are biased, it doesn’t matter how much of it you’ve collected. (E.g., the disastrous 1936 Literary Digest prediction of Landon defeating Roosevelt, which polled millions of Americans, but from non-representative automobile and telephone owners.)
We’re talking about someone who stopped seeking evidence, so it doesn’t apply here.
All of which is to say, I’m very dubious that people’s personal experiences in the comments are an unbiased survey of the state of electron app speeds.
So would I.
And it doesn’t help that apparently different people have very different criteria for what constitutes acceptable performance. My personal criterion would be “within an order of magnitude of the maximum achievable”. That is, if it is 10 times slower than the fastest possible, that’s still acceptable to me in most settings. Thing is though, I’m pretty sure many programs are _three_orders of magnitude slower than they could be, and I don’t notice because when I click a button or whatever they still react in fewer frames than I can consciously perceive — but that still impacts battery life, and still necessitates a faster computer than necessary. Worse, in practice I have no idea how much slower than necessary an app really is. The best I can do is notice that a similar app feels snappier, or doesn’t uses as much resources.
It still applies if they stopped seeking evidence because of confirmation bias.
Oh but then you have to establish that confirmation bias happened before they stopped. And so far you haven’t even asserted it — though if you did I would dispute it.
And even if you were right, and confirmation bias led them to think they have enough evidence even though they do not, and then stopped seeking, the act of stopping itself is not confirmation bias, it’s just thinking one has enough evidence to stop bothering.
Stopping to seek evidence does not confirm anything by the way. It goes both ways: either the evidence confirms the belief and we go “yeah yeah, I know” and forget about it, or it weakens it and we go “don’t bother, I know it’s bogus in some way”. Under confirmation bias, one would remember the confirming evidence, and use it later.
Oh but then you have to establish that confirmation bias happened before they stopped. And so far you haven’t even asserted it — though if you did I would dispute it.
As a default stance, that’s more likely to be wrong than right.
Which of these two scenarios is more likely: that the users in this thread carefully weighed the evidence in an unbiased manner, examining both electron and non-electron apps, seeking both confirmatory and disconfirmatory evidence… or that they made a gut judgment based on a mix of personal experience and public perception.
The second is way more likely.
the act of stopping itself is not confirmation bias, it’s just thinking one has enough evidence to stop bothering.
It’s the reason behind stopping, not the act itself, that can constitute “confirmation bias”.
… either the evidence confirms the belief and we go “yeah yeah, I know” and forget about it, or it weakens it and we go “don’t bother, I know it’s bogus in some way”. Under confirmation bias, one would remember the confirming evidence, and use it later.
As a former neuroscientist, I can assure you, you’re using an overly narrow definition not shared by the actual psychology literature.
Confirmation bias (also confirmatory bias, myside bias,[a] or congeniality bias[2]) is the tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values.[3] People display this bias when they select information that supports their views, ignoring contrary information, or when they interpret ambiguous evidence as supporting their existing attitudes. The effect is strongest for desired outcomes, for emotionally charged issues, and for deeply entrenched beliefs.
Sounds like a reasonable definition, not overly narrow. And if you as a specialist disagree with that, I encourage you to correct the Wikipedia page. Assuming however you do agree with this definition, let’s pick apart the original comment:
I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.
WHY this is the case is a respactable topic for sure, but since I already know the outcome I’m more interested in other topics.
Let’s see:
I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.
If that’s true, that’s not confirmation bias — because it’s true. If it isn’t, yeah, we can blame confirmation bias for ignoring good Electron apps. Maybe they only checked when the app was terrible or something? At this point we don’t know.
Now one could say with high confidence this is confirmation bias, if they personally believe a good proportion of Electron apps are not terrible. They would conclude highly unlikely that the original commenter really only stumbled on terrible Electron apps, so they must have ignored (or failed to notice) the non-terrible ones. Which indeed would be textbook confirmation bias.
But then you came in and wrote:
since I already know the outcome
This is exactly what confirmation bias refers to.
Oh, so you were seeing the bias in the second paragraph:
WHY this is the case is a respactable topic for sure, but since I already know the outcome I’m more interested in other topics.
Here we have someone who decided they had seen enough, and decided to just avoid Electron and move on. Which I would insist is a very reasonable thing to do, should the first paragraph be true (which it is, as far as they’re concerned).
Even if the first paragraph was full of confirmation bias, I don’t see any here. Specifically, I don’t see any favouring of supporting information, or any disfavouring of contrary information, or misinterpreting anything in a way that suits them. And again, if you as a specialist says confirmation bias is more than that, I urge you to correct the Wikipedia page.
is the tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values
But… Wikipedia already agrees with me here. This definition is quite broad in scope. In particular, note the “search for” part. Confirmation bias includes biased searches, or lack thereof.
If that’s true, that’s not confirmation bias — because it’s true.
Confirmation bias is about how we search for and interpret evidence, regardless of whether our belief is true or not. Science is not served by only seeking to confirm what we know. As Karl Popper put it, scientists should always aim to falsify their theories. Plus, doing so assumes the conclusion; we might only think we know the truth, but without seeking to disconfirm, we’d never find out.
I don’t see any favouring of supporting information, or any disfavouring of contrary information, or misinterpreting anything in a way that suits them
Why would they be consciously aware of doing that, or say so in public if they were? People rarely think, “I’m potentially biased”. It’s a scientific approach to our own cognition that has to be cultivated.
To reiterate, it’s most likely we’re biased, haven’t done the self-reflection to see that, and haven’t systematically investigated electron vs non-electron performance to state anything definitively.
And I get it, too. We only have so many hours in the day, we can’t investigate everything 100%, and quick judgments are useful. But, they trade off speed for accuracy. We should strive to remember that, and be humble instead of overconfident.
In particular, note the “search for” part. Confirmation bias includes biased searches, or lack thereof.
As long as you’re saying “biased search”, and “biased lack of search”. The mere absence of search is not in itself a bias.
quick judgments are useful. But, they trade off speed for accuracy.
Yup. Note that this trade-off is a far cry from actual confirmation bias.
If that’s true, that’s not confirmation bias — because it’s true.
Confirmation bias is about how we search for and interpret evidence, regardless of whether our belief is true or not.
Wait, I think you’re misinterpreting the “it” in my sentence. By “it”, I meant literally the following statement: “I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.”
That statement does not say whether all Electron apps are terrible or whether Electron makes apps terrible, or anything like that. It states what had been directly observed. And if it is true that:
They used many Electron apps.
They’ve all been terrible.
Every time there was an alternative it was better.
Then believing and writing those 3 points is not confirmation bias. It’s just stating the fact as they happened. If on the other hand it’s not true, then we can call foul:
If they only used a couple Electron apps, that’s inflating evidence.
If not all Electron apps they used have been terrible, there’s confirmation bias for omitting (or forgetting) the one that weren’t.
If sometimes the alternative was worse, again, confirmation bias.
As Karl Popper put it, scientists should always aim to falsify their theories.
For the record I’m way past Popper. He’s not wrong, and his heuristic is great in practice, but now we have probability theory. Long story short, the material presented in E. T. Jaynes’ Probability Theory: the Logic of Science should be part of the mandatory curriculum, before you even leave high school — even if maths and science aren’t your chosen field.
One trivial, yet important, result from probability theory, is that absence of evidence is evidence of absence: if you expect to see some evidence of something if it’s true, then not seeing that evidence should lower your probability that it is true. The stronger you expect that evidence, the further your belief ought to shift.
Which is why Popper’s rule is important: by actively seeking evidence, you make it that much more probable to stumble upon it, should your theory be false. But the more effort you put into falsifying your theory, and failing, the more likely your theory is true. The kicker, though, is that it doesn’t apply to just the evidence you actively seek out, or the experimental tests you might do. It applies to any evidence, including what you passively observe.
Why would they be consciously aware of doing that, or say so in public if they were? People rarely think, “I’m potentially biased”.
Oh no you don’t. We’re all fallible mortals, all potentially biased, so I can quote a random piece of text, say “This is exactly what confirmation bias refers to” and that’s okay because surely the human behind it has confirmation bias like the rest of us even if they aren’t aware of it, right? That’s a general counter argument, it does not work that way.
There is a way to assert confirmation bias, but you need to work from your own prior beliefs:
Say you have very good reasons to believe that (i) at least half of Electrons app are not terrible, and (ii) confirmation bias is extremely common.
Say you accept that they have used at least 10 such apps. Under your prior, the random chance they’ve all been terrible is less than 1 in a thousand. The random chance that confirmation bias is involved in some way however, is quite a bit higher.
Do the math. What do you know, it is more likely this comment is a product of confirmation bias than actual observation.
Something like that. It’s not exact either (there’s selection bias, the possibility of “many” meaning only “5”, the fact we probably don’t agree on the definitions of “terrible” and “better”), but you get the gist of it: you can’t invoke confirmation bias from a pedestal. You have to expose yourself a little bit, reveal your priors at the risk of other people disputing them, otherwise your argument falls flat.
Our comments are getting longer and longer, we’re starting to parse minutiae, and I just don’t have the energy to add in the Bayesian angle and keep it going today.
It’s been stimulating though! I disagree, but I liked arguing with someone in good faith. Enjoy your weekend out there.
Am I the only one who routinely looks at every app I download to see what toolkit it’s using? Granted, I have an additional reason to care about that: accessibility.
Who cares? “All electron apps are terrible, most non-electron apps are not” is enough information to try to avoid Electron, even if it just so happens to be true for other reasons (e.g maybe only terrible development teams choose Electron, or maybe the only teams who choose Electron are those under a set of constraints from management which necessarily will make the software terrible).
Users, both in the consumer and business space, do not care. One hour of Netflix at 4K is roughly 7 GB, a typical Call of Duty update regularly clocks in more than 300 GB. In practice, we have not seen end users care about binary size more than they do about virtually anything else your engineering team could spend time on.
Something you seem to forget in this paragraph, is that watching a movie or playing a game tend to be performed exclusively — save for background tasks the user isn’t even aware of, the video player or game tend to be the only app running. Okay, maybe not the video player, but those 7GB are never going to be sitting in RAM at the same time.
Regular applications however tend to be run concurrently. Often we have at least the browser, messenger, email, and whatever we’re working on, all open at the same time. I personally like to have reasonable assurances that doing so will not cause my computer to swap like crazy and slow down to a crawl. And as a consumer, I would really have liked to not have to buy 32 gigs of RAM, when I’m pretty sure more reasonable coding practices would require an order of magnitude less than that — same for CPU, I love games, but my regular use requires less than two orders of magnitude computational power, if only programs were more performant.
The cost of adding ~200MB per app, for all user across the globe, is significant. The resources and pollution involved can’t be dismissed out of hand, and the benefits better be as significant. Not that Electron’s aren’t, the mere fact that it enables web devs to write native apps is huge. But it’s also part of its cost: if a web dev writes an Electron app, they’re less likely to consider resource & performance constraints, and even less likely to address them.
Electron isn’t here to compete with anyone.
But it is. People have limited time to develop applications, and they have to chose how much of that time is dedicated to Electron apps. No way around that, that’s true of pretty much anything we publish — including this very comment.
At a deeper level, people have to learn how to do stuff. There Electron is a double edged sword. On the good side it reduces the learning a web dev has to do, as well as reducing the need to learn various natives APIs for whatever set of platforms one is targetting. On the other hand it discourages learning about more efficient (at runtime) ways of writing programs, and as such is an impediment to reasonable performance — programs that’s aren’t the ludicrous CPU or RAM hogs that they so often are right now.
However, the entire point of Electron is that you can pair your web app with any native code you want to write—specifically with C++, Objective-C, or Rust.
Okay, but people aren’t using it that way. As far as I know they stop at JavaScript. Because they can. They may be missing “the entire point of Electron”, but in practice there’s very little incentive there to learn native programming: the biggest selling point of Electron after all is that it lets web devs write desktop apps. Meaning, without having to learn how to write a native app.
It’s not learning that’s the bandwidth limitation. Learning Swift+SwiftUI or C++/WinUI is something to do once and then leverage forever. I know Android, iOS, Mac, enough to build apps from scratch, and I’ve dabbled in Qt and Gnome stuff.
The issue is that Electron+Web largely lets you target all platforms from a shared codebase, rather than needing to write and indefinitely maintain 2-5 different copies of your app. If I only want to target Mac, I’ll use Swift & the native toolkits. But if I need to support Mac and Windows, I’ll pick Electron so I don’t need a second copy of my app. And if I want to target iOS and Android, all the more reason to use Electron on desktop, and wrap a webview on the mobile platforms.
I’ll have to write some duplicate code in the webview wrappers (and can add other native features selectively) but once that’s out of the way, I can implement a new feature once in my web codebase and deliver it same-day to everyone, no matter their platform.
I’m not aware of any options besides Dart/Flutter or game engine stacks that can claim the same write-once-run-everywhere, and neither of those feel like a credible option on web yet.
VS Code is the only desktop app I use. It dawned on me that Electron changed the game for app devs. Every OS vendor loves rug pulls with UI toolkits, gtk2->gtk3, winforms, various Mac UI toolkits. Its often a multi year effort to port apps between em just to stay on same platform.
By using electron you can keep using your html ui toolkit from 2010 for next century and offload all the hard integration work onto chrome devs.
When I worked at Mozilla just ensuring that Firefox wont crash on newly released MacOS was occasionally a huge undertaking cos for example libc io functions would randomly start throwing objc exceptions.
Firefox is a great example of what not supporting native UI does to your product. For years, No probably for more than a decade , Firefox did not integrate well with native UI and OS features that people take for granted to be available in every app they use.
To this day it doesn’t properly support the CoreText keyboard navigation shortcuts (Chromium, notably, does) in its text fields implementation, which drives people like me batty. Edit to add: For folks reading this who are not aware: a huge subset of the Emacs-style keyboard navigation and transformation commands Just Work™ in native Mac text fields, including Ctrl-A and Ctrl-E to go to the start and end of line, Ctrl-B and Ctrl-F to navigate by characters, Ctrl-T to swap characters, Ctrl-O to insert a newline after the cursor, Ctrl-H to delete characters, etc. It is the kind of thing that becomes second nature/muscle memory, so then finding it not working in a text field becomes incredibly distracting and annoying.
I mostly agree with you, the cross platform bit is significant¹. Though I will note that anything UI better be reduced to the absolute minimum (stateless and dumb), if only because it makes the rest of the program so much easier to test. That alone would reduce the amount of duplication needed. Most devs (and I’ve been guilty myself) don’t do this, because leveraging the framework you’re using is so much more convenient in the short term.
Which leads to learning: you’re correct, it’s not really a bandwidth limitation. It’s an investment: big initial cost, pays off later. And we humans are notoriously bad at making such investments.
[1] Edit: I forgot about Qt. It’s mere existence significantly weakens the cross platform bit, unless you count the web itself as a platform.
The cost of adding ~200MB per app, for all user across the globe, is significant.
Thanks, you mostly made my point so I don’t have to. It’s a bit of a Catch-22. The “bigger” and more important the app, the more likely it is written as a native app because it’s a proper app I properly interact with. I don’t have a problem with electron here, it’s a choice and I can reserve resources.
But the more of a situational tool the app is (e.g. a little helper, a GUI for a driver, anything) - the more likely it is written to be in Electron, because it’s not that important (even the authors see that) and the more of them I have running, and the more I’d prefer them to use 5MB of RAM and not 200.
Slack’s Electron-based app was horrible. So bad that I refuse to use it. (My M1 Max MBP only has 10 cores, 32GB RAM, and 2TB of flash, which seems either insufficient or barely-sufficient to run the Slack app.) The web version looks the same as the Electron app, but seems so much better. Even on Firefox. I don’t like Slack, so I still avoid it whenever possible, but if I need to be on Slack, it’s always going to be on the web app.
OTOH, I think the Discord app is fine. Even pleasant. I didn’t even realize it was Electron-based, but that makes sense in retrospect. It’s obviously not the fastest or lightest app (by a long shot), but it’s never made me cringe. It just seems like the Discord developers actually tried using their own app, and worked hard to make it not suck. I’ve used the web app for Discord, too, but I really didn’t care for it (even though it looked the exact same).
So anecdotally, two different apps, each available as an Electron app and as a web app, and the result of using those two apps (and both Electron and web with both apps) caused me to select the diametrically opposite outcome for each. I think with a group like the Discord dev team, I’d feel pretty comfortable building an Electron app, and not be embarrassed by the result. As for Slack, I’d say that they do a great job of making Electron look pretty bad.
This would be worth a sidebar conversation in and of itself. I don’t “rely” on Discord much, but I do use it for a slew of random purposes including (a) work chats (99% text), (b) non-work tech group chats (all text), (c) random friend circle chats (all text), (d) various web site centric chats e.g. /r/programminglanguages Discord server (all text) and (e) my family online gaming chat (mostly audio). It doesn’t tend to get in my way for any of these purposes, which is my main measure of “doesn’t suck”. I’m on macOS and spend most of my time in a code editor (IntelliJ), a shell (zsh), or the browser (Firefox), so Discord is just one of the “always on” apps (like Mail and Calendar) that sits there doing mostly nothing until I need to look at it. Anyhow, I’m curious why it is “unspeakably horrible” for you. Maybe I’m just not using it in anger, or my expectations are just super low for it 🤣
Anyhow, I’m curious why it is “unspeakably horrible” for you.
Gosh. It’s a bit like saying why you don’t like gangrene. Where to start?
I find it a visually confusing mess. It’s hard to tell groups, from contents of that group, from subtopics of that group, from threads in a topic.
It threading is nonexistent.
It’s bright and colourful and distracting, but doesn’t use colour intelligently to indicate who said what where: it seems to just splash it around for decoration. To me it looks like a UI for a teenaged boy.
Its tools for navigating from conversation to conversation are nonexistent.
It feels to me like a badly-thought-out badly-designed incompetent replacement for IRC that was put together by someone who’s never seen IRC, never seen any other text chat or 1:1 or 1:many chat app, but overheard a description in a noisy bar and thought “I can do that.” Without understanding the first thing about what’s good about such things, or what’s bad, or caring.
Are we using the same app? Discord is gray on gray. The only color is user profile pics, server-assigned name coloring, the red of the “live” indicator, and the green “share screen” button (which could probably get a coat of gray).
Threading exists, but no one uses it because a handful of topic-specific text channels works fine.
Channel groups have a “expand/collapse” chevron, text channels have a #, voice channels have a loudspeaker. Threads are indented.
Navigating between conversations is a single click?
I hear UI complaints about Discord a lot, but the complaints are always so alien to my experience.
Oh yes, but seeing it through different eyes. (Mine are 57 and myopic.)
Discord is gray on gray.
Yeah. A badly-done, low-contrast version of the annoyingly trendy “dark mode”. DO NOT WANT.
The only color is user profile pics, server-assigned name coloring, the red of the “live” indicator, and the green “share screen” button (which could probably get a coat of gray).
In other words, 4 things I don’t care about, resulting in an ugly garish riot.
Threading exists, but no one uses it
Translation: broken for non-trivial discussions.
Channel groups have a “expand/collapse” chevron, text channels have a #, voice channels have a loudspeaker. Threads are indented.
Summary: chaotic mess with no overall plan, designed for millennials who do not grok hierarchies.
Navigating between conversations is a single click?
WTF is a conversation and why should I have to know?
I hear UI complaints about Discord a lot, but the complaints are always so alien to my experience.
How do you feel about Usenet and IRC?
For me, Usenet was about as good as threaded discussion got.
While I feel inclined to join the “electron bad” bandwagon, I just haven’t had this experience with Slack and I’ve used its electron app on Windows, MacOS, and Linux. Not to mention that the computers I’ve used it on have fewer cores and RAM than yours. Does it lag from time to time? Probably? But I just leave it running in the background and it’s generally fine.
I’m curious to know what people mean when they say they find various electron apps unusable, since I’m seeing it a lot in this thread. I love to complain myself about electron whenever something inconveniences me, but I’ve never had anything more than an inconvenience. Maybe my standards for usability are much lower?
The Slack app got a lot better when they rewrote it in 2020. Prior to that it was terrible and would routinely use more than 2Gb of RAM, as shown in the chart in the linked post.
OTOH, I think the Discord app is fine. Even pleasant. I didn’t even realize it was Electron-based, but that makes sense in retrospect. It’s obviously not the fastest or lightest app (by a long shot), but it’s never made me cringe. It just seems like the Discord developers actually tried using their own app, and worked hard to make it not suck. I’ve used the web app for Discord, too, but I really didn’t care for it (even though it looked the exact same).
It makes me chuckle a bit that you have that reaction. I don’t love the slack app, and do prefer the site, but my reaction wasn’t nearly as strong as yours.
The discord app, on the other hand… I hate it with the fire of a thousand suns. I mean, it feels OK when I’m plugged in, and the web app is very aggressive about pushing me to install the electron app rather than just letting me use the site in peace.
But holy cow, the electron app is beyond awful when I’m working on battery. Leaving it running usually halves my battery life. Sometimes worse.
I only sporadically work mostly on battery, but when I do, discord is right out. I try to leave the mobile app set for notifications on my phone so that I’m still reachable that way, but I’d cheerfully pay for the ability to use an alternative discord front-end that doesn’t destroy my battery during those times when I’m working on battery.
The web app is only any better for the battery if I run it in Safari. And it feels more glitchy on Safari than in Chrome or Electron.
With a sample size of (my own usage) I’d say the discord team made an awful thing and they should feel bad, where your experience with that gives you the opposite feeling. And that’s why it makes me chuckle… two of us, using the same app for the same thing, on the same platform (I’m using a lower end M1 Pro MBP with 16GB of RAM) have very different reactions.
My experience with the Discord app is so bad that I do my best to exhaust other communication mechanisms before resorting to Discord, and I’m less likely to engage with projects that only/mostly use Discord.
I’m in camp of those who dislike most Electron apps (even though I’ll be writing one myself), but for me Slack in browser is clearly worse than in the app. At least in the app version mostly knows how to load missed messages while the app wasn’t running which is something that browser version in Firefox regularly miserably fails at. Not sure why though as I’d expect them to run the same code.
I kinda forgot how software could be and went back to reading RSS using NetNewsWire.
It’s a full fledged UI application written entirely in Swift and it’s so light-weight, so snappy to start and use. I wouldn’t mind never using another Electron app again.
Slightly longer: the post asserts 4 main points. The author fails to adequately defend any of them. I feel that that the 3 main points he tries to defend all fail. I feel all 4 objections are valid and disagree with all of his attempted defences.
This is the attitude that enables enshittification: “most users” will keep using our product despite us degrading the experience.
The dev version of this: “$POPULAR_FRAMEWORK is popular, and it must be popular because it is good, therefore $POPULAR_FRAMEWORK is good.” If you lack the imagination to see literally any other way to implement it, the experience of using something else, or lack the ability to assess the tradeoffs, it is easy to fall into this trap. It is much cognitively cheaper to outsource the hard work of critically evaluating technology to other people. The problem arises when most everyone does the same thing, creating a closed system that stalls out at local maxima. (cough)
Think about the prevailing assessment that static types were worthless boilerplate that dominated the web discourse in the early 2010s. And then TS flipped that opinion around, where people swear by static types now. That collective everyone changed their mind, which was good. But it should also instill doubt in those paying attention whether that collective everyone’s takes are as infallible as they purport to be.
Unpopular take: People write Electron apps because it solves real problems that they have, and does it better than other options. For them, the costs are worth the benefits, and for users, the UX they are used to is so twisted that they’ll shrug and use anything as long as it does something useful.
I agree with your whole take but would argue that “better” in this case means “with less effort/less cost”. There’s a lot of axes on which something can be better and I’d argue that Electron loses on most of them but by winning on that axis it got a ton of traction.
Agreed, but people seem to dicker about the definition of “better” without looking at “real problems that they have”. The real problem is “distribute GUI-based client software to everyone (that can do things that are hard for a webpage)”. Which is a hard problem, and there really aren’t that many options out there that don’t involve writing two… three… five or so different versions of their software. This is only a big problem for small teams without much funding, one might argue. Sure, but big things that succeed generally grow out of small things that succeed. And large software rewrites of functional-but-ugly systems traditionally tend to not go very well either.
So yes, “less effort and less cost”. Sometimes that’s just people twiddling numbers to try to make their own numbers go up. But sometimes it translates very directly into engineer-years of effort. How much of a finite life does one really want to spend keeping a bunch of mostly-independent codebases in sync?
I don’t use Stack Overflow much. I use Quora often, in a recreational XKCD 386 sort of way.
Some of the most frequently asked questions in my subject areas are “which is the best Linux distro?”, or “which is the best desktop?”, or “is Linux better than FreeBSD?”
And of course the response can only be: define ‘better’!
Better how, for who, for what? Better on what bases?
You say “it does it better” but that’s a relative judgement that’s hanging unsupported in the air exactly the way that bricks don’t.
The only interpretation I can find is “it makes it easier to solve real problems that they have”. It’s easier for the developers. They are presumably used to Javascript, and this saves the developers the time and effort of doing the job properly – by squandering the users’ resources, and time, and patience.
Easier != better for everyone.
To make another media SFnal reference: “Logic clearly dictates that the needs of the many outweigh the needs of the few.” Therefore, if the users outnumber the developers, then the better solution is one that delivers better apps for the users. Better by the largest average scores on as many measurements as we can think of: smaller, faster, more native and familiar looking, more accessible, using less resources, having fewer vulnerabilities, needing fewer updates, being quicker to download, being quicker to launch… how many more can we come up with?
The better solution is the solution that is better for the largest possible number of users, and if that’s more work for the devs, well the company needs to hire more or train them better.
But the real meaning of “better” here, I think, in fact means “cheaper” and “easier” and “quicker to ship”… all things which make it worse for everyone else except the developers.
Didn’t web apps take off with users because they didn’t have to download and install software? You just create an account and off you go. Electron gets rid if that advantage.
Then it became the norm and loads of stuff was web based, electron seemed like the cheapest way to make a desktop app using existing devs at a company that also produced a web app.
Now HTML and js are all over the place and developing a native app is niche and expensive so electron makes sense.
I feel like the history of electron is a history of cost cutting to achieve cross-platform compatibility. Same goes with web apps.
As a solo dev, I produce web apps for work because all my users have a web browser regardless of platform, so I can sympathise with this approach. But in a perfect world it’d be a native app for each of them.
Also the McDonald’s screen sucks and is a terrible example
No thought was given to people who are running old devices. I am curious to know whether (or how badly) Electron-based apps and other heavyweight software (ex: Android Studio, Windows 11, etc) lock out poorer people from participating in technology and society.
I also wonder how much heavyweight software impacts E-waste. After all, our devices don’t get slower; software is the main reason we feel like we need to constantly upgrade our devices and throw out our old ones.
In any case, this is more than just a technical issue. My (completely unresearched) guess is that heavyweight software is a major contributor to socioeconomic and environmental issues.
In a roundabout way, it could be good for the economies of most countries, since Capitalism tends to underemploy resources and needs artificial stimulus all the time [source: my head]. But in terms of the environment, and also slavery in mines and factories, I’m sure you’re right.
What surprises me more is the very existence of Electron. There ought to be a package format for the ‘app’ part and chrome itself capable of launching it. Having a fork that drags behind for such a massive and evolving codebase just hurts packaging and increases the value of n-day exploits.
Those were “Chrome Apps” which almost nobody used. I believe that was in part because Google kinda led people to believe they had to distribute those apps through the Chrome web store. That wasn’t really technically true but the developer documentation all assumed it.
One of Electron’s big draws is making it cheap to write a single app that supports the two most popular desktop operating systems, Windows and macOS. So I’m not at all surprised that no such package format exists, given that the format’s author would have to convince Microsoft and Apple to support the format.
macOS’s closest thing to a package manager is the Mac App Store. It has a lot of limitations, including not supporting third-party registries. So Apple is far from being able to support a specific package format.
Microsoft supporting a new format would be more plausible. Windows finally added the Windows Package Manager to the OS in 2020, seven years after the release of Electron.
Microsoft basically does support the web app stuff. Their WebView2 is an auto-updating embeddable chromium/edge for applications to use and you can declare your intention to use it with a little MS-provided dll or in the packager of the IDE (I know that’s vague, I’m not an IDE users, but I’ve seen the checkboxes in there before).
I know this isn’t exactly what you have in mind, since you still package an exe and dll, but it really isn’t awful.
So I’m not at all surprised that no such package format exists, given that the format’s author would have to convince Microsoft and Apple to support the format.
I don’t think this is true. It would be better that way, sure, but you can do it in userland. Instead of embedding Chromium the Electron app would embed a thin, infrequently updated runtime management layer that would manage the Chromium runtime in some common directory that every app used.
Lots of flaws with this approach obviously, many that would be solved by the system managing it, but I think most if not all of them are solvable decently satisfactorily.
Having Microsoft support it would be in their interests as they can then route it from App Store through Edge. That is enough surface area for it to be relevant.
Electron is just another form of corner-cutting tradeoff. One app reaches more platforms in exchange for being comparatively shitty on all of them, in terms of resource use and user experience. “At least it’s on my platform at all” is about the only positive thing a user can say about this software which is ostensibly for them. But we can all envision a better app than the one we get, one that is user-centered and therefore fit to each familiar platform. That is indeed more expensive for the same feature set, but the degree of difference depends on how much each platform provides that you then use, rather than leaving shelved the likes of NSTextView and multiple windows.
Reading through the comments, I just realised that I’ve developed a pattern subconsciously – given that half the apps I have to run for work are Electron apps, I keep an Electron app running for only as much time as I need it. None of the keep-it-in-background approach. Just because of the perception that Electron apps use a lot more resources.
I don’t think the argument is “web apps are bad” but instead “native UI is superior”
I use plenty amazing web apps. But I accept those for what they are. When an Electron app tries to become a native desktop app then the line blurs and it is clear that the lack of native UI is very noticeable.
I totally agree. Specifically, people arguing over bundle size is ridiculous when compared to the amount of data we stream on a daily basis. People complain that a website requires 10mb of JS to run but ignore the GBs in python libs required to run an LLM – and that’s ignoring the model weights themselves.
There’s a reason why Electron continues to dominate modern desktop apps and it’s pride that is clouding our collective judgement.
As someone who complains about Electron bundle size, I don’t think the argument of how much data we stream makes sense.
My ISP doesn’t impose a data cap—I’m not worried about the download size. However, my disk does have a fixed capacity.
Take the Element desktop app (which uses Electron) for example; on macOS the bundle is 600 MB. That is insane. There is no reason a chat app needs to be that large, and to add insult to injury, the UX and performance is far worse than if it were a native client or a Qt-based application.
Take the Element desktop app (which uses Electron) for example; on macOS the bundle is 600 MB. That is insane. There is no reason a chat app needs to be that large, and to add insult to injury, the UX and performance is far worse than if it were a native client or a Qt-based application.
Is it because it uses Electron that the bundle size is so large? Or could it be due to the developer not taking any care with the bundle size?
Offhand I think a copy of Electron or CEF is about ~120-150MB in 2025, so the whole bundle being 600MB isn’t entirely explained by just the presence of that.
Hm. I may be looking at a compressed number? My source for this is that when the five or so different Electron-or-CEF based apps that I use on Windows update themselves regularly, each of them does a suspiciously similar 120MB-150MB download each time.
I don’t think the streaming data comparison makes sense. I don’t like giant electron bundles because they take up valuable disk space. No matter how much I stream my disk utilisation remains roughly the same.
Interesting, I don’t think I’ve ever heard this complaint before. I’m curious, why is physical disk space a problem for you?
Also “giant” at 100mb is a surprising claim but I’m used to games that reach 100gb+. That feels giant to me so we are orders of magnitude different on our definitions.
Also, the problem of disk space and memory capacity becomes worse when we consider the recent trend of non-upgradable/non-expandable disk and memory in laptops. Then the money really counts.
Modern software dev tooling seems to devolve to copies of copies of things (Docker, Electron) in the name of standardizing and streamlining the dev process. This is a good goal, but, hope you shelled out for the 1TB SSD!
I believe @Loup-Vaillant was referring to 3D eye candy, which I think you know is different from the Electron eye candy people are referring to in other threads.
A primary purpose of games is often to show eye candy. In other words, sure games use more disk space, but the ratio of disk space actually used / disk space inherently required by the problem space is dramatically lower in games than in Electron apps. Context matters.
I care because my phone has limited storage. I’m at a point where I can’t install more apps because they’re so unnecessarily huge. When apps take up more space than personal files… it really does suck.
And many phones don’t have expandable storage via sdcard either, so it’s eWaste to upgrade. And some builds of Android don’t allow apps to be installed on external storage either.
Native libraries amortize this storage cost via sharing, and it still matters today.
Does Electron run on phones? I had no idea, and I can’t find much on their site except info about submitting to the MacOS app store, which is different to the iOS app store.
Well, Electron doesn’t run on your phone, and Apple doesn’t let apps ship custom browser engines even if they did. Native phone apps are still frequently 100mb+ using the native system libraries.
It’s not Electron but often React Native, and other Web based frameworks.
There’s definitely some bloated native apps, but the minimum size is usually larger for the web based ones. Just shipping code as text, even if minified,is a lot of overhead.
Offhand I think React Native’s overhead for a “Hello world” app is about 4MB on iOS and about 10MB on Android, though you have to turn on some build system features for Android or you’ll see a ~25MB apk.
Just shipping code as text, even if minified,is a lot of overhead.
I am not convinced of this in either direction. Can you cite anything, please? My recollection is uncertain but I think I’ve seen adding a line of source code to a C program produce object code which was bigger by more bytes than the size of the source code line was bigger. And C is a PL which tends towards small object code size, and that’s without gzipping the source code or anything.
I don’t have numbers but I believe on average machine code has higher information density than the textual representation, even if you minify that text.
So if you take a C program and compile it, generally the binary is smaller than the total text it is generated from. Again, I didn’t measure anything, but knowing a bit about how instructions are encoded makes this seem obvious to me. Optimizations can come into play, but I doubt it would change the outcome on average.
I’ve seen adding a line of source code to a C program produce object code which was bigger by more bytes than the size of the source code line was bigger
That’s different to what I’m claiming. I’d wager that change caused more machine code to be generated because before some of the text wasn’t used in the final program, i.e. was dead code or not included.
Installed web apps don’t generally ship their code compressed AFAIK, that’s more when streaming them over the network, so I don’t think it’s really relevant for bundle size.
Installed web apps don’t generally ship their code compressed AFAIK, that’s more when streaming them over the network, so I don’t think it’s really relevant for bundle size.
IPA and APK files are both zip archives. I’m not certain about iOS but installed apps are stored compressed on Android phones.
I’m not sure about APK, but IPAs are only used for distribution and are unpacked on install. Basically like a .deb DMG on macOS.
So AFAIK, it’s not relevant for disk space.
FWIW phone apps that embed HTML are using WebView (Android) or WKWebView (iOS). They are using the system web renderer. I don’t think anyone (except Firefox for Android) is bundling their own copy of a browser engine because I think it’s economically infeasible.
Funnily enough, there’s a level of speculation that one of the cited examples (Call of Duty games) is large specifically to make storage crunch a thing. You already play Call of Duty, so you want to delete our 300GB game and then have to download it again later to play other games?
I wish people chose native alternatives to Electron, but that’s going to be a tough sell until the next generation of ground-up native UI frameworks start to mature. Real ones that can claim to compete with Qt and GTK, but with modern guts written in Rust, Zig, modern C++, whatever.
That’s a lot of work, but it’s going to happen, because there is a lot of value and a lot of dare I say business agility in shipping lean code: you can deploy more places, faster. I think you’re going to see more products like Slint, and then you’ll continue to see the OSS do-it-yourself versions of those.
I dislike most Electron apps I’m aware of, but I think there’s only one thing which I fault Electron itself and not developers that use it and that is RAM usage. It doesn’t seem to be possible to write a small Electron app (small as low double digit MB).
Having said that, the app I’m in early stage of writing will almost certainly be an Electron app because I’m one guy and I’d like to cover all three major platforms. My app will need to store potentially a lot of data locally so it can work offline. The only other alternative that I’m aware of where I could use mostly one codebase is Dart/Flutter, but then the web part will suck, which I find even worse and I doubt I can build the kind of UI I know I’m capable using web technologies.
Writing and maintaining all apps in native technologies would just be completely unrealistic even if I could dedicate my whole day to this project.
Qt covers all major platforms too. In fact, it’s the one thing that still makes me use C++. Though I’d understand if C++ is a deal breaker — and I say that even though I wrote C++ for most of my career.
Thanks, you are right, I forgot about Qt. I guess I could use Python bindings which honestly I’d prefer to Javascript, but I’m also aiming for an excellent web experience and I’m not sure I can achieve that with Qt. I’ll definitely check it out though.
Electron’s choices, especially the very idea of building interfaces with web tech and shipping large parts of Chromium to render them, are not uncontroversial.
Honestly I love the core idea. I think building local UI with web tech is a fantastic idea. I just wish they shipped much less of chromium and shipped more database technology. Together these would tame a lot of the memory bloat encourage people to make more performant applications.
Electron was a great idea, solves real problems, but yet it’s misused, or just not good enough to be the default solution. Not gonna repeat what most others said, but I think if there were apps that could have “I’m targeting Electron 2025-01” and then you, as the user, have one copy of “Electron 2025-01” and not 10 of them, and also RAM usage like… in a Chrome tab per app, and not so much.. then people would maybe react more reasonable towards it. Also a lot of goodwill was used up by many terrible, terrible apps that used GB of memory for a horrible experience, e.g. Slack for a couple years (I think they’re fine now).
I prefer running web apps in my standard browser over the electron apps 100% of the time, and one of the reasons is that I, as the end user, am empowered with choice that way that electron denies me. And the general user experience is generally better, with better integration in my desktop (which you might not expect from a web app, but it is true because my browser is better integrated than their browser) and controls the other one might deny me.
It hasn’t been much of a compatibility problem either, everything ive wanted to use has worked fine, so I don’t buy the line about needing separate downloads for version control either.
Electron doesn’t support uBlock… enough said
Do many native apps support ad blocking extensions? That’d be the relevant comparison here.
Also I can’t say I’ve seen many (any?) ads in Electron apps, but I suppose they’re out there.
Tracking and analytics can be an issue as well, even if there aren’t any ads visible.
uBlock is also very helpful for thwarting some of the dark patterns in web app design. For example, it is trivial to block the “recommendations” sections on YouTube to avoid falling in to rabbit holes there.
As another example, I’ve personally blocked almost the entire “home page” of GitHub with its mix of useless eye-grabbing information and AI crap. Ideally I’d just not use GitHub, but the network effect is strong and being able to exert my will on the interface to some extent makes it more tolerable for now.
There’s nothing stopping any native app from doing that, too, right? It’s not an Electron thing per se
Indeed, and this is a legit reason for users to prefer the web apps… but if you use their browser instead of your browser, you throw those sandbox benefits away. (as well as the actually kinda nice ui customization options you have in the web world)
Sure, but since Electron apps are usually just wrapped web apps anyway, might as well use them in a browser where you get to block unwanted stuff. At least if that’s a concern for you.
I also use adblockers for removing AI prompts and such (thinking of slack here)
Particularly relevant to the author: I have no idea why a Notion app exists (which is probably broken in lots of ways) if it’s just a web site anyway.
It’s a bit surreal to me that a guy who maintains electron and works at notion tries to tell me that I’m wrong about electron while their app is so broken that I can’t even log in in it because the input fields don’t work for me.
It exists in a lot of cases to get past gatekeepers at larger companies. Buyers in these organizations use checklists for product comparison, so the lack of a desktop app can rule a product out of contention. A PWA would likely suffice, but these get surprisingly negative feedback from large organizations where the people with the control and giving the feedback are somewhat distant from the usage.
Developers respond by doing minimal work to take advantage of the desktop. The developers know they could do deeper desktop integration, but product management only want to check the box and avoid divergence from the web experience (along with a dose of MVP-itis). End users could get more value from an otherwise cruddy Electron app, if it exploited helpful desktop integrations.
Clearly, it’d be better to have a native app that exploits the desktop, but this is unlikely to happen when the customer is checking boxes (but not suggesting solid integration use cases) and PMs are overly focused on MVPs (with limited vision and experience with how desktop apps can shine.) It’s funny how these things change when it comes to native mobile apps because cross-platform apps can get dinged on enterprise checklists while PMs are willing to commit heavily.
I usually run into issues when I need to screen share or something that requires the FS
This does not seem to engage with the actual underlying disagreement, which is the tension between making economic sense and making technical sense.
As noted in the article, Electron is a very successful technology, it solves an existing issue, but I believe it is an economic issue that is being solved, not a technical one. The software industry is nowadays highly biased towards web technologies (because most software being written are written as web applications) and we have loads of developers familiar with that, Electron makes it possible to take existing web developers and have them write desktop applications with minimal training, this is a huge gain for companies compared to hiring native developers and dealing with multiple platforms.
When people complain about Electron, they usually do so on technical grounds, not economic ones. Using HTML and Javascript for the web was an (happy ?) accident, at least the way we end up using them is pretty far from the original use case they were designed for, but we do not really have any alternative. For native applications, its hard to argue web technologies are appropriate from a purely technical standpoint, they require an enormous amount of extra code on top of the operating system (a web renderer and a javascript engine), require heroic efforts to be made acceptably fast, and lack easy access to operating system services (which is usually the reason for a native app nowadays).
I find it notable that Electron seems to be mostly used for company developed software, where economic pressure is strong, and seldomly used for spare-time open source software, where economic pressure is much less present.
To expand a little on the economic argument, it’s not just a glut of web developers, but we now have to make apps that work on Windows, Android, iOS, and the web (and if you can get it working on a few popular Linux distros, that’s gravy). Maintaining a different app for every platform is costly, and the web largely solves this compatibility problem.
I do too, and it makes a certain kind of sense to me. When I’m scratching my own itch in my spare time, I don’t really ever need native and web. If web makes sense for whatever gadget I’m building, I just make a web site. If I need lots of local native functionality, I’ll go native, frequently with wxWidgets. But if a web stack is well-suited for what I’m building, just letting people point a browser at it is generally good enough for spare time projects for me.
The main time I’ve been tempted in a desktop-y direction for my web things is when I’ve had a django app that I wanted to also use offline. For my own use, starting it on the command line and pointing at localhost suits me. But I’ve got one now that I’d like to share with a few friends who decidedly won’t be able to
git cloneandmake runserver. They’re not dumb, but telling them to open a terminal is a complete non-starter. And they’ll want to use it in an environment where they won’t have wifi.For that one, I’m considering building a local app with tauri. It seems lighter than electron, seems to have some facilities to let you spawn a python server, and would give a download-and-double-click experience to these. My other option is to learn how to use ServiceWorkers to build a PWA, but I haven’t enjoyed exploring that so far, I think I’d have to tell the Mac user to install it using Firefox instead of their normal Safari browser, and I don’t have a good read on how well PWAs work on Mac even with Firefox.
Since most of this comment is negative, I’ll preface it by saying I appreciate you engaging with criticism about the project, and don’t think Electron is inherently bad.
I do avoid it when I can because of bundle size, RAM usage, and security*.
That being said, I think the misconceptions you try to address are misrepresented.
Electron pits JavaScript versus native codeYes it’s a possibility, but most apps don’t do it. Most apps use Electron as a shell for their website, with some extra hooks to look a tad native.
Web apps are badThe more nuanced argument is that given a small amount of devs and time, it’s likely easier to get a Web/Electron app out of the door. Especially with the web eating the world as you put it. Given more time, or more/different devs, then I believe native leads to a better UX (let me say “in most cases” explicitly, this is not an absolute statement).
And nowadays companies expect to invest much less in “apps,” combined with less investment in native toolkits, it tips that scale further.
I agree some people are assholes about it, but again, this is presenting things in absolute terms.
Operating System WebViews are more performantAlso, claiming “empowered with choice” doesn’t sit well with me. There’s heavy network effects at play both with using official Electron apps compared to third party native ones, and developer mindshare is already focused on Web things. Both of those often make user choice moot: I have to deal with Electron because it’s the only functional choice.
That’s not a claim I’ve heard much. At least for me, it’s mostly about reducing dependency duplication and attack surface.
Bundle size mattersBandwidth is temporary. Disk space is forever.
Defeating ElectronElectron should be called… Dark Matter.
I think this also fails to acknowledge Electron’s status and position. It’s not a tiny side project. At that scale, you, IMO, need to be conscious about impact on the ecosystem. You don’t need to help out others, but at least acknowledge your project is not on an even playing field anymore.
* On the new Why Electron docs it gives security as a reason to use it. But in my experience, Electron apps don’t get updates as often as my browser, so that possibility is not realized.
I’m not sure the author realises why companies use Electron. It’s not economically doable for most companies to write one decent native app, let alone three. Electron is their way around that.
With that kind of economic incentive, none of the arguments listed anywhere are relevant.
Yes, that’s what I was also trying to say in a couple of those paragraphs. But even outside of that the arguments are, IMO, not sound.
Your bandwidth cap is temporary, but less so, if you’re unlucky enough to live somewhere rural enough that the internet sucks. This is better than a few years ago I believe, but certainly not solved. That being said…
I like this idea a lot. After all, Electron apps do all contain black holes (or at least, something comparable…).
I have to react to this one and I don’t know how to say that nicely.
People totally lost track about how a good application is supposed to be.
Electron apps are slooow to load like a molasse on a 64GB multi GB/s NVME 32 core workstation, they have weird desktop UX, drag and drop works half of the time, Wayland support is basically the worst of all, they don’t play well with the KDE app bar most of the time.
Slack? Horrible, so slow. Zoom? Absolute garbage good luck sharing any screen with it, graphic glitches everywhere. Discord? Wants to self update, game over… When it is a glorified webpage!?
I feel insulted as a user: Laptop battery life ? Who cares! Hogging the resources from stuff you actually wants to do? Not my problem!
Now please compare that to way way more complex applications like inkscape, kdenlive, blender, krita, etc… they insta load, their UX is coherent, copy paste works, they are responsive, they support Wayland very well and they don’t duplicate an incompatible web browser runtime install for each one.
Seriously waiting 5s for a stupid chat application to load with 4GB/s of IO, combined 100GHz of super scalar CPU is just outrageous PERIOD. I still remember Borland pascal load and compile 100k lines of code in less time on a 486 at 66Mhz, this is completely absurd.
Don’t think Zoom uses electron. It’s a QtQuick app with some CEF.
oh you are right!
It feels like so many components are web based I thought it was an electron app :P. I mean the name of the process is literally “ZoomWebviewHost” :shrug: It kind of just converges to the same thing…
100% agree with your point. Even with the valid objection from @wezm about Zoom, I still think you’re right.
It feels to me like there are multiple non-overlapping definitions of what constitutes a “good app”.
An app may be a good app on a phone, but bad on a tablet. It may be good on a tablet in landscape and bad in portrait. It could be good on both tablet and phone but still terrible on a desktop PC or laptop.
Computers are not phones. Phones are not computers except in a trivial and irrelevant dictionary-definition sort of sense. A good UI on a keyboardless device can be a very bad one on a keyboard-driven device and vice versa.
I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.
WHY this is the case is a respactable topic for sure, but since I already know the outcome I’m more interested in other topics.
I believe in your perception, but I wonder how people determine this sort of thing.
It seems like an availability heuristic: if you notice an app is bad, and discover it’s made in Electron, you remember that. But if an app isn’t bad, do you even check how it was built?
Sort of like how you can always tell bad plastic surgery, but not necessarily good plastic surgery.
On macOS, there has been a shift in the past decade from noticing apps have poor UIs and seeing that they are Qt, to seeing that they are Electron. One of the problems with the web is that there’s no standard rich text edit control. Cocoa’s NSTextView is incredibly powerful, it basically includes an entire typesetting engine with hooks exposed to everything. Things like drag-and-drop, undo, consistent keyboard shortcuts, and so on all work for free if you use it. Any app that doesn’t use it, but exposes a way of editing text, sticks out. Keyboard navigation will work almost how you’re used to, for example. In Electron and the web, everyone has to use a non-standard text view if they want anything more than plain text. And a lot of apps implement their own rather than reusing a single common one, so there isn’t even consistency between Electron apps.
The is probably the best criticism of Electron apps in this thread that’s not just knee-jerk / dogpiling. It’s absolutely valid and even for non-Electron web apps it’s a real problem. I work at a company that had it’s own collaborative rich-text editor based on OT, and it is both a tonne of work to maintain and extend, and also subtly (and sometimes not-so-subtly) different to every other rich text editor out there.
I’ve been using Obsidian a fair bit lately. I’m pretty sure it’s Electron-based but on OSX that still means that most of the editing shortcuts work properly. Ctrl-a and ctrl-d for start and end of line, ctrl-n and ctrl-p for next and previous line, etc. These are all Emacs hotkeys that ended up in OSX via NeXT. Want to know what the most frustrating thing has been with using Obsidian cross platform? Those Emacs hotkeys that all work on OSX don’t work on the Linux version… on the Linux version they do things like Select All or Print. Every time I switch from my Mac laptop to my Linux desktop I end up frustrated from all of the crap that happens when I use my muscle memory hotkeys.
This is something that annoys me about Linux desktops. OPENSTEP and CDE, and even EMACS, supported a meta key so that control could be control and invoking shortcuts was a different key. Both KDE and GNOME were first released after Windows keys were ubiquitous on PC keyboards that could have been used as a command / meta key, yet they copied the Windows model for shortcuts.
More than 50% of the reason I use a Mac is that copy and paste in the terminal are the same shortcut as every other app.
You mean middle click, right? I say that in jest, but anytime I’m on a non-Linux platform, I find myself highlighting and middle clicking, then realizing that just doesn’t work here and sadly finding the actual clipboard keys.
X11’s select buffer always annoyed me because it conflates two actions. Selecting and copying are distinct operations and need to be to support operations like select and paste to overwrite. Implicitly doing a copy-like operation is annoying and hits a bunch of common corner cases. If I have something selected in two apps, switching between them and then pasting in a third makes it unclear which thing I’ll paste (some apps share selection to the select buffer when it’s selected, some do it when they are active and a selection exists, it’s not clear which is ‘correct’ behaviour).
The select buffer exists to avoid needing a clipboard server that holds a copy of the object being transferred, but drag and drop (which worked reliably on OPENSTEP and was always a pain on X11) is a better interaction model for that. And, when designed properly, has better support for content negotiation, than the select buffer in X11. For example, on macOS I can drag a file from the Finder to the Terminal and the Terminal will negotiate the path of the file as the type (and know that it’s a file, not a string, so properly escape it) and insert it into the shell. If you select a file in any X11 file manager, does this work when you middle click in an X11 terminal? Without massive hacks and tight coupling?
There’s no reason why it shouldn’t on the X level - middle clicks to the same content negotiation as any other clipboard or drag and drop operation (in fact, it is literally the same, asking for the TARGETS property, then calling XConvertSelection with the format you want, the only difference is that second argument to XConvertSelection - PRIMARY, CLIPBOARD, or XdndSelection).
If it doesn’t work, it is probably just because the terminal doesn’t try. Which I’d understand; my terminal unconditionally asks for strings too, because knowing what is going on in the running application is a bit of a pain. The terminal doesn’t know if you are at a shell prompt or a text editor or a Python interpreter unless you hack up those programs to inform it somehow. (This is something I was fairly impressed with on the Mac, those things do generally work, but I don’t know how. My guess is massive hacks and tight coupling between their shell extensions and their terminal extensions.)
Eh, I made it work in my library! I like middle click a lot and frequently double click one thing to select it, then double click followed by middle click in another to replace its content. Heck, that’s how I do web links a great many times (I can’t say a majority, but several times a day). Made me a little angry that it wouldn’t work in the mainstream programs, so I made it work in mind.
It is a bit hacky though: it does an automatic string copy of the selection into an internal buffer of the application when replacing the selection. Upon pasting, if it is asked to paste the current selection over itself, it instead use that saved buffer. Theoretically pure? Nah. Practically perfect? Yup. Works For Me.
You know, I thought this was in the spec and loaded it up to prove it and…. it isn’t. lol, it is clear to me what is the correct behavior (asserting ownership of the global selection just when switching between programs is obviously wrong - it’d make copy/paste between two programs with a background selection impossible, since trying to paste in one would switch the active window, which would change the selection, which is just annoying), I’d assert the selection if and only if it is an explicit user action to change the selection or to initiate a clipboard cut/copy command, but yeah the ICCCM doesn’t go into any of this and neither does any other official document ive checked.
tbh, I think this is my biggest criticism of the X ecosystem in general: there’s little bits that are underspecified. In some cases, they just never defined a standard, though it’d be easy, and thus you get annoying interop problems. Other cases, like here, they describe how you should do something, but not when or why you should do that. There’s a lot to like about “mechanism, not policy” but… it certainly has its downsides.
Fair points and a difference of opinion probably driven by difference in use. I wasn’t even thinking about copying and pasting files, just textual snippets. Middle click from a file doesn’t work, but dragging and dropping files does lead to the escaped file path being inserted into the terminal.
I always appreciate the depth of knowledge your comments bring to this site, thank you for turning my half-in-jest poke at MacOS into a learning opportunity!
You know, I’m always ashamed to say that, and I won’t rate the % that it figures into my decision, but me too. For me, the thing I really like is that I can use full vim mode in JetBrains tools, but all my Mac keyboard shortcuts also work well. Because the mac command key doesn’t interfere ever with vim mode. And same for terminal apps. But the deciding feature is really JetBrains… PyCharm Pro on Mac is so much better than PyCharm Pro on Linux just because of how this specific bit of behavior influences IdeaVim.
I also like Apple’s hardware better right now, but all things being equal, this would nudge me towards mac.
Nothing to be ashamed of. I’m a diehard Linux user. I’ve been at my job 3 years now, that entire time I had a goal to get a Linux laptop, I’ve purposefully picked products that enabled that and have finally switched, and I intend to maintain development environment stuff myself (this is challenging because I’m not only the only Linux engineer, I’m also the only x86 engineer).
I say all this to hammer home that despite how much I prefer Linux (many, many warts and all), this is actually one of the biggest things by far that I miss about my old work Mac.
Have you seen or tried Kinto?
I have not heard of it and my ability to operate a search engine to find the relevant thing is failing me.
https://kinto.sh/
“Mac-style shortcut keys for Linux & Windows”
https://github.com/rbreaves/kinto
Plus we live in a world now where we expect tools to be released cross-platform, which means that I think a lot of people compare an electron app on, say, Linux to an equivalent native app on Linux, and argue that the native app would clearly be better.
But from what I remember of the days before electron, what we had on Linux was either significantly worse than the same app released for other platforms, or nothing at all. I’m thinking particularly of Skype for Linux right now, which was a pain to use and supported relatively few of the features other platforms had. The election Skype app is still terrible, but at least it’s better than what we had before.
Yeah, I recall those days. Web tech is the only reason Linux on the desktop isn’t even worse than it was then.
Weird, all the ones I’ve used have been excellent with great UX. It’s the ones that go native that seem to struggle with their design. Prolly because xml is terrible for designing apps
I’d really like to see how you and the parent comment author interact with your computer. For me electron apps are at best barely useable, ranging from terrible UI/UX but with some useful features and useless eye candy at the cost of performance (VSCode), to really insulting to use (Slack, Discord). But then I like my margins to be set to 0 and information density on my screen to approximate the average circa-2005 japanese website. For instance Ripcord (https://cancel.fm/ripcord/static/ripcord_screenshot_win_6.png) is infinitely more pleasant for me to use than Discord.
But most likely some people disagree - from the article:
I’m really amazed for instance that anyone would use McDonald’s kiosks as an example of something good - you can literally see most of these poor things stutter with 10fps animations and constant struggles to show anything in a timely manner.
My children - especially the 10 and 12 year old - will stand around mocking their performance while ordering food.
IDK, Slack literally changed the business world by moving many companies away from email. As it turns out, instant communication and the systems Slack provided to promote communication almost certainly resulted in economic growth as well as the ability to increase remote work around the world. You can call that “insulting” but it doesn’t change the facts of its market- and mind-share.
Emoji reactions, threads, huddles, screen sharing are all squarely in the realm of UX and popularized by Slack. I would argue they wouldn’t have been able to make Slack so feature packed without using web tech, especially when you see their app marketplace which is a huge UX boon.
Slack is not just a “chat app”.
If you want a simple text-based chat app with 0-margins then use IRC.
I could easily make the same argument for VSCode: you cannot ignore the market- and mind-share. If the UX was truly deplorable then no one would use it.
Everything else is anecdotal and personal preference which I do not have any interest in discussing.
I truly miss the days when you could actually connect to Slack with an IRC client. That feature went away in… I dunno, 2017 or so. It worked fabulously well for me.
Yeah Slack used to be much easier to integrate with. As a user I could pretty easily spot the point where they had grown large enough that it was time to start walling in that garden …
This is not a direct personal attack or criticism, but a general comment:
I find it remarkable that, when I professionally criticise GNOME, KDE and indeed Electron apps in my writing, people frequently defend them and say that they find them fine – in other words, as a generic global value judgement – without directly addressing my criticisms.
I use one Electron app routinely, Panwriter, and that’s partly because it tries to hide its UI. It’s a distraction-free writing tool. I don’t want to see its UI. That’s the point. But the UI it does have is good and standards-compliant. It has a menu bar; those menus appear in the OS’s standard place; they respond to the standard keystrokes.
My point is:
There are objective, independent standards for UI, of which IBM CUA is the #1 and the Mac HIG are the #2.
“It looks good and I can find the buttons and it’s easy to work” does not equate to “this program has good UI.”
It is, IMHO, more important to be standards-compliant than it is to look good.
Most Electron apps look like PWAs (which I also hate). But they are often pretty. Looking good is nice, but function is more important. For an application running on an OS, fitting in with that OS and using the OS’s UI is more important than looking good.
But today ISTM that this itself is an opinion, and an unusual and unpopular one. I find that bizarre. To me it’s like saying that a car or motorbike must have the standard controls in the standard places and they must work in the standard way, and it doesn’t matter if it’s a drop-dead beautiful streamlined work of art if those aren’t true. Whereas it feels like the prevailing opinion now is that a streamlined work of art with no standard controls is not only fine but desirable.
This is called confirmation bias.
No, that’s not what confirmation bias means.
This is exactly what confirmation bias refers to.
Confirmation bias is cherry picking evidence to support your preconceptions. This, is simply having observed something (“all Electron apps I’ve used were terrible”), and not being interested in why — which is understandable since the conclusion was “avoid Electron”.
It’s okay at some point to decide you have looked at enough evidence, make up your mind, and stop spending time examining any further evidence.
Yes, cherry picking is part of it, but confirmation bias is a little more extensive than that.
It also affects when you even seek evidence, such as only checking what an app is built with when it’s slow, but not checking when it’s fast.
It can affect your interpretation and memory as well. E.g., if you already believe electron apps are slow, you may be more likely to remember slow electron apps and forget (if you ever learned of) fast electron apps.
Don’t get me wrong, I’m guilty of this too. Slack is the canonical slow electron app, and everyone remembers it. Whereas my 1Password app is a fast electron app, but I never bothered to learn that until the article mentioned it.
All of which is to say, I’m very dubious that people’s personal experiences in the comments are an unbiased survey of the state of electron app speeds. And if your data collection and interpretation are biased, it doesn’t matter how much of it you’ve collected. (E.g., the disastrous 1936 Literary Digest prediction of Landon defeating Roosevelt, which polled millions of Americans, but from non-representative automobile and telephone owners.)
We’re talking about someone who stopped seeking evidence, so it doesn’t apply here.
So would I.
And it doesn’t help that apparently different people have very different criteria for what constitutes acceptable performance. My personal criterion would be “within an order of magnitude of the maximum achievable”. That is, if it is 10 times slower than the fastest possible, that’s still acceptable to me in most settings. Thing is though, I’m pretty sure many programs are _three_orders of magnitude slower than they could be, and I don’t notice because when I click a button or whatever they still react in fewer frames than I can consciously perceive — but that still impacts battery life, and still necessitates a faster computer than necessary. Worse, in practice I have no idea how much slower than necessary an app really is. The best I can do is notice that a similar app feels snappier, or doesn’t uses as much resources.
??? It still applies if they stopped seeking evidence because of confirmation bias. I’m not clear what you’re trying to say here.
Oh but then you have to establish that confirmation bias happened before they stopped. And so far you haven’t even asserted it — though if you did I would dispute it.
And even if you were right, and confirmation bias led them to think they have enough evidence even though they do not, and then stopped seeking, the act of stopping itself is not confirmation bias, it’s just thinking one has enough evidence to stop bothering.
Stopping to seek evidence does not confirm anything by the way. It goes both ways: either the evidence confirms the belief and we go “yeah yeah, I know” and forget about it, or it weakens it and we go “don’t bother, I know it’s bogus in some way”. Under confirmation bias, one would remember the confirming evidence, and use it later.
As a default stance, that’s more likely to be wrong than right.
Which of these two scenarios is more likely: that the users in this thread carefully weighed the evidence in an unbiased manner, examining both electron and non-electron apps, seeking both confirmatory and disconfirmatory evidence… or that they made a gut judgment based on a mix of personal experience and public perception.
The second is way more likely.
It’s the reason behind stopping, not the act itself, that can constitute “confirmation bias”.
As a former neuroscientist, I can assure you, you’re using an overly narrow definition not shared by the actual psychology literature.
From Wikipedia:
Sounds like a reasonable definition, not overly narrow. And if you as a specialist disagree with that, I encourage you to correct the Wikipedia page. Assuming however you do agree with this definition, let’s pick apart the original comment:
Let’s see:
If that’s true, that’s not confirmation bias — because it’s true. If it isn’t, yeah, we can blame confirmation bias for ignoring good Electron apps. Maybe they only checked when the app was terrible or something? At this point we don’t know.
Now one could say with high confidence this is confirmation bias, if they personally believe a good proportion of Electron apps are not terrible. They would conclude highly unlikely that the original commenter really only stumbled on terrible Electron apps, so they must have ignored (or failed to notice) the non-terrible ones. Which indeed would be textbook confirmation bias.
But then you came in and wrote:
Oh, so you were seeing the bias in the second paragraph:
Here we have someone who decided they had seen enough, and decided to just avoid Electron and move on. Which I would insist is a very reasonable thing to do, should the first paragraph be true (which it is, as far as they’re concerned).
Even if the first paragraph was full of confirmation bias, I don’t see any here. Specifically, I don’t see any favouring of supporting information, or any disfavouring of contrary information, or misinterpreting anything in a way that suits them. And again, if you as a specialist says confirmation bias is more than that, I urge you to correct the Wikipedia page.
But… Wikipedia already agrees with me here. This definition is quite broad in scope. In particular, note the “search for” part. Confirmation bias includes biased searches, or lack thereof.
Confirmation bias is about how we search for and interpret evidence, regardless of whether our belief is true or not. Science is not served by only seeking to confirm what we know. As Karl Popper put it, scientists should always aim to falsify their theories. Plus, doing so assumes the conclusion; we might only think we know the truth, but without seeking to disconfirm, we’d never find out.
Why would they be consciously aware of doing that, or say so in public if they were? People rarely think, “I’m potentially biased”. It’s a scientific approach to our own cognition that has to be cultivated.
To reiterate, it’s most likely we’re biased, haven’t done the self-reflection to see that, and haven’t systematically investigated electron vs non-electron performance to state anything definitively.
And I get it, too. We only have so many hours in the day, we can’t investigate everything 100%, and quick judgments are useful. But, they trade off speed for accuracy. We should strive to remember that, and be humble instead of overconfident.
As long as you’re saying “biased search”, and “biased lack of search”. The mere absence of search is not in itself a bias.
Yup. Note that this trade-off is a far cry from actual confirmation bias.
Wait, I think you’re misinterpreting the “it” in my sentence. By “it”, I meant literally the following statement: “I’ve used many Electron apps, both mass-market and niche, and they’ve all been terrible. In some cases there’s a native app that does the same thing and it’s always better.”
That statement does not say whether all Electron apps are terrible or whether Electron makes apps terrible, or anything like that. It states what had been directly observed. And if it is true that:
Then believing and writing those 3 points is not confirmation bias. It’s just stating the fact as they happened. If on the other hand it’s not true, then we can call foul:
For the record I’m way past Popper. He’s not wrong, and his heuristic is great in practice, but now we have probability theory. Long story short, the material presented in E. T. Jaynes’ Probability Theory: the Logic of Science should be part of the mandatory curriculum, before you even leave high school — even if maths and science aren’t your chosen field.
One trivial, yet important, result from probability theory, is that absence of evidence is evidence of absence: if you expect to see some evidence of something if it’s true, then not seeing that evidence should lower your probability that it is true. The stronger you expect that evidence, the further your belief ought to shift.
Which is why Popper’s rule is important: by actively seeking evidence, you make it that much more probable to stumble upon it, should your theory be false. But the more effort you put into falsifying your theory, and failing, the more likely your theory is true. The kicker, though, is that it doesn’t apply to just the evidence you actively seek out, or the experimental tests you might do. It applies to any evidence, including what you passively observe.
Oh no you don’t. We’re all fallible mortals, all potentially biased, so I can quote a random piece of text, say “This is exactly what confirmation bias refers to” and that’s okay because surely the human behind it has confirmation bias like the rest of us even if they aren’t aware of it, right? That’s a general counter argument, it does not work that way.
There is a way to assert confirmation bias, but you need to work from your own prior beliefs:
Something like that. It’s not exact either (there’s selection bias, the possibility of “many” meaning only “5”, the fact we probably don’t agree on the definitions of “terrible” and “better”), but you get the gist of it: you can’t invoke confirmation bias from a pedestal. You have to expose yourself a little bit, reveal your priors at the risk of other people disputing them, otherwise your argument falls flat.
Our comments are getting longer and longer, we’re starting to parse minutiae, and I just don’t have the energy to add in the Bayesian angle and keep it going today.
It’s been stimulating though! I disagree, but I liked arguing with someone in good faith. Enjoy your weekend out there.
If Robert Aumann himself can at the same time produce his agreement theorem and be religious, it’s okay for us to give up. :-)
Thanks for engaging with me thus far.
Am I the only one who routinely looks at every app I download to see what toolkit it’s using? Granted, I have an additional reason to care about that: accessibility.
No I do this too. Always interesting to see how things are built.
You should write your findings up in a post and submit it! Might settle a lot of debates in the comments 😉
[Comment removed by author]
Were you able to determine that they were terrible because they used Electron?
Who cares? “All electron apps are terrible, most non-electron apps are not” is enough information to try to avoid Electron, even if it just so happens to be true for other reasons (e.g maybe only terrible development teams choose Electron, or maybe the only teams who choose Electron are those under a set of constraints from management which necessarily will make the software terrible).
I think one thing worth noting is this:
Emphasis mine. A lot of users won’t care if an app sort of sucks, but at least it exists.
Something you seem to forget in this paragraph, is that watching a movie or playing a game tend to be performed exclusively — save for background tasks the user isn’t even aware of, the video player or game tend to be the only app running. Okay, maybe not the video player, but those 7GB are never going to be sitting in RAM at the same time.
Regular applications however tend to be run concurrently. Often we have at least the browser, messenger, email, and whatever we’re working on, all open at the same time. I personally like to have reasonable assurances that doing so will not cause my computer to swap like crazy and slow down to a crawl. And as a consumer, I would really have liked to not have to buy 32 gigs of RAM, when I’m pretty sure more reasonable coding practices would require an order of magnitude less than that — same for CPU, I love games, but my regular use requires less than two orders of magnitude computational power, if only programs were more performant.
The cost of adding ~200MB per app, for all user across the globe, is significant. The resources and pollution involved can’t be dismissed out of hand, and the benefits better be as significant. Not that Electron’s aren’t, the mere fact that it enables web devs to write native apps is huge. But it’s also part of its cost: if a web dev writes an Electron app, they’re less likely to consider resource & performance constraints, and even less likely to address them.
But it is. People have limited time to develop applications, and they have to chose how much of that time is dedicated to Electron apps. No way around that, that’s true of pretty much anything we publish — including this very comment.
At a deeper level, people have to learn how to do stuff. There Electron is a double edged sword. On the good side it reduces the learning a web dev has to do, as well as reducing the need to learn various natives APIs for whatever set of platforms one is targetting. On the other hand it discourages learning about more efficient (at runtime) ways of writing programs, and as such is an impediment to reasonable performance — programs that’s aren’t the ludicrous CPU or RAM hogs that they so often are right now.
Okay, but people aren’t using it that way. As far as I know they stop at JavaScript. Because they can. They may be missing “the entire point of Electron”, but in practice there’s very little incentive there to learn native programming: the biggest selling point of Electron after all is that it lets web devs write desktop apps. Meaning, without having to learn how to write a native app.
It’s not learning that’s the bandwidth limitation. Learning Swift+SwiftUI or C++/WinUI is something to do once and then leverage forever. I know Android, iOS, Mac, enough to build apps from scratch, and I’ve dabbled in Qt and Gnome stuff.
The issue is that Electron+Web largely lets you target all platforms from a shared codebase, rather than needing to write and indefinitely maintain 2-5 different copies of your app. If I only want to target Mac, I’ll use Swift & the native toolkits. But if I need to support Mac and Windows, I’ll pick Electron so I don’t need a second copy of my app. And if I want to target iOS and Android, all the more reason to use Electron on desktop, and wrap a webview on the mobile platforms.
I’ll have to write some duplicate code in the webview wrappers (and can add other native features selectively) but once that’s out of the way, I can implement a new feature once in my web codebase and deliver it same-day to everyone, no matter their platform.
I’m not aware of any options besides Dart/Flutter or game engine stacks that can claim the same write-once-run-everywhere, and neither of those feel like a credible option on web yet.
VS Code is the only desktop app I use. It dawned on me that Electron changed the game for app devs. Every OS vendor loves rug pulls with UI toolkits, gtk2->gtk3, winforms, various Mac UI toolkits. Its often a multi year effort to port apps between em just to stay on same platform.
By using electron you can keep using your html ui toolkit from 2010 for next century and offload all the hard integration work onto chrome devs.
When I worked at Mozilla just ensuring that Firefox wont crash on newly released MacOS was occasionally a huge undertaking cos for example libc io functions would randomly start throwing objc exceptions.
Firefox is a great example of what not supporting native UI does to your product. For years, No probably for more than a decade , Firefox did not integrate well with native UI and OS features that people take for granted to be available in every app they use.
To this day it doesn’t properly support the CoreText keyboard navigation shortcuts (Chromium, notably, does) in its text fields implementation, which drives people like me batty. Edit to add: For folks reading this who are not aware: a huge subset of the Emacs-style keyboard navigation and transformation commands Just Work™ in native Mac text fields, including Ctrl-A and Ctrl-E to go to the start and end of line, Ctrl-B and Ctrl-F to navigate by characters, Ctrl-T to swap characters, Ctrl-O to insert a newline after the cursor, Ctrl-H to delete characters, etc. It is the kind of thing that becomes second nature/muscle memory, so then finding it not working in a text field becomes incredibly distracting and annoying.
I mostly agree with you, the cross platform bit is significant¹. Though I will note that anything UI better be reduced to the absolute minimum (stateless and dumb), if only because it makes the rest of the program so much easier to test. That alone would reduce the amount of duplication needed. Most devs (and I’ve been guilty myself) don’t do this, because leveraging the framework you’re using is so much more convenient in the short term.
Which leads to learning: you’re correct, it’s not really a bandwidth limitation. It’s an investment: big initial cost, pays off later. And we humans are notoriously bad at making such investments.
[1] Edit: I forgot about Qt. It’s mere existence significantly weakens the cross platform bit, unless you count the web itself as a platform.
I do count web itself as a platform - it’s probably the most important one for commercial cross-platform apps
Thanks, you mostly made my point so I don’t have to. It’s a bit of a Catch-22. The “bigger” and more important the app, the more likely it is written as a native app because it’s a proper app I properly interact with. I don’t have a problem with electron here, it’s a choice and I can reserve resources.
But the more of a situational tool the app is (e.g. a little helper, a GUI for a driver, anything) - the more likely it is written to be in Electron, because it’s not that important (even the authors see that) and the more of them I have running, and the more I’d prefer them to use 5MB of RAM and not 200.
Slack’s Electron-based app was horrible. So bad that I refuse to use it. (My M1 Max MBP only has 10 cores, 32GB RAM, and 2TB of flash, which seems either insufficient or barely-sufficient to run the Slack app.) The web version looks the same as the Electron app, but seems so much better. Even on Firefox. I don’t like Slack, so I still avoid it whenever possible, but if I need to be on Slack, it’s always going to be on the web app.
OTOH, I think the Discord app is fine. Even pleasant. I didn’t even realize it was Electron-based, but that makes sense in retrospect. It’s obviously not the fastest or lightest app (by a long shot), but it’s never made me cringe. It just seems like the Discord developers actually tried using their own app, and worked hard to make it not suck. I’ve used the web app for Discord, too, but I really didn’t care for it (even though it looked the exact same).
So anecdotally, two different apps, each available as an Electron app and as a web app, and the result of using those two apps (and both Electron and web with both apps) caused me to select the diametrically opposite outcome for each. I think with a group like the Discord dev team, I’d feel pretty comfortable building an Electron app, and not be embarrassed by the result. As for Slack, I’d say that they do a great job of making Electron look pretty bad.
Utter astonishment
It is my single most-hated modern internet comms vector because the client is so unspeakably horrible.
Including the fact that it wants to update multiple times every time I use it. For this reason I use the web or iPad app. The latter is electron free.
This would be worth a sidebar conversation in and of itself. I don’t “rely” on Discord much, but I do use it for a slew of random purposes including (a) work chats (99% text), (b) non-work tech group chats (all text), (c) random friend circle chats (all text), (d) various web site centric chats e.g. /r/programminglanguages Discord server (all text) and (e) my family online gaming chat (mostly audio). It doesn’t tend to get in my way for any of these purposes, which is my main measure of “doesn’t suck”. I’m on macOS and spend most of my time in a code editor (IntelliJ), a shell (zsh), or the browser (Firefox), so Discord is just one of the “always on” apps (like Mail and Calendar) that sits there doing mostly nothing until I need to look at it. Anyhow, I’m curious why it is “unspeakably horrible” for you. Maybe I’m just not using it in anger, or my expectations are just super low for it 🤣
Gosh. It’s a bit like saying why you don’t like gangrene. Where to start?
I find it a visually confusing mess. It’s hard to tell groups, from contents of that group, from subtopics of that group, from threads in a topic.
It threading is nonexistent.
It’s bright and colourful and distracting, but doesn’t use colour intelligently to indicate who said what where: it seems to just splash it around for decoration. To me it looks like a UI for a teenaged boy.
Its tools for navigating from conversation to conversation are nonexistent.
It feels to me like a badly-thought-out badly-designed incompetent replacement for IRC that was put together by someone who’s never seen IRC, never seen any other text chat or 1:1 or 1:many chat app, but overheard a description in a noisy bar and thought “I can do that.” Without understanding the first thing about what’s good about such things, or what’s bad, or caring.
And I don’t even like IRC!
Are we using the same app? Discord is gray on gray. The only color is user profile pics, server-assigned name coloring, the red of the “live” indicator, and the green “share screen” button (which could probably get a coat of gray).
Threading exists, but no one uses it because a handful of topic-specific text channels works fine.
Channel groups have a “expand/collapse” chevron, text channels have a #, voice channels have a loudspeaker. Threads are indented.
Navigating between conversations is a single click?
I hear UI complaints about Discord a lot, but the complaints are always so alien to my experience.
Oh yes, but seeing it through different eyes. (Mine are 57 and myopic.)
Yeah. A badly-done, low-contrast version of the annoyingly trendy “dark mode”. DO NOT WANT.
In other words, 4 things I don’t care about, resulting in an ugly garish riot.
Translation: broken for non-trivial discussions.
Summary: chaotic mess with no overall plan, designed for millennials who do not grok hierarchies.
WTF is a conversation and why should I have to know?
How do you feel about Usenet and IRC?
For me, Usenet was about as good as threaded discussion got.
While I feel inclined to join the “electron bad” bandwagon, I just haven’t had this experience with Slack and I’ve used its electron app on Windows, MacOS, and Linux. Not to mention that the computers I’ve used it on have fewer cores and RAM than yours. Does it lag from time to time? Probably? But I just leave it running in the background and it’s generally fine.
I’m curious to know what people mean when they say they find various electron apps unusable, since I’m seeing it a lot in this thread. I love to complain myself about electron whenever something inconveniences me, but I’ve never had anything more than an inconvenience. Maybe my standards for usability are much lower?
The Slack app got a lot better when they rewrote it in 2020. Prior to that it was terrible and would routinely use more than 2Gb of RAM, as shown in the chart in the linked post.
Interesting. Since I’ve avoided the Electron app for that long, I probably haven’t experienced the new and improved version, so my bias is ancient.
It makes me chuckle a bit that you have that reaction. I don’t love the slack app, and do prefer the site, but my reaction wasn’t nearly as strong as yours.
The discord app, on the other hand… I hate it with the fire of a thousand suns. I mean, it feels OK when I’m plugged in, and the web app is very aggressive about pushing me to install the electron app rather than just letting me use the site in peace.
But holy cow, the electron app is beyond awful when I’m working on battery. Leaving it running usually halves my battery life. Sometimes worse.
I only sporadically work mostly on battery, but when I do, discord is right out. I try to leave the mobile app set for notifications on my phone so that I’m still reachable that way, but I’d cheerfully pay for the ability to use an alternative discord front-end that doesn’t destroy my battery during those times when I’m working on battery.
The web app is only any better for the battery if I run it in Safari. And it feels more glitchy on Safari than in Chrome or Electron.
With a sample size of (my own usage) I’d say the discord team made an awful thing and they should feel bad, where your experience with that gives you the opposite feeling. And that’s why it makes me chuckle… two of us, using the same app for the same thing, on the same platform (I’m using a lower end M1 Pro MBP with 16GB of RAM) have very different reactions.
My experience with the Discord app is so bad that I do my best to exhaust other communication mechanisms before resorting to Discord, and I’m less likely to engage with projects that only/mostly use Discord.
I’m in camp of those who dislike most Electron apps (even though I’ll be writing one myself), but for me Slack in browser is clearly worse than in the app. At least in the app version mostly knows how to load missed messages while the app wasn’t running which is something that browser version in Firefox regularly miserably fails at. Not sure why though as I’d expect them to run the same code.
In my browser I can have at least some control over what it does (uMatrix is a great plugin), but the app can do whatever it wants. So, Firefox it is.
I kinda forgot how software could be and went back to reading RSS using NetNewsWire.
It’s a full fledged UI application written entirely in Swift and it’s so light-weight, so snappy to start and use. I wouldn’t mind never using another Electron app again.
My “TL;DR” summary:
Everyone does it, nobody cares, so it’s fine.
Slightly longer: the post asserts 4 main points. The author fails to adequately defend any of them. I feel that that the 3 main points he tries to defend all fail. I feel all 4 objections are valid and disagree with all of his attempted defences.
This is the attitude that enables enshittification: “most users” will keep using our product despite us degrading the experience.
The dev version of this: “$POPULAR_FRAMEWORK is popular, and it must be popular because it is good, therefore $POPULAR_FRAMEWORK is good.” If you lack the imagination to see literally any other way to implement it, the experience of using something else, or lack the ability to assess the tradeoffs, it is easy to fall into this trap. It is much cognitively cheaper to outsource the hard work of critically evaluating technology to other people. The problem arises when most everyone does the same thing, creating a closed system that stalls out at local maxima. (cough)
Think about the prevailing assessment that static types were worthless boilerplate that dominated the web discourse in the early 2010s. And then TS flipped that opinion around, where people swear by static types now. That collective everyone changed their mind, which was good. But it should also instill doubt in those paying attention whether that collective everyone’s takes are as infallible as they purport to be.
Unpopular take: People write Electron apps because it solves real problems that they have, and does it better than other options. For them, the costs are worth the benefits, and for users, the UX they are used to is so twisted that they’ll shrug and use anything as long as it does something useful.
I agree with your whole take but would argue that “better” in this case means “with less effort/less cost”. There’s a lot of axes on which something can be better and I’d argue that Electron loses on most of them but by winning on that axis it got a ton of traction.
Agreed, but people seem to dicker about the definition of “better” without looking at “real problems that they have”. The real problem is “distribute GUI-based client software to everyone (that can do things that are hard for a webpage)”. Which is a hard problem, and there really aren’t that many options out there that don’t involve writing two… three… five or so different versions of their software. This is only a big problem for small teams without much funding, one might argue. Sure, but big things that succeed generally grow out of small things that succeed. And large software rewrites of functional-but-ugly systems traditionally tend to not go very well either.
So yes, “less effort and less cost”. Sometimes that’s just people twiddling numbers to try to make their own numbers go up. But sometimes it translates very directly into engineer-years of effort. How much of a finite life does one really want to spend keeping a bunch of mostly-independent codebases in sync?
This is the key stumbling block, I feel.
I don’t use Stack Overflow much. I use Quora often, in a recreational XKCD 386 sort of way.
Some of the most frequently asked questions in my subject areas are “which is the best Linux distro?”, or “which is the best desktop?”, or “is Linux better than FreeBSD?”
And of course the response can only be: define ‘better’!
Better how, for who, for what? Better on what bases?
You say “it does it better” but that’s a relative judgement that’s hanging unsupported in the air exactly the way that bricks don’t.
The only interpretation I can find is “it makes it easier to solve real problems that they have”. It’s easier for the developers. They are presumably used to Javascript, and this saves the developers the time and effort of doing the job properly – by squandering the users’ resources, and time, and patience.
Easier != better for everyone.
To make another media SFnal reference: “Logic clearly dictates that the needs of the many outweigh the needs of the few.” Therefore, if the users outnumber the developers, then the better solution is one that delivers better apps for the users. Better by the largest average scores on as many measurements as we can think of: smaller, faster, more native and familiar looking, more accessible, using less resources, having fewer vulnerabilities, needing fewer updates, being quicker to download, being quicker to launch… how many more can we come up with?
The better solution is the solution that is better for the largest possible number of users, and if that’s more work for the devs, well the company needs to hire more or train them better.
But the real meaning of “better” here, I think, in fact means “cheaper” and “easier” and “quicker to ship”… all things which make it worse for everyone else except the developers.
Didn’t web apps take off with users because they didn’t have to download and install software? You just create an account and off you go. Electron gets rid if that advantage.
Then it became the norm and loads of stuff was web based, electron seemed like the cheapest way to make a desktop app using existing devs at a company that also produced a web app.
Now HTML and js are all over the place and developing a native app is niche and expensive so electron makes sense.
I feel like the history of electron is a history of cost cutting to achieve cross-platform compatibility. Same goes with web apps.
As a solo dev, I produce web apps for work because all my users have a web browser regardless of platform, so I can sympathise with this approach. But in a perfect world it’d be a native app for each of them.
Also the McDonald’s screen sucks and is a terrible example
No thought was given to people who are running old devices. I am curious to know whether (or how badly) Electron-based apps and other heavyweight software (ex: Android Studio, Windows 11, etc) lock out poorer people from participating in technology and society.
I also wonder how much heavyweight software impacts E-waste. After all, our devices don’t get slower; software is the main reason we feel like we need to constantly upgrade our devices and throw out our old ones.
In any case, this is more than just a technical issue. My (completely unresearched) guess is that heavyweight software is a major contributor to socioeconomic and environmental issues.
In a roundabout way, it could be good for the economies of most countries, since Capitalism tends to underemploy resources and needs artificial stimulus all the time [source: my head]. But in terms of the environment, and also slavery in mines and factories, I’m sure you’re right.
What surprises me more is the very existence of Electron. There ought to be a package format for the ‘app’ part and chrome itself capable of launching it. Having a fork that drags behind for such a massive and evolving codebase just hurts packaging and increases the value of n-day exploits.
Those were “Chrome Apps” which almost nobody used. I believe that was in part because Google kinda led people to believe they had to distribute those apps through the Chrome web store. That wasn’t really technically true but the developer documentation all assumed it.
One of Electron’s big draws is making it cheap to write a single app that supports the two most popular desktop operating systems, Windows and macOS. So I’m not at all surprised that no such package format exists, given that the format’s author would have to convince Microsoft and Apple to support the format.
macOS’s closest thing to a package manager is the Mac App Store. It has a lot of limitations, including not supporting third-party registries. So Apple is far from being able to support a specific package format.
Microsoft supporting a new format would be more plausible. Windows finally added the Windows Package Manager to the OS in 2020, seven years after the release of Electron.
Microsoft basically does support the web app stuff. Their WebView2 is an auto-updating embeddable chromium/edge for applications to use and you can declare your intention to use it with a little MS-provided dll or in the packager of the IDE (I know that’s vague, I’m not an IDE users, but I’ve seen the checkboxes in there before).
I know this isn’t exactly what you have in mind, since you still package an exe and dll, but it really isn’t awful.
I don’t think this is true. It would be better that way, sure, but you can do it in userland. Instead of embedding Chromium the Electron app would embed a thin, infrequently updated runtime management layer that would manage the Chromium runtime in some common directory that every app used.
Lots of flaws with this approach obviously, many that would be solved by the system managing it, but I think most if not all of them are solvable decently satisfactorily.
Having Microsoft support it would be in their interests as they can then route it from App Store through Edge. That is enough surface area for it to be relevant.
Electron is just another form of corner-cutting tradeoff. One app reaches more platforms in exchange for being comparatively shitty on all of them, in terms of resource use and user experience. “At least it’s on my platform at all” is about the only positive thing a user can say about this software which is ostensibly for them. But we can all envision a better app than the one we get, one that is user-centered and therefore fit to each familiar platform. That is indeed more expensive for the same feature set, but the degree of difference depends on how much each platform provides that you then use, rather than leaving shelved the likes of NSTextView and multiple windows.
Reading through the comments, I just realised that I’ve developed a pattern subconsciously – given that half the apps I have to run for work are Electron apps, I keep an Electron app running for only as much time as I need it. None of the keep-it-in-background approach. Just because of the perception that Electron apps use a lot more resources.
I don’t think the argument is “web apps are bad” but instead “native UI is superior”
I use plenty amazing web apps. But I accept those for what they are. When an Electron app tries to become a native desktop app then the line blurs and it is clear that the lack of native UI is very noticeable.
I totally agree. Specifically, people arguing over bundle size is ridiculous when compared to the amount of data we stream on a daily basis. People complain that a website requires 10mb of JS to run but ignore the GBs in python libs required to run an LLM – and that’s ignoring the model weights themselves.
There’s a reason why Electron continues to dominate modern desktop apps and it’s pride that is clouding our collective judgement.
https://bower.sh/my-love-letter-to-front-end-web-development
As someone who complains about Electron bundle size, I don’t think the argument of how much data we stream makes sense.
My ISP doesn’t impose a data cap—I’m not worried about the download size. However, my disk does have a fixed capacity.
Take the Element desktop app (which uses Electron) for example; on macOS the bundle is 600 MB. That is insane. There is no reason a chat app needs to be that large, and to add insult to injury, the UX and performance is far worse than if it were a native client or a Qt-based application.
Mine does and many ISPs do. Disk space is dirt cheap in comparison to bandwidth costs
Citation needed.
See native (Qt-based) Telegram client.
Is it because it uses Electron that the bundle size is so large? Or could it be due to the developer not taking any care with the bundle size?
Offhand I think a copy of Electron or CEF is about ~120-150MB in 2025, so the whole bundle being 600MB isn’t entirely explained by just the presence of that.
I’m not so sure… the “minimal” spotify build is 344 MB:
And if you decompress it (well, this is an older version but i don’t wanna downlod another just for a lobsters comment):
1.3 GB libcef.so, no slouch.
Hm. I may be looking at a compressed number? My source for this is that when the five or so different Electron-or-CEF based apps that I use on Windows update themselves regularly, each of them does a suspiciously similar 120MB-150MB download each time.
I don’t think the streaming data comparison makes sense. I don’t like giant electron bundles because they take up valuable disk space. No matter how much I stream my disk utilisation remains roughly the same.
Interesting, I don’t think I’ve ever heard this complaint before. I’m curious, why is physical disk space a problem for you?
Also “giant” at 100mb is a surprising claim but I’m used to games that reach 100gb+. That feels giant to me so we are orders of magnitude different on our definitions.
When a disk is getting full due to virtual machines, video footage, photos, every bit counts and having 9 copies of chromium seems silly and wasteful.
Also, the problem of disk space and memory capacity becomes worse when we consider the recent trend of non-upgradable/non-expandable disk and memory in laptops. Then the money really counts.
Modern software dev tooling seems to devolve to copies of copies of things (Docker, Electron) in the name of standardizing and streamlining the dev process. This is a good goal, but, hope you shelled out for the 1TB SSD!
At least games have the excuse of showing a crapload of eye candy (landscapes and all that).
Funny, even within this thread people are claiming Electron apps have “too much eye candy” while others are claiming “not enough”
I believe @Loup-Vaillant was referring to 3D eye candy, which I think you know is different from the Electron eye candy people are referring to in other threads.
A primary purpose of games is often to show eye candy. In other words, sure games use more disk space, but the ratio of
disk space actually used / disk space inherently required by the problem spaceis dramatically lower in games than in Electron apps. Context matters.I care because my phone has limited storage. I’m at a point where I can’t install more apps because they’re so unnecessarily huge. When apps take up more space than personal files… it really does suck.
And many phones don’t have expandable storage via sdcard either, so it’s eWaste to upgrade. And some builds of Android don’t allow apps to be installed on external storage either.
Native libraries amortize this storage cost via sharing, and it still matters today.
Does Electron run on phones? I had no idea, and I can’t find much on their site except info about submitting to the MacOS app store, which is different to the iOS app store.
Well, Electron doesn’t run on your phone, and Apple doesn’t let apps ship custom browser engines even if they did. Native phone apps are still frequently 100mb+ using the native system libraries.
It’s not Electron but often React Native, and other Web based frameworks.
There’s definitely some bloated native apps, but the minimum size is usually larger for the web based ones. Just shipping code as text, even if minified,is a lot of overhead.
Offhand I think React Native’s overhead for a “Hello world” app is about 4MB on iOS and about 10MB on Android, though you have to turn on some build system features for Android or you’ll see a ~25MB apk.
I am not convinced of this in either direction. Can you cite anything, please? My recollection is uncertain but I think I’ve seen adding a line of source code to a C program produce object code which was bigger by more bytes than the size of the source code line was bigger. And C is a PL which tends towards small object code size, and that’s without gzipping the source code or anything.
I don’t have numbers but I believe on average machine code has higher information density than the textual representation, even if you minify that text.
So if you take a C program and compile it, generally the binary is smaller than the total text it is generated from. Again, I didn’t measure anything, but knowing a bit about how instructions are encoded makes this seem obvious to me. Optimizations can come into play, but I doubt it would change the outcome on average.
That’s different to what I’m claiming. I’d wager that change caused more machine code to be generated because before some of the text wasn’t used in the final program, i.e. was dead code or not included.
Installed web apps don’t generally ship their code compressed AFAIK, that’s more when streaming them over the network, so I don’t think it’s really relevant for bundle size.
IPA and APK files are both zip archives. I’m not certain about iOS but installed apps are stored compressed on Android phones.
I’m not sure about APK, but IPAs are only used for distribution and are unpacked on install. Basically like a
.debDMG on macOS.So AFAIK, it’s not relevant for disk space.
FWIW phone apps that embed HTML are using WebView (Android) or WKWebView (iOS). They are using the system web renderer. I don’t think anyone (except Firefox for Android) is bundling their own copy of a browser engine because I think it’s economically infeasible.
Funnily enough, there’s a level of speculation that one of the cited examples (Call of Duty games) is large specifically to make storage crunch a thing. You already play Call of Duty, so you want to delete our 300GB game and then have to download it again later to play other games?
I wish people chose native alternatives to Electron, but that’s going to be a tough sell until the next generation of ground-up native UI frameworks start to mature. Real ones that can claim to compete with Qt and GTK, but with modern guts written in Rust, Zig, modern C++, whatever.
That’s a lot of work, but it’s going to happen, because there is a lot of value and a lot of dare I say business agility in shipping lean code: you can deploy more places, faster. I think you’re going to see more products like Slint, and then you’ll continue to see the OSS do-it-yourself versions of those.
I dislike most Electron apps I’m aware of, but I think there’s only one thing which I fault Electron itself and not developers that use it and that is RAM usage. It doesn’t seem to be possible to write a small Electron app (small as low double digit MB).
Having said that, the app I’m in early stage of writing will almost certainly be an Electron app because I’m one guy and I’d like to cover all three major platforms. My app will need to store potentially a lot of data locally so it can work offline. The only other alternative that I’m aware of where I could use mostly one codebase is Dart/Flutter, but then the web part will suck, which I find even worse and I doubt I can build the kind of UI I know I’m capable using web technologies.
Writing and maintaining all apps in native technologies would just be completely unrealistic even if I could dedicate my whole day to this project.
Qt covers all major platforms too. In fact, it’s the one thing that still makes me use C++. Though I’d understand if C++ is a deal breaker — and I say that even though I wrote C++ for most of my career.
Thanks, you are right, I forgot about Qt. I guess I could use Python bindings which honestly I’d prefer to Javascript, but I’m also aiming for an excellent web experience and I’m not sure I can achieve that with Qt. I’ll definitely check it out though.
Wait, by “all three major platforms”, did you mean Windows+Mac Os+Web browser? I thought you meant Linux initially.
Anyway, if the web browser is one of your targets, I’m afraid Qt isn’t meant for that. Maybe Qt Quick, but I’ve never used it so I don’t know.
Yes, I did meant that and should have written 4 platforms.
Most of these things are actually right, at least to some degree.
Honestly I love the core idea. I think building local UI with web tech is a fantastic idea. I just wish they shipped much less of chromium and shipped more database technology. Together these would tame a lot of the memory bloat encourage people to make more performant applications.
Electron was a great idea, solves real problems, but yet it’s misused, or just not good enough to be the default solution. Not gonna repeat what most others said, but I think if there were apps that could have “I’m targeting Electron 2025-01” and then you, as the user, have one copy of “Electron 2025-01” and not 10 of them, and also RAM usage like… in a Chrome tab per app, and not so much.. then people would maybe react more reasonable towards it. Also a lot of goodwill was used up by many terrible, terrible apps that used GB of memory for a horrible experience, e.g. Slack for a couple years (I think they’re fine now).