7 ms·

Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs pu

Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs put in a lot more effort in the app in general based on my anecdotal evidence. It is also more performant and smaller in size, things that I cherish. It also pays homage to limits and striving to come up with new ways of overcoming them, which hackers would have to do in the past. I don't think not worrying about memory, CPU, etc are not healthy in the long run. Slack desktop app is almost 1 gig in size. That is crazy to me, no matter the "memory is cheap" mantra.

airstrike 6y ago
Bonus points if it includes offline documentation. As nice as it is to have "updated" online docs, the reality to me seems to be defined more by broken links than by actual up-to-date documentation.
ttoinou 6y ago
1 gig for Slack ? I count < 300 MB on my Windows C:\Users\[MY USERNAME]\AppData\Local\slack counting app-4.5.0 and packages folder And currently taking < 300 MB RAM
- developerdylan 6y ago
  185MB on mac.
- jbverschoor 6y ago
  "storage is cheap" "memory are cheap" "cpus are cheap" Say the same people who spend a million on AWS every year
SllX 6y ago
Agreed. If you have a CPU from 2012 onwards, 16GB of RAM and an SSD, that’s a respectable hardware setup. It might not be the fastest piece of kit on the planet, but I don’t see any reason why it couldn’t last another 3 to 5 years without feeling slow. Electron apps invariably make such kit feel slower than it actually is. You can get good performance out of even older hardware if you treat it well and load it with good software that respects the hardware.
- toomuchtodo 6y ago
  I type this from a 2014 MacBook Air with 8GB of ram, still going strong, no upgrades except a battery replacement. Everything is still as snappy as the first day I got it. No electron apps!
- dx87 6y ago
  Yep, the new Steam library being a bloated web app is what forced me to install more RAM. I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use. Then they update the library to the new bloated version, and my computer starts freezing because the library memory footprint is so much larger that my computer was having to use over a gig of swap space.
  - karatestomp 6y ago
    I have a rig powerful enough to run a lot of last-gen games at 4K with high quality settings, and a lot of current-gen ones at mid to high settings and 1080p. The fucking redesigned Steam library lags, none of the animations (why does it need animations?!) are even close to smooth, and there's massive delay on every input. I've never once encountered a move toward webtech, or toward heavier and "appier" JS use in something that's already webtech, and gone "oh good, this works much better now, I'm so glad they did that."
    - Groxx 6y ago
      And somehow it's still dramatically better than the Epic Games launcher. I don't know what these companies are doing. Clearly they're not paying attention though. This is not merely low-hanging fruit that's going ignored, it's watermelons.
  - biggestdecision 6y ago
    >I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use. That sounds like your problem. And I refuse to believe that the new steam UI uses 2gb of memory.
ryukafalz 6y ago
I agree, in part because of performance, but also in part because I value being able to bootstrap from source as much as possible. There are only a few projects seriously working on this, one being GNU Guix: https://guix.gnu.org/ https://guix.gnu.org/ The trouble with Electron apps though (and most Node apps) is the sheer number of dependencies. It's just infeasible to package them for a distro if you care about their dependencies being packaged as well - at least, not without the entire process being automated.
egypturnash 6y ago
Slack desktop app is almost 1 gig in size. On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs. And Ripcord (a native discord/slack client) is a mere 40.
- deleted 6y ago
  [deleted]
- lytedev 6y ago
  ooh I'll have to check out ripcord!
  - thewebcount 6y ago
    I use it daily. It's OK. It's better than having a full electron app/browser running, but it's fairly incomplete. (For example, in Slack I can't find a way to set my status.) I also have to reauthenticate every Monday morning which means launching Slack in a web browser to grab my credentials. It's a pain.
  - ivanfon 6y ago
    I've found it's great for Discord, and pretty good for Slack (although I've been using Slack in my browser now that it's become critical during WFH). Unfortunately it's proprietary, but there's another native client called gtkcord3 [0] that seems to be progressing well. 0: https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3
- DaiPlusPlus 6y ago
  And Winamp is 4MB (after removing the stock plugins that I don’t need, like modern skins and the long-broken media library internet lookup stuff). How big is Spotify now?
  - jleahy 6y ago
    Spotify is 273MB (on Linux at least), 70MB for the binary and 137MB for Chrome, plus some other bits and bobs. $ pacman -Qi spotify Name : spotify Version : 1:1.1.10.546-4 Description : A proprietary music streaming service Architecture : x86_64 ... Installed Size : 272.79 MiB So at least it's smaller than Slack.
BubRoss 6y ago
It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but creating crazy O^2 algorithms that run on every frame with memory allocations that run in the inner loop. At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant. These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386. People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.
- ghettoimp 6y ago
  I strongly disagree with the idea that lower level is better. Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go. But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility. If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort. The correct choice depends almost entirely on the domain.
  - hootbootscoot 6y ago
    How about "being aware of what your abstraction layers cost, and being palpably aware of every needless contortion you create" know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c" For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code. Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO? Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least. Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions. Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code. Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.
seventh-chord 6y ago
The "<resource> is cheap" mantra also really only makes sense if you are writing server code, where you yourself pay for all the memory your code will ever use. If you deploy code to a large number of users it makes little sense. If a million users start your app daily, and your app has a 5 second load time and uses 300mb of ram, you are wasting over 50 days of user time, and hogging close to 300 terabytes of ram.
- hobofan 6y ago
  So you are telling me that I can easily exchange development time which I would have to pay for end-user resources, which I would not have to pay? Sounds like a great deal.
  - dialamac 6y ago
    In a fair society it should be taxed as an externality. There is a real environmental cost associated with software bloat.
    - pkalinowski 6y ago
      People pay with electricity, uncomfortable temperature and fan noise, wasting time working on slow apps. Apparently, they trade off still worth it, as many electron apps are popular despite these issues. Many times there is electron app or nothing.
      - p_l 6y ago
        Your last sentence hits the nail - many users don't have a choice in selecting the application, and due to industry fads can't expect to have a better option. I can make a great chat system that uses fast native client, but it won't change the fact that Corporation A paid for a slack license and won't switch to mine.
    - hobofan 6y ago
      Then I hope we would also tax the bad UX of the competing 20-year old Frankenstein applications, which lead to slower business processes (= more resources used as well).
bobblywobbles 6y ago
I admire your words here. I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks. I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.
- mingabunga 6y ago
  I agree too, and your average user is not going to care about the fact you've used Electron, or even know. It's a big win for development.
  - thewebcount 6y ago
    I disagree. I mean they may literally not know that your app uses Electron, but they'll certainly have the feeling of, "Oh, that janky app that doesn't quite work correctly and makes my system slow."
  - criddell 6y ago
    I think that might be true on Windows or Linux, but not on the Mac. It seems like Mac developers care more about making their application feel good to use.
  - giulianob 6y ago
    Your average user has just come expect technology to suck nowadays. Go look around and many people are jaded by how poor things actually function.
- smabie 6y ago
  When why not just use gtk or qt and call it a day? Electron is unnecessary.
  - joshbaptiste 6y ago
    Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.

airstrike 6y ago

Bonus points if it includes offline documentation. As nice as it is to have "updated" online docs, the reality to me seems to be defined more by broken links than by actual up-to-date documentation.

ttoinou 6y ago

1 gig for Slack ? I count < 300 MB on my Windows C:\Users\[MY USERNAME]\AppData\Local\slack counting app-4.5.0 and packages folder And currently taking < 300 MB RAM

developerdylan 6y ago
185MB on mac.
jbverschoor 6y ago
"storage is cheap" "memory are cheap" "cpus are cheap" Say the same people who spend a million on AWS every year

SllX 6y ago

Agreed. If you have a CPU from 2012 onwards, 16GB of RAM and an SSD, that’s a respectable hardware setup. It might not be the fastest piece of kit on the planet, but I don’t see any reason why it couldn’t last another 3 to 5 years without feeling slow. Electron apps invariably make such kit feel slower than it actually is. You can get good performance out of even older hardware if you treat it well and load it with good software that respects the hardware.

toomuchtodo 6y ago
I type this from a 2014 MacBook Air with 8GB of ram, still going strong, no upgrades except a battery replacement. Everything is still as snappy as the first day I got it. No electron apps!
dx87 6y ago
Yep, the new Steam library being a bloated web app is what forced me to install more RAM. I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use. Then they update the library to the new bloated version, and my computer starts freezing because the library memory footprint is so much larger that my computer was having to use over a gig of swap space.
- karatestomp 6y ago
  I have a rig powerful enough to run a lot of last-gen games at 4K with high quality settings, and a lot of current-gen ones at mid to high settings and 1080p. The fucking redesigned Steam library lags, none of the animations (why does it need animations?!) are even close to smooth, and there's massive delay on every input. I've never once encountered a move toward webtech, or toward heavier and "appier" JS use in something that's already webtech, and gone "oh good, this works much better now, I'm so glad they did that."
  - Groxx 6y ago
    And somehow it's still dramatically better than the Epic Games launcher. I don't know what these companies are doing. Clearly they're not paying attention though. This is not merely low-hanging fruit that's going ignored, it's watermelons.
- biggestdecision 6y ago
  >I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use. That sounds like your problem. And I refuse to believe that the new steam UI uses 2gb of memory.

ryukafalz 6y ago

I agree, in part because of performance, but also in part because I value being able to bootstrap from source as much as possible. There are only a few projects seriously working on this, one being GNU Guix: https://guix.gnu.org/ https://guix.gnu.org/ The trouble with Electron apps though (and most Node apps) is the sheer number of dependencies. It's just infeasible to package them for a distro if you care about their dependencies being packaged as well - at least, not without the entire process being automated.

egypturnash 6y ago

Slack desktop app is almost 1 gig in size. On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs. And Ripcord (a native discord/slack client) is a mere 40.

deleted 6y ago
[deleted]
lytedev 6y ago
ooh I'll have to check out ripcord!
- thewebcount 6y ago
  I use it daily. It's OK. It's better than having a full electron app/browser running, but it's fairly incomplete. (For example, in Slack I can't find a way to set my status.) I also have to reauthenticate every Monday morning which means launching Slack in a web browser to grab my credentials. It's a pain.
- ivanfon 6y ago
  I've found it's great for Discord, and pretty good for Slack (although I've been using Slack in my browser now that it's become critical during WFH). Unfortunately it's proprietary, but there's another native client called gtkcord3 [0] that seems to be progressing well. 0: https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3
DaiPlusPlus 6y ago
And Winamp is 4MB (after removing the stock plugins that I don’t need, like modern skins and the long-broken media library internet lookup stuff). How big is Spotify now?
- jleahy 6y ago
  Spotify is 273MB (on Linux at least), 70MB for the binary and 137MB for Chrome, plus some other bits and bobs. $ pacman -Qi spotify Name : spotify Version : 1:1.1.10.546-4 Description : A proprietary music streaming service Architecture : x86_64 ... Installed Size : 272.79 MiB So at least it's smaller than Slack.

BubRoss 6y ago

It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but creating crazy O^2 algorithms that run on every frame with memory allocations that run in the inner loop. At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant. These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386. People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.

ghettoimp 6y ago
I strongly disagree with the idea that lower level is better. Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go. But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility. If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort. The correct choice depends almost entirely on the domain.
- hootbootscoot 6y ago
  How about "being aware of what your abstraction layers cost, and being palpably aware of every needless contortion you create" know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c" For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code. Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO? Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least. Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions. Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code. Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.

seventh-chord 6y ago

The "<resource> is cheap" mantra also really only makes sense if you are writing server code, where you yourself pay for all the memory your code will ever use. If you deploy code to a large number of users it makes little sense. If a million users start your app daily, and your app has a 5 second load time and uses 300mb of ram, you are wasting over 50 days of user time, and hogging close to 300 terabytes of ram.

hobofan 6y ago
So you are telling me that I can easily exchange development time which I would have to pay for end-user resources, which I would not have to pay? Sounds like a great deal.
- dialamac 6y ago
  In a fair society it should be taxed as an externality. There is a real environmental cost associated with software bloat.
  - pkalinowski 6y ago
    People pay with electricity, uncomfortable temperature and fan noise, wasting time working on slow apps. Apparently, they trade off still worth it, as many electron apps are popular despite these issues. Many times there is electron app or nothing.
    - p_l 6y ago
      Your last sentence hits the nail - many users don't have a choice in selecting the application, and due to industry fads can't expect to have a better option. I can make a great chat system that uses fast native client, but it won't change the fact that Corporation A paid for a slack license and won't switch to mine.
  - hobofan 6y ago
    Then I hope we would also tax the bad UX of the competing 20-year old Frankenstein applications, which lead to slower business processes (= more resources used as well).

bobblywobbles 6y ago

I admire your words here. I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks. I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.

mingabunga 6y ago
I agree too, and your average user is not going to care about the fact you've used Electron, or even know. It's a big win for development.
- thewebcount 6y ago
  I disagree. I mean they may literally not know that your app uses Electron, but they'll certainly have the feeling of, "Oh, that janky app that doesn't quite work correctly and makes my system slow."
- criddell 6y ago
  I think that might be true on Windows or Linux, but not on the Mac. It seems like Mac developers care more about making their application feel good to use.
- giulianob 6y ago
  Your average user has just come expect technology to suck nowadays. Go look around and many people are jaded by how poor things actually function.
smabie 6y ago
When why not just use gtk or qt and call it a day? Electron is unnecessary.
- joshbaptiste 6y ago
  Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.