7 ms·

Is it just me or do others find the Electron bashing a little over the top as well? I mean VS Code, Discord, Slack and Obsidian are all in very widespread use

Is it just me or do others find the Electron bashing a little over the top as well? I mean VS Code, Discord, Slack and Obsidian are all in very widespread use and work perfectly fine for me. Are there alternatives to Electron that require less resources? Tauri seems to be proof that there are. But I think there is real value in large communities and backing. Electron seems to work perfectly fine to me for everyday use as is evident by the applications mentioned above. I would personally choose Electron over Tauri even for greenfield projects, simply because Electron seems to power applications that are in much more widespread use.

ohgodplsno 3y ago
Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You know what I'd like to use my RAM for instead ? Gradle. kotlinc. intellij. Things that I actually use to do my work, and not a bad IRC that wants to make me pay for the privilege of seeing old messages. Electron is a demonstration of laziness and a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time.
- crubier 3y ago
  > a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time. Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, but want the app to have the features and UX they need instead. The irrational obsession of part of the Hacker News crowd for the RAM usage of web apps is borderline psychotic. Man, take a chill pill, go get more RAM for a couple bucks once every 3 years, and let the engineers focus on UX and features ok? I don't want my productivity app to be a codegolf exercise
  - palata 3y ago
    You seem to believe that companies do what's best for their users. Not sure in which world you live: companies do what seems most profitable for them (and pray that it is). Can we at least agree on the fact that it would not be that difficult (and costly) for Slack to actually expose an API allowing for third-party clients? That way I could have a lightweight CLI client and I would be fine with most users staying on their crappy Electron client. I guess they don't do it for a reason, which is probably not user experience. Maybe having only official apps is (or seems, again) better for lock-in?
    - crubier 3y ago
      Couple reasons: 1-An external API is a product, you have to maintain it, keep it backward compatible even when you change your internal models, monitor it, protect it against attacks, etc. So no, I do not agree that it would be easy for Slack to expose an external API for 3rd party clients. It would be at least millions worth of investment. 2-A lightweight CLI client for Slack? Let me tell you, this would have a very very tiny user base. Probably just you, and even you would be bored of it after 1week. Would it be worth it for Slack to invest millions in an external API just so a couple hundred geeks can make their own crappy client? 3-Analytics. Slack runs analytics on usage of their app, in order to know what users use and want. Can't do that if you don't own the frontend. 4-Brand. If one of your main competitive advantages is a good UX (And believe me, it is the case for Slack), would you want to grant people the right to create crappy apps that ruins the UX and turn people off your product? This is what is killing Android brand value for example. Sure it's open, but it means there are a lot of Crappy UIs that turn people off. The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company, so incentives are aligned to some extent, and very unlikely to be completely opposed as you seem to suggest. So yes, I believe that companies are taking strategic decisions (such as not shipping an external API and 5 different native clients) in large part because it does indeed benefit the majority of their users.
      - palata 3y ago
        1- I would hope that they already maintain and protect their private API against attacks (it has to be exposed to the internet, right?), and that they keep backward compatibility for the ElectronJS (and isn't the Android app native?) that are not updated out there. You forgot to mention something like "they would have to invent access control", to which I would answer that they already need that. They would literally just have to open their API to third parties. I doubt this would cost millions. 2- Don't assume too much. I use IRC from a CLI. But anyway you are just repeating your previous point, which is that you think it would cost millions. 3- Well, they would know what the third-party apps use in the API. They could also provide integrations for most popular languages, and those would send telemetry (what do you think the Google Play Services do?). For my crappy app, probably they don't need to know what I do, I am just a useless geek as you said. 4- Counter example: I was always able to connect my crappy app to my GMail account, and it did not prevent GMail from essentially taking over e-mail. But the couple hundred geeks who don't like the web frontend can use their crappy e-mail app, and everyone is happy. > The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company. Respectfully, that is the most naive comment I have read today. I don't even know where to start answering that, so I'll just pass :-).
- dathinab 3y ago
  Idk. I have electron programs running which take up much less residual memory. I do have slack running in my browser thou and the whole browser running slack and outlock360 and a bunch of other tabs uses 600MB of residual memory of which ... 324MB is used by slack ... so I would say it's more of an slack then a electron problem. AFIK the overhead of electron is around 100MB per-program this is still bad, sure, but far less worse then what you describe.
- nottorp 3y ago
  > Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You forgot about the times when two or more of the electron applications you run because you have no other option decide to take 20% CPU each or more. Even if you make it a point of pride to run a computer that eats power measurable in kilowatts per hour, that's bad when on battery at least. And from the article: > One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron. What's the difference? It will still end up eating all that ram and needlessly refreshing the cat gifs someone posted a day and a half ago.
  - jraph 3y ago
    > What's the difference? The code of the web engine can be shared among several apps, instead of each of them having its own copy in RAM, making it less of an issue when having several of them. If each of them don't abuse RAM usage of course. Which is a big if of course.
    - nottorp 3y ago
      The .so is shared. All those uncompressed cat gifs, no. I'm not familiar with internal browser architecture, but do they make at least a token effort to not render/run attached javascript for elements that are not currently in view? I haven't measured, but my gut feeling is Electron apps go extremely crappy when you have like 30 memes in a row in a chat channel and make the mistake of switching to it. Edit: hey, what happens when you open a 500 M log file in vscode?
      - pwdisswordfishc 3y ago
        There is not such thing as ‘attached javascript for elements’.
        nottorp 3y ago
        There should be. So it can be turned off when the element is not visible.
creshal 3y ago
Discord is not working "perfectly fine" on desktop for many people. Usually, the browser version is faster, needs less resources, has fewer platform integration problems (mic/camera access etc.), and crashes less often. And has less critical security vulnerabilities, as a browser gets patched much faster than Electron in general, and Discord in particular (who tend to be on an older branch, due to some native C++ libraries, that as far as I can tell have no user-visible impact). And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.
255kb 3y ago
I maintain an open-source app built with Electron. It serves tens of thousands of users every months and nobody complained in 5 years that it is being built with Electron. Not saying that Electron is perfect, and that it couldn't be a bit more performant, but as a solo maintainer (and entrepreneur) it helps me ship something that save people time. The burden of maintaining an application is already huge. Having to juggle with multiple environments would be a hassle and I definitely wouldn't do it. That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet. The app, if you are interested: https://mockoon.com https://mockoon.com
razemio 3y ago
I feel so too. There are currently no valid alternatives I know to electron. It is sad, but this is the current state of UI frameworks, if you are targeting cross-platform with identical look and feel. Also electron comes with its own advantages which many on HN seem to forget. code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.
BiteCode_dev 3y ago
While I appreciate VSCode, I think Discord, Slack and Obsidian are not selling the platform at all. They feel sluggish and have poor ergonomics. Now the second one may or may not be attributed to Electron depending of if you buy the cultural thinggy, but the first one clearly is. Mumble is super reactive in comparison to them, and most note softwares dance around Obsidian. Having a latency on local clicks and transitions is not my idea of fun. VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.
- Capricorn2481 3y ago
  I can't imagine anyone calling Obsidian sluggish. Do you perhaps have a lot of plugins?
  - BiteCode_dev 3y ago
    Open sublime text side by side, and it will be obvious.
    - Capricorn2481 3y ago
      Well sublime is amazing, and trying to build an Obsidian equivalent in Sublime would be astronomical work. For what it is, Obsidian is very impressive.
- IceSentry 3y ago
  These things are all very subjective. Not everyone is affected the same way by latency. I hear people complaining about it all the time on thw internet, but in practice I never notice it and I don't know anyone that does either. Ergonomics is the same, I think discord is really nice to use and all the alternatives I've used have been worse. To be clear, your opinion is absolutely valid I just don't think they apply equally to everyone.
  - BiteCode_dev 3y ago
    It's probably a generational thing. The 20 last years, the web, the animations and the badly coded apps lead people to be used to slow software. However, when you have used software for decades on much less powerful hardware, the sluggishness of all of it is kinda jarring.
theappsecguy 3y ago
Electron is ok. Not the best, but not as bad as some people claim it is, though it varies app to app. I feel the same way about React Native.

ohgodplsno 3y ago

Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You know what I'd like to use my RAM for instead ? Gradle. kotlinc. intellij. Things that I actually use to do my work, and not a bad IRC that wants to make me pay for the privilege of seeing old messages. Electron is a demonstration of laziness and a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time.

crubier 3y ago
> a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time. Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, but want the app to have the features and UX they need instead. The irrational obsession of part of the Hacker News crowd for the RAM usage of web apps is borderline psychotic. Man, take a chill pill, go get more RAM for a couple bucks once every 3 years, and let the engineers focus on UX and features ok? I don't want my productivity app to be a codegolf exercise
- palata 3y ago
  You seem to believe that companies do what's best for their users. Not sure in which world you live: companies do what seems most profitable for them (and pray that it is). Can we at least agree on the fact that it would not be that difficult (and costly) for Slack to actually expose an API allowing for third-party clients? That way I could have a lightweight CLI client and I would be fine with most users staying on their crappy Electron client. I guess they don't do it for a reason, which is probably not user experience. Maybe having only official apps is (or seems, again) better for lock-in?
  - crubier 3y ago
    Couple reasons: 1-An external API is a product, you have to maintain it, keep it backward compatible even when you change your internal models, monitor it, protect it against attacks, etc. So no, I do not agree that it would be easy for Slack to expose an external API for 3rd party clients. It would be at least millions worth of investment. 2-A lightweight CLI client for Slack? Let me tell you, this would have a very very tiny user base. Probably just you, and even you would be bored of it after 1week. Would it be worth it for Slack to invest millions in an external API just so a couple hundred geeks can make their own crappy client? 3-Analytics. Slack runs analytics on usage of their app, in order to know what users use and want. Can't do that if you don't own the frontend. 4-Brand. If one of your main competitive advantages is a good UX (And believe me, it is the case for Slack), would you want to grant people the right to create crappy apps that ruins the UX and turn people off your product? This is what is killing Android brand value for example. Sure it's open, but it means there are a lot of Crappy UIs that turn people off. The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company, so incentives are aligned to some extent, and very unlikely to be completely opposed as you seem to suggest. So yes, I believe that companies are taking strategic decisions (such as not shipping an external API and 5 different native clients) in large part because it does indeed benefit the majority of their users.
    - palata 3y ago
      1- I would hope that they already maintain and protect their private API against attacks (it has to be exposed to the internet, right?), and that they keep backward compatibility for the ElectronJS (and isn't the Android app native?) that are not updated out there. You forgot to mention something like "they would have to invent access control", to which I would answer that they already need that. They would literally just have to open their API to third parties. I doubt this would cost millions. 2- Don't assume too much. I use IRC from a CLI. But anyway you are just repeating your previous point, which is that you think it would cost millions. 3- Well, they would know what the third-party apps use in the API. They could also provide integrations for most popular languages, and those would send telemetry (what do you think the Google Play Services do?). For my crappy app, probably they don't need to know what I do, I am just a useless geek as you said. 4- Counter example: I was always able to connect my crappy app to my GMail account, and it did not prevent GMail from essentially taking over e-mail. But the couple hundred geeks who don't like the web frontend can use their crappy e-mail app, and everyone is happy. > The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company. Respectfully, that is the most naive comment I have read today. I don't even know where to start answering that, so I'll just pass :-).
dathinab 3y ago
Idk. I have electron programs running which take up much less residual memory. I do have slack running in my browser thou and the whole browser running slack and outlock360 and a bunch of other tabs uses 600MB of residual memory of which ... 324MB is used by slack ... so I would say it's more of an slack then a electron problem. AFIK the overhead of electron is around 100MB per-program this is still bad, sure, but far less worse then what you describe.
nottorp 3y ago
> Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You forgot about the times when two or more of the electron applications you run because you have no other option decide to take 20% CPU each or more. Even if you make it a point of pride to run a computer that eats power measurable in kilowatts per hour, that's bad when on battery at least. And from the article: > One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron. What's the difference? It will still end up eating all that ram and needlessly refreshing the cat gifs someone posted a day and a half ago.
- jraph 3y ago
  > What's the difference? The code of the web engine can be shared among several apps, instead of each of them having its own copy in RAM, making it less of an issue when having several of them. If each of them don't abuse RAM usage of course. Which is a big if of course.
  - nottorp 3y ago
    The .so is shared. All those uncompressed cat gifs, no. I'm not familiar with internal browser architecture, but do they make at least a token effort to not render/run attached javascript for elements that are not currently in view? I haven't measured, but my gut feeling is Electron apps go extremely crappy when you have like 30 memes in a row in a chat channel and make the mistake of switching to it. Edit: hey, what happens when you open a 500 M log file in vscode?
    - pwdisswordfishc 3y ago
      There is not such thing as ‘attached javascript for elements’.
      - nottorp 3y ago
        There should be. So it can be turned off when the element is not visible.

creshal 3y ago

Discord is not working "perfectly fine" on desktop for many people. Usually, the browser version is faster, needs less resources, has fewer platform integration problems (mic/camera access etc.), and crashes less often. And has less critical security vulnerabilities, as a browser gets patched much faster than Electron in general, and Discord in particular (who tend to be on an older branch, due to some native C++ libraries, that as far as I can tell have no user-visible impact). And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.

255kb 3y ago

I maintain an open-source app built with Electron. It serves tens of thousands of users every months and nobody complained in 5 years that it is being built with Electron. Not saying that Electron is perfect, and that it couldn't be a bit more performant, but as a solo maintainer (and entrepreneur) it helps me ship something that save people time. The burden of maintaining an application is already huge. Having to juggle with multiple environments would be a hassle and I definitely wouldn't do it. That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet. The app, if you are interested: https://mockoon.com https://mockoon.com

razemio 3y ago

I feel so too. There are currently no valid alternatives I know to electron. It is sad, but this is the current state of UI frameworks, if you are targeting cross-platform with identical look and feel. Also electron comes with its own advantages which many on HN seem to forget. code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.

BiteCode_dev 3y ago

While I appreciate VSCode, I think Discord, Slack and Obsidian are not selling the platform at all. They feel sluggish and have poor ergonomics. Now the second one may or may not be attributed to Electron depending of if you buy the cultural thinggy, but the first one clearly is. Mumble is super reactive in comparison to them, and most note softwares dance around Obsidian. Having a latency on local clicks and transitions is not my idea of fun. VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.

Capricorn2481 3y ago
I can't imagine anyone calling Obsidian sluggish. Do you perhaps have a lot of plugins?
- BiteCode_dev 3y ago
  Open sublime text side by side, and it will be obvious.
  - Capricorn2481 3y ago
    Well sublime is amazing, and trying to build an Obsidian equivalent in Sublime would be astronomical work. For what it is, Obsidian is very impressive.
IceSentry 3y ago
These things are all very subjective. Not everyone is affected the same way by latency. I hear people complaining about it all the time on thw internet, but in practice I never notice it and I don't know anyone that does either. Ergonomics is the same, I think discord is really nice to use and all the alternatives I've used have been worse. To be clear, your opinion is absolutely valid I just don't think they apply equally to everyone.
- BiteCode_dev 3y ago
  It's probably a generational thing. The 20 last years, the web, the animations and the badly coded apps lead people to be used to slow software. However, when you have used software for decades on much less powerful hardware, the sluggishness of all of it is kinda jarring.

theappsecguy 3y ago

Electron is ok. Not the best, but not as bad as some people claim it is, though it varies app to app. I feel the same way about React Native.