31 ms·

Doing work locally minimizes problems with Electron apps

285 points by jlongster 7y ago

Sahhaese 7y ago
I'm not an electron hater, but when only using 300mb of memory while idle is something to boast about, they may have a point.
- jlongster 7y ago
  Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB. It goes on to say that there's a memory-intensive piece that I haven't even optimized yet and will rewrite into Rust which should bring the memory down a lot more.
  - loljabab 7y ago
    Its interesting that slack takes 1gb+ memory. Slack still uses the OS provided webview, right? That seems like the right way to do it (last time I used Slack, it was a 3mb download - glorious), but how is it using so much RAM? maybe its leaky?
    - jlongster 7y ago
      My guess is Slack likes to keep pages around, and each workspace is a separate page that are individually pretty heavy. So if I'm logged into 4-5 workspaces that adds up quick. Slack does not use the OS webview, it is Electron. I don't think it's a 3MB download - if it is it must just be an installer that installs the real thing? I haven't looked recently.
      - loljabab 7y ago
        It has been years so youre probably right. Bummer. That explains the ram usage. I do prefer the webview approach because I don’t need/want my chat app to bundle a browser :-/ Ive been a web and native app dev for a decade and do not agree that developer convenience could ever justify these sorts of choices. My webview backed native apps are all sub 1mb and I have no trouble developing them. I guess I just dont get it.
    - butteroverflow 7y ago
      Are you sure those 3 MB were not just a web installer?
    - wlesieutre 7y ago
      Electron ships its own Chromium-based browser view. Using the OS provided one does sound like an efficient option, but then you have to deal with all the same compatibility testing (different browsers, different releases, running under different OSes and OS releases) that makes web development suck. It's trying to provide a web-based stack while abstracting away most of those headaches. It also provides some Chrome specific functionality (loading Chrome extensions) that wouldn't work in an engine-agnostic system, though I don't imagine this is a commonly used mechanism. Extensions are more useful for shoving your own functionality into someone else's webpage, if you control the whole codebase surely it's not the best way to do anything. https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath https://electronjs.org/docs/api/browser-window#browserwindow...
      - monksy 7y ago
        > but then you have to deal with all the same compatibility testing Which means they choose the wrong way to go about creating an app. If you have to bundle a huge secondary app just to run your main application, you've done something wrong.
        coldtea 7y ago
        If you have a multi-billion valuation while doing it, and millions of users, you could not care less...
    - danShumway 7y ago
      As someone who uses Slack only in the browser and not as a native app, Electron is not the reason Slack is slow. Electron doesn't help, of course. But Slack seems to either cache a lot of stuff, or have memory leaks, or something. It's weird, because Slack seems to re-fetch data whenever I switch rooms, so I'm not sure what all that RAM is being used for.
    - krzyk 7y ago
      Not every OS has a "provided webview", Linux doesn't, not sure if MacOS does.
      - mthoms 7y ago
        MacOS does (WKWebView)
      - yjftsjthsd-h 7y ago
        Doesn't it? I would say that WebKitGTK counts.
        krzyk 7y ago
        You need to install it first, there are multiple Linux distributions
  - weego 7y ago
    Making electron, the entire point of which was to lower the barrier to entry to app development, even vaguely reasonable in terms of memory use by having to code in Rust which is very much not low barrier to entry is an irony that strikes exactly to the heart of the point the person was making.
    - jlongster 7y ago
      I don't get what you are saying. Using 230MB of memory for a very data-heavy app is already somewhat reasonable, and more advanced optimizations are going to require more advanced engineering. It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725
      - Scarbutt 7y ago
        I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
        fjp 7y ago
        Every single transaction on every account they have for starters, plus a data point for the total in the account at the end of each day I would imagine, plus all metadata you could ever want to associated with a transaction
        _dps 7y ago
        Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)
    - derefr 7y ago
      Electron lowers the barrier-to-entry for frontend app development. Or, more cynically: Electron allows you to hire cheaper, less-experienced frontend engineers. A background worker in an Electron process, however, can be thought of (depending on what it’s used for) as more of a “local ambassador of the server”, and thus isn’t really “frontend” at all. It lands on the client, sure, but it’s no more frontend than the client-side half of the Firebase library is frontend. It’s plumbing, and so it’d be the responsibility of a backend or infrastructure engineer to write and maintain. If you take this perspective, you still receive the main practical advantage that the system’s product manager was probably seeking by choosing Electron in the first place: the ability to hire inexperienced engineers to do UX tweaks, freeing up the senior engineers’ time to handle the hard stuff. UX tweaks won’t generally bubble down to the level of needing to modify the background worker (again, depending on how you’ve written the thing), so your [junior] frontend engineers won’t need to touch the background worker, so it can be written in a language more on the “good engineering” side of the spectrum than the “low barrier to entry” side—like Rust—without that causing you any headaches of the “everybody who knows how to fix it is busy” variety.
  - coldtea 7y ago
    >Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB. You're not making it any better...
  - dang 7y ago
    "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."" https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- CharlesW 7y ago
  It's relative. Outlook is using 2.37 GB of RAM as I type this.
  - Sahhaese 7y ago
    That's odd, OUTLOOK.EXE is using 44MB of ram as I type this and has been open for 7 hours.
    - LandR 7y ago
      Same here, Outlook has been open from 9am > 4pm and it's using 64MB.
    - toyg 7y ago
      Maybe a Mac. My Outlook on mac is idling at 150MB.
      - CharlesW 7y ago
        Yes, this is Office 365 on macOS. Neither the computer nor Outlook have been restarted in weeks, which is surely contributing to its current RAM footprint.
    - GrinningFool 7y ago
      Is it minimized? IIRC on Windows, when an application is minimized the working set is trimmed which can result in a significant reduction - but it jumps back up when you start using the application again.
  - jeroenhd 7y ago
    That too is relative. My copy of Thunderbird with 6 open emails from six open mailboxes is consuming about 170MB of memory right now, and that's hosting a fully-featured browser to view emails. Granted, that's reserved memory, but that's the only memory you really need to worry about anyway. Of course, native doesn't make a program automatically use less RAM. It does start with a lower footprint through, meaning that you can keep an eye on memory usage without relying on ugly hacks in your code.
chrisweekly 7y ago
Thanks for sharing! Your post is full of things that might seem obvious in hindsight, but all too likely to be ignored absent a compelling writeup like yours. Bookmarked the linked repo, will revisit w/ my next Electron app.
edoceo 7y ago
I am an electron hater but this is a really good setup. Server reloading with that debugger is rad. I'm going to use these methods with a platform I don't like.
toyg 7y ago
300mb of memory to do a bit of money-counting, which you could probably do equally well with MSVC in 2mb. Such a wasteful world.
- castis 7y ago
  thats 300mb across several completely necessary helper processes. garbage in, garbage out
  - favorited 7y ago
    garbage collected
- chasd00 7y ago
  In the author's defense, it's just an example he was using to explain a development setup and some techniques. You can also do a factorial on a sheet of paper at 0mb RAM
  - jlongster 7y ago
    The 230MB (not 300MB) is from my real app Actual. The example project uses much less because it does nothing except start electron, which looks like it uses about 80MB baseline.
- AlexandrB 7y ago
  My favourite example is Etcher[1] which is effectively a GUI for "dd" and ships as a 227MB "app" that uses >200MB of RAM idling. "dd" is 37KB. [1] https://www.balena.io/etcher/ https://www.balena.io/etcher/
  - kbumsik 7y ago
    Etcher is okay to me because you won't run it in background, you are gonna close it right away after flashing anyway. BTW comparing an GUI app with a CLI-only program sounds unfair.
  - 7y ago
falcolas 7y ago
IMHO, good electron apps feel and behave like native apps. Or, in the worst case scenario, they feel like an equivalent web app. Specifically - I should not have to think of having to “ctrl-R” for a desktop application. Good electron apps do exist, but they feel like a vast minority. Most just feel like a bloated version of their web application.
- jlongster 7y ago
  I completely agree! Are you referring to the "ctrl-r" to reloading the server in the article? That's only for development - the user never has to refresh the app like that of course!
  - falcolas 7y ago
    I think you’re saying “a user should never have to refresh the app”. Because ctrl-r has returned completely borked applications back to working. Specifically, I’ve had to use it almost daily to make slack recover from a freeze.
    - jlongster 7y ago
      Oh, yeah that's stupid. cmd+r or ctrl+r for refreshing doesn't even work in my electron app because it doesn't make sense for a desktop app.
    - btsheehy 7y ago
      I'm not sure what the point is, here. Is it that Electron apps can lock up or crash? That they can be refreshed seems pretty immaterial, given that any application in any language can crash
- yoz-y 7y ago
  > IMHO, good electron apps feel and behave like native apps. I second this, but there are a few reasons why they can't. For example Blink does not respect MacOS highlight color setting so any electron app won't either. I should not be able to select text in parts of interface (e.g.: text inside a button), but it is pretty common that a cmd+a selects everything including interface. Buttons should be in the correct order and have correct highlights depending on the platform.
jlongster 7y ago
I'm the author of the post and I should also say that I don't love Electron. It's a practical choice for getting an app of the ground, but I want something more lightweight eventually. I see it as a stop-gap until I can invest more resources into something more lean. But I'm focused on the product right now, not rewriting the world and wasting time because of engineering ideals.
- grecht 7y ago
  That’s the right mentality. I'd say don't change it if it works (and is nowhere near as bad as Slack). If the difference in practice is marginal it‘d provide no real value.
- makkesk8 7y ago
  From looking at your electron-with-server-example hastily, I would imagine adding typescript is not an issue?
  - jlongster 7y ago
    I don't actively use typescript, the example is focused solely on the architecture for adding a background process. Typescript seems like a separate concern?
- ulfw 7y ago
  I agree with your statement but just have never really seen it work that way in real life. Slack is the best example. An app that just 'works' in Electron and the stop-gap became the permanent solution for eternity et voila -> still huge valuation and IPO. I am afraid once you go Electron, most will stay Electron.
  - jlongster 7y ago
    Whatever it ends up being it has to be web-based. I'm definitely not going to rewrite the app. However, if something were to come along that uses the user's local webview instead and provided a way to bundle a node server with it, I could absolutely switch to it. In fact, I've played with the idea of providing an app that only sits in your menubar and runs the server, and opening the app just opens a tab in your browser. But most users don't care as much about all this as we think and would find that odd. You're right though - if something is working well enough it probably will end up sticking. Slack just goes to show that it's probably Good Enough despite what we feel about it.
chasd00 7y ago
I've never noticed Electron apps negatively impacting my computer. I use Slack all the time and I don't notice a difference when I have it running vs when i don't. Do most people not like Electron because the number seems high or does it negatively impact their computer in some way? (I have a MBP with 8 gig RAM, that doesn't seem out of the ordinary)
- yoz-y 7y ago
  As for impact it depends. Slack is not that bad except that it is slow (for example switching teams was sluggish when I was using it). But when I run Slack, Skype, Insomnia and VS Code at the same time I definitely saw the impact. I had 16Gigs of ram but half of that was eaten by a VM all the time.
- luckylion 7y ago
  I don't like Slack for that reason, but it's a Slack issue, not Electron. Other Electron apps (vscode, keeweb for example) aren't that resource hungry.
- ckuhl 7y ago
  It definitely negatively affects the battery life of my 2018 MBP. Using only native applications, I can get a full days work done. If I have Slack open, usually I can only work until noon.
makkesk8 7y ago
Some people seem to think that unused ram is good, quite the contrary actually. If you have 50 of these apps running doing work while playing a game while having a pc from 10 years ago, then I can actually see a problem. Laptop and battery-driven devices is a whole other matter though. I like to think the reusability and speed of development with electron is just terrific and is a trade-off that is worth it in the end.
- falcolas 7y ago
  Unused RAM is good. It lets the OS do things like pre-fetching and caching disc reads. That is, it speeds everything up to not be using all of your RAM. Plus, when you do fill your RAM, you have to start contending with swapping, which slows everything down significantly.
  - makkesk8 7y ago
    Swap is not enabled by default by any OS that I know of. And I doubt any OS requires you to have several gbs free in order to work smoothly. My point being is, we are not stuck with 2 gbs of ram anymore and like games, apps will scale to use more resources for ease of development or better features.
    - VonGallifrey 7y ago
      As far as I am aware both windows and linux (several distros) use swap by default. On windows it will be a file on the C drive and on Linux it will be a swap partition. Of course they are not going to swap unless they have to, but they will swap in default configuration.
    - michaelmrose 7y ago
      Literally every major OS in existence has swap enabled by default. Linux, Mac, windows. The alternative is for things to start crashing when you run out of memory rather than swapping out.
      - 7y ago
emptyparadise 7y ago
I miss native apps.
grecht 7y ago
I use VS Code and it never felt sluggish. But it’s probably one of the best Electron apps out there. Honestly, if I had to develop a Desktop app today and wanted it to be cross-platform, I’d probably use Electron. No need for hacky workarounds like in a web app to make it run on every major browser.
- 0xffff2 7y ago
  I use VS Code too and it's extremely sluggish compared to a text editor like Sublime. I use it only because the plugin experience is much better than Sublime and the responsiveness is infinitely better than JetBrains' products.
  - hackandtrip 7y ago
    I find it not fair to compare VSCode to JetBrains' product: one of them is an IDE, the other one is an editor, different features and different targets!
    - 0xffff2 7y ago
      I disagree. VSCode is really a hybrid product. With plugins, it does intellisense and debugging, which are really the two major value-add features of an IDE for me. It's still light years faster than IntelliJ (and light years slower than Sublime). I switched from IntelliJ to VSCode and it minimally affected my workflow, so they're objectively not different targets in that regard.
      - winrid 7y ago
        Are there are VS Code intellisense plugins that beat Webstorm?
ionised 7y ago
I find the problem lies with the trade-off you are making. You are making your life as a developer easier in exchange massively increasing the resource requirements and battery usage on end-user machines. It's just bad practice and Electron encourages it. I feel like if we ever want to be taken seriously as a profession the way structural or mechanical engineers are for example, then efficiency and reliability need to be primary considerations, otherwise we are basically making toys.
- jlongster 7y ago
  I would easily forego the niceties explained in the article if it meant there were something better. The main reason to use Electron is that I can have happy macOS, Windows, and Linux users. Apps that focus on a single platform are exclusionary.
  - krzyk 7y ago
    You can have that already - use web, the real one, not Electron. Everyone then can use their favorite browser for your app, not forced to use Chromium. And if you want to make an efficient desktop app, look at telegram source code.
    - michannne 7y ago
      If the goal was to have an online-only tool, wouldn't that have been developed from the get-go?
    - jlongster 7y ago
      The web's offline support sucks, and don't tell me to use service workers. Actual is a truly offline 100% local app. Most users love that they can simply launch a desktop app and it always runs no matter their network connection.
IloveHN84 7y ago
First rule: if you need Electron, change your requirements/design and move to something more cross platform like Qt or libui/C++.
- matthewbauer 7y ago
  I would discourage libui… The bus factor is 1 right now. There is now guarantee it’s going to be around in a few years. Qt5 on the other hand has a large community around it.
- michannne 7y ago
  You forgot a number of additional tips: - Hire a C++ programmer - Learn C++ - Adapt knowledge in your current language of choice to C++/Python - Find a designer who can use Qt - Adapt common tools normally found in npm to C++ - Rewrite your application logic to run in C++ Should be simple for any dev to do considering the pay off is lower RAM and "native" look and feel
gfodor 7y ago
If electron apps' claimed memory causes your computer to go slow due to swapping, you should complain. But most complaints I see on this topic stem from a discomfort over the reported figure by the operating system. With SSDs and modern virtual memory systems the claimed memory figure is not a sufficient measure to infer the resource utilization of a process. For example, if slack has a bunch of allocated memory that is rarely accessed, it's going to (at worst) land on your SSD and sit there, having no impact on your user experience. If you want to complain about applications' engineering, you should complain not about claimed memory but about things that are directly affecting resource utilization or user experience like power draw or excessive CPU utilization due to poor programming. Claimed memory must be combined with a profile to show that cold reads are common enough for the claimed memory figure to be correlated with a performance hit. But of course, this often isn't readily available without profiling for all but the most extreme cases, and so engineering types fixate on easily visible measures like claimed memory that likely have no actual resource utilization impact in most cases.
- forgottenpass 7y ago
  >If electron apps' claimed memory causes your computer to go slow due to swapping, you should complain. But most complaints I see on this topic stem from a discomfort over the reported figure by the operating system. I tried that once. But I'm sick of having to fight that my usecase is valid, that my laptop isn't too old, and that it isn't broken/misconfigured in some other way. It's 4 years old, and I can't run 2 electron applications and firefox at the same time without swapping so hard I can't get anything done. Fuck me for asking so much from a computer, right?
  - iforgotpassword 7y ago
    No idea why you're getting downvotes. I think this actually is a problem in the dev world. They often have overpowered systems compared to the average user and as a result might not realize or simply don't care how their software performs on lower end systems. One example that's driving me mad is shotwell (photo managing software). For some reason whenever you start it, it is crawling your entire collection of photos again. There are countless rejected tickets from people asking to add an option to disable it. I personally manage my photos on an older laptop with a spinning 2tb drive, for when I travel... So I'm somewhere without a power outlet in reach, battery sitting at 12%, and would like to quickly show some photos to a friend, but opening up shotwell will make sure that remaining battery will be drained in an instant. But the neckbeards developing that software sitting in their basements with 4 SSDs running in raid 0 just fail to understand what my problem is. Sadly I haven't found a good replacement so far, feature wise. Edit: Also forgetting your password sucks ;-)
vijaybritto 7y ago
Unrelated: I really hope software like https://github.com/revery-ui/revery https://github.com/revery-ui/revery becomes mainstream! This node IPC debugging technique is pretty nice!
- seddin 7y ago
  What's the size of the built binaries?
bfrog 7y ago
The secret is don't use electron.
asdkhadsj 7y ago
So, I love the role that Electron fits, but boy do I hate how much we discuss Electron itself. What we should be discussing is providing the functionality of Electron without the cost. A protocol that behaves like React native. Ideally a spec, which any language can implement and provide a native UX to the end user. Some projects try (ProtonNative, for example), but I've not seen one go quite far enough. I don't want to be forced to write a JS app to get benefits here. After all, with ReactNative, it's basically a process RPC to a bunch of widgets. `process <-> UI`. So why be forced to write JS? An open spec would do wonders here. I've not invested cycles on solving this problem, of course. Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth. They're great projects, but a slightly wider vision would make them amazing projects. Thoughts? Am I missing something obvious?
- hexmiles 7y ago
  i really loved xul form mozilla. i build a lot of tiny apps with it, unfortunately it's no longer supported. I also used it to build the kind of bridge you mention, it was for dynamically build gui for cli apps that did job processing (but it was a basic bridge with few functionality), and also some crud form from the database schema.
- nexuist 7y ago
  >I don't want to be forced to write a JS app to get benefits here. Although most major Electron apps are written in node, it's pretty easy to have a backend in another (compiled) language. You can simply use the subprocess module in node and build your own bridge, for example to a Go CLI that accepts events from electron and does whatever you want it to do. It's a workaround for sure, but the point is you could do it in a pretty stable way. >After all, with ReactNative, it's basically a process RPC to a bunch of widgets >Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth I've used React Native in the past and I'm working on a Flutter app now. The problem with RN is that every platform has its own unique widgets. It's neat that you have one codebase, but you still need to build a separate UI (at least for certain pages) for Android and iOS. It just doesn't look right otherwise. Flutter gets away with this because it owns the drawing layer as well as the widget layer. I know that something drawn in Flutter is going to look exactly the same no matter where I run it. This means that widgets fail gracefully by default - in RN, things just straight up break or look weird. The worst that can happen in Flutter is that the user has to deal with an iOS picker on Android or vice versa. Electron is more akin to Flutter than RN in this way. It controls the drawing/rendering because of Chromium. Slack on Mac looks exactly like Slack on Windows. That's more enticing than needing to build new UIs for every platform you want to support. The only way to solve this is to basically invent another cross platform drawing layer. But why bother? HTML/CSS already exists. There's effort and tooling and docs and community and everything else you'd need for a successful framework. It's not worth the effort. I think the best solution will be just embedding Electron at the OS layer, so apps don't have to bring along their own Chromium runtime. This way it runs closer to the metal, which should help alleviate RAM and storage concerns (these seem to be the only major concerns most people have with it).
cpursley 7y ago
Thanks for the post. > I want something more lightweight eventually Check out https://github.com/revery-ui/revery https://github.com/revery-ui/revery
- jlongster 7y ago
  That's a very cool project (I've used OCaml before) and I hope it takes off. I should try it, but I admit I'm a little skeptical because there are so many details to get right like focus management, accessibility, and more. Unfortunately since I can't rewrite my project entirely, I'm going to need something that reduces bloat by using a local webview instead, so it's still web-based.
  - ori_b 7y ago
    The local web view is the bloat. The rest of electron is not the problem.
    - jlongster 7y ago
      ? A local webview usually means that it reuses the user's already installed browser and uses that instead.
      - ori_b 7y ago
        The browser I have installed is the single most resource intensive program I have on my computer.
        iforgotpassword 7y ago
        Why? Because you picked a particularly bad one or because you have 200 open tabs? Usually the browser is running anyways so adding another open tab or window increases resource usage much less than another program shipping its own browser engine.
        7y ago
mhd 7y ago
The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the average RAM at the time they were accused of bloat] It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc. Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign. In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).
- jlongster 7y ago
  I agree with this too but this problem can be addressed by caring. I care. You can find a bunch of non-native interactions in my app but every time I work on it I make it better and implement more of a native feel (like disabling selecting text when you shouldn't be able to, etc). It's a balance - personally I think apps that focus on a specific platform is exclusionary. So accepting some non-native feel means more people can use my app. I agree that browsers make it hard though.
  - mhd 7y ago
    I'd argue that despite all cries about non-native styling and behavior, MacOS Classic, OS X, Windows 95, OS/2, Next, Swing etc. had more in common with each other than they do with webapps (unless we're talking about ExtJS enterprise apps or the like). This won't matter as much for rich-text chat apps or the like, which always looked horribly non-native, over-styled, skeuomorphic (cf. Trillian)… But let's picture a database client or IDE. Those used to resemble regular desktop apps. Nowadays? Note that I'm not arguing about your article or even approach, I was just chiming in on the dislike for Electron in general, where I think bloat is the least of our worries. All this wasn't something new, the downturn of desktop UIs started way before, as people are now used to mobile and webapps and expect that kind of look and feel everywhere. The OS manufacturers definitely seem to approve and comply. You saw this happening in other places, before. Just look at enterprise Windows applications that were targeted to people used to terminal UIs (3270, VT220). Current UI trends are the same, just with spurious rounded corners instead of closely-grouped form elements…
draw_down 7y ago
At least for Slack, you don't have to worry about this if you just run it in a web browser. Because it's a web app. Seems like good advice though.
wlesieutre 7y ago
Electron discussions often focus around the battery and memory impact, one other thing I'd mention is the poor access to native features. You get the stuff a web browser can do, but for anything else offered by the OS you might need to wait a while. For example, Apple shipped their first TouchID laptop in 2016, and Electron's support for that landed in v6.0.0 beta 1 just last month. https://electronjs.org/releases/beta?page=2#6.0.0-beta.1 https://electronjs.org/releases/beta?page=2#6.0.0-beta.1 I'd looked at switching off 1password to BitWarden and that's a pretty major feature to be missing for three years. Surprisingly, for as much as everyone craps on the touchbar, that got supported by Electron a lot faster than TouchID did. I guess because not all apps need authentication and they can rely on passwords instead, while it's really obvious when an app doesn't have touchbar support.
- jbverschoor 7y ago
  Not with nativescript.. you just use the brand new api
  - mthoms 7y ago
    Does nativescript do desktop? Their site seems squarely focused on mobile (iOS/Android).
- kitsunesoba 7y ago
  There’s system feature absences that bleed over from Chrome, too. One that comes to mind is the total exclusion of the numerous bits of functionality that macOS provides in text fields, a great example of which is how Chrome has lacked support for macOS text substitution for coming up on a decade now. https://bugs.chromium.org/p/chromium/issues/detail?id=42434 https://bugs.chromium.org/p/chromium/issues/detail?id=42434
fmakunbound 7y ago
What are the 83 threads used for in that trivial budgeting application?
rmrfchik 7y ago
Not only memory is the problem with electron, but also app feeling. Skype left is the only electron app I'm using. And comparing to desktop messaging app (telegram): 1. Skype unresponsive. Opening chat takes up to few seconds. 2. I see how opened chat is literally updating -- messages, avatars, emoticons emerges from dust 3. Selecting messages as messages in native vs selecting messages as text with surrounding artefacts (chat is a html page with all what comes with it) Summarizing, electron apps are just feels like foreigners.
adgasf 7y ago
People love to bash Electron, but what is the alternative? Is there any other platform that provides: - Support for the 3 major desktop platforms from one code-base; - A decent choice of high-level programming languages (there are excellent compile-to-JS options now); - Reasonable tooling and community support; - MIT (or similar) license
- barking 7y ago
  Lazarus, Pascal only, but otherwise it ticks your boxes I'd say.
- danieldk 7y ago
  Qt. Supports Linux, macOS, and Windows. Supports at least one high-level programming language very well (Python). Has good tooling and a lot of support. It's LGPL, which is fine for most cases. But you could always buy a commercial license.
  - golemiprague 7y ago
    What about the web? Electron apps can usually run also as web apps, can QT do that?
- c-smile 7y ago
  Sciter (https://sciter.com https://sciter.com) - Support for the 3 major desktop platforms from one code-base; - A decent choice of high-level programming languages... C/C++, Go, Rust, C# and other .NETs, Delphi, Python as host languages. - Reasonable tooling and community support Whatever host language provides. - License: Sciter is free to use in binary form. Contained in single dll/so/dylib without external dependencies. Size of DLL is 5-10 mb. Can be statically linked into host (C/C++) application to create monolithic executable.
  - deleted 7y ago
    [deleted]
- steve1977 7y ago
langitbiru 7y ago
The hate for Electron is strong in this thread. For Electron haters, here are the alternatives: OpenJFX (some people hate Java), Qt5 (it can be pricey in some situations), wxWidgets (not popular enough?). However, I have a lot of hope for Flutter in desktop. I hope the developers of Flutter framework can pull off the challenge. In my case, for opensource projects, I definitely use Qt5 (using PySide2). But for proprietary projects, I have to admit that most likely I will choose Electron.
- Narishma 7y ago
  AFAIK, as long as you don't modify Qt itself, you can use it just fine for proprietary projects without having to buy a commercial license.
fabiospampinato 7y ago
It sounds like a generally good approach for keeping the UI process responsive at all times. I wonder if the serialization cost behind all those IPC calls becomes an issue at some point, especially when passing large structures back and forth, have you found this to be an issue for your use case?
- swiley 7y ago
  Doesn’t (or didn’t?) X11 work by serializing every drawing operation and doing IPC? That’s been used on very old machines and is very responsive.
  - ptx 7y ago
    The MIT-SHM shared memory extension was added pretty early on. And nowadays (in GTK etc.) everything is drawn on the client side and sent over as a bitmap. The old-style serialized drawing commands model is only responsive when you have a very simple UI that doesn't do much drawing.
- jlongster 7y ago
  I haven't noticed an issue - the only alternative would be to block the renderer and do it in the same process. The IPC uses a local domain socket which is very high performance (better than a web socket) so any overhead is quickly made up for with UI responsiveness. There may be specialized cases where it is a problem and you'll have to figure something out.
  - codesushi42 7y ago
    How do you secure the socket and prevent a malicious process from connecting to it?
skrebbel 7y ago
I feel like the key idea here is somewhat unrelated to writing Electron apps. It's that you can set up any Node server app to run inside an Electron window during development and then you get cmd+r and all the devtools for free. Kind of like a node inspector on steroids. Pretty nifty!
UtahDave 7y ago
Vote for Linux support in Actual here: https://trello.com/c/A7XzJgJX https://trello.com/c/A7XzJgJX
- jlongster 7y ago
  Linux support was added in 0.0.99! See here (and download it): https://github.com/actualbudget/releases/releases/tag/0.0.99 https://github.com/actualbudget/releases/releases/tag/0.0.99 Somehow that card didn't get moved to done, sorry! Let me know if it doesn't work.
m48 7y ago
Obviously bundling nearly all of Chromium with an app is inherently inefficient, but out of curiosity's sake, has there been any objective analysis of exactly what makes this use a seemingly disproportionate amount of resources? Are JavaScript runtimes inherently inefficient? Is it Electron's node.js part? Is it the huge amounts of code needed to parse and render HTML and CSS? Is it the multimedia features, like WebGL and the video and audio players? Is the problem actually just badly written code running on top of Electron? And if so, what exactly are are most Electron apps doing wrong that one could avoid? Is it, as this blog post seems to suspect, that they aren't sufficiently taking advantage of Electron's node.js integration? In addition, once the actual bottleneck has been identified, doesn't this open the door to fix things on the WebKit/Blink engine side of things? Before, when Electron was managed by GitHub, one could say this would be unreasonably difficult, but now that GitHub is owned by Microsoft, isn't tweaking Blink to be more suitable for deployment environments outside of Chrome exactly the type of thing they would have a vested interest in doing, and the resources to actually pull off? After all, with VS Code, they are one of the highest-profile Electron users, and using Blink in Edge presumably involves working with the Blink code to some degree anyway. It's always struck me that a lot of Electron apps likely never use a single line of WebGL, while a lot of WebGL apps likely only use DOM APIs to pretend the DOM doesn't exist by plastering everything in a huge <canvas> element, and both likely don't want their binaries to include the Chrome devtools, but Electron includes all of these things anyway. I'm not sure how much space or resources it would actually save, but is Chromium/Blink refactoring their code and build process to facilitate Electron building different Electron "profiles" that include different sets of features even remotely a possibility?
ptx 7y ago
If you need a background process to call Node APIs because "it's the only place where it's safe to access them", what unsafe way is this meant to contrast with? Does Electron normally (but unsafely?) call Node APIs from the browser process?
- jlongster 7y ago
  You can enable "node integration" with any renderer process and call node from their. But you definitely should not enable it in your primary renderer process if any untrusted code is running their (if you pull in any JS from anywhere else)
- deleted 7y ago
  [deleted]
geodel 7y ago
Well to me it is thing that should not be done at all, instead of doing it diligently. I will put this in category of 'The secret of good user tracking on web', 'the secret of doing quality journalism on ads supported model' or 'the secret of nuanced political debate on Twitter' etc.
michannne 7y ago
I'm building an application using Electron and I've found the majority of memory consumption occurs when instantiating new components. When using a UI framework like Material, this can happen frequently, such that the simple act of hovering over a menu and showing an indicator can cause an increase of 3 MB of RAM. I love Electron, it allows me to create applications in an intuitive way using a language meant for building UIs, rather than slapping a library on a native codebase, and I can deploy it wherever Chromium is supported, so I'd like to make it efficient, wherever possible. Two solutions I have found during my development: 1) Keep your components light. Most of what I used from Material can be done completely with raw HTML and CSS in a simpler fashion without much going on in terms of state, so I created my own components that serve my purposes. A lot of libraries and frameworks are heavy because they are used on webpages viewed by multiple different browsers and require complex logic to work across different environments. Electron sandboxes your code in Chromium + node, you code only for 1 browser engine, so I hope more devs take advantage of that fact. 2) Load what you know you need in the beginning, and keep your cache to a minimum. Most Electron apps do not have view transitions, they are built as SPAs. One of the downsides of this is that you need to be mindful of your cache since it is not cleared when you display a new component. Clearing the things that don't matter to the view or data has been essential in keeping my memory footprint small. With a large app that does many things and loads many views, I'm able to keep the RAM usage to under 200, most times around 150, which, while larger than something like Excel running idle, is a small price to pay to have intuitive design features and access to a large and constantly growing library of reusable components and packages.
jlarocco 7y ago
I honestly don't know why people waste time building Electron apps. It's the worst possible combination. All of the downsides of web apps (poor performance, memory use, poor integration, etc.) and native apps (security problems, hard to update, etc.), without the advantages of either one. Why would I want to download your specially packaged browser, without adblock or uMatrix or any of that, just to basically view a website anyway?
- joefourier 7y ago
  Ah, but you don't waste time, that's the whole point of the idea. You just repackage your existing web app and distribute it as a "native" app, no effort required. You also have a cross-platform application with no extra work (the auld "Write once, run anywhere" slogan), and can use web developers instead of people who know QT/Java/what have you. Then the user can run your chat/music/text editor in the background, have it appear in the taskbar, and start boot, at the cost of requiring a few gigabytes of RAM and 25% CPU utilization while idling. Personally I'd rather have Progressive Web Apps but for some reason, those are still in an awkward stage.
  - jlarocco 7y ago
    But packaging and distributing take a non-zero amount of time. And none of those "benefits" have any advantage over running the web app in its own window. It's a hack to use cheap web developers to check off the "standalone app" checkbox.
  - steve1977 7y ago
    > and can use web developers instead of people who know QT/Java/what have you. Is that supposed to be an advantage? ;)
- automathematics 7y ago
  > I honestly don't know why people waste time building Electron apps. Yes you do. Because some people understand UI design and know how to program in javascript/html/css and have a need to make a desktop app. For example, a small budget indie startup has enough to make ONE version of their app to get funding. They can use JS with the same budget and launch on Web, PC, Mac, Linux, iOS and Android instead of just making a single Windows native app. There is 100% a place for electron. You can argue that after funding they should convert to native, sure. But if you're reading HN you are definitely smart enough to know why a lot of us use electron :) tldr; Smart use of electron is NOT for the end user. It's for the developer.
smith-kyle 7y ago
I made something similar a couple years ago: https://github.com/smith-kyle/electron-process https://github.com/smith-kyle/electron-process But I love the addition of defaulting to a node server for lower memory usage. The Atom editor (the first Electron app) has slowly been rewriting a lot of their modules in C++ for speed and lower memory usage, binding to them through NodeJs. Kind of ironic since GitHub created Electron to build desktop apps using web technologies.
sys_64738 7y ago
My simple rule of thumb for reducing the memory usage of Electron apps is to not run any of them. Problem solved. It's like why I never ever installed java which was subpar garbage. Gosling has a lot to answer for.
z3t4 7y ago
I would just skip Electron and make a PWA (add2desktop) instead.
imtringued 7y ago
The type of developer that chooses Electron isn't going to care about squeezing out the best performance possible. They already made a conscious trade-off to sacrifice performance and memory usage in exchange for productivity. They won't do some hacky things like use Rust instead of nodejs.
olliej 7y ago
I have never had an issue with electron apps being terrible because of networking - although clearly there are apps that do push more work than is necessary over the network, there’s plenty of native software that does too. My problem with electron apps is that they use way more memory and cpu than they should be - the architecture fix for that would be to not be a full browser. The problem I have is they lack basic app behaviors from the platform. My experience is mostly for the Mac, but my experience using vscode on Linux has been similar. But here we go, for a Mac: * cmd-e/f/g are so wide, not just app wide. Vscode goes even further and seems to achieve per-view behavior. * document editors and viewers are expected to have an icon for the file being edited, either in the window or in the tab. That is a draggable link to the file, and a drop down on right click for the directory hierarchy. * drag and drop of files into and out of the windows don’t work These are basic behaviors that even the simplest apps manage to get right on OS X, yet no electron apps seem capable of meeting this low bar.
ulisesrmzroche 7y ago
The argument about bloat is so weak tho. Engineering about trade-offs. If you can’t tell why people use Electron, you’re not a good engineer.

285 points by jlongster 7y ago

I'm not an electron hater, but when only using 300mb of memory while idle is something to boast about, they may have a point.

jlongster 7y ago
Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB. It goes on to say that there's a memory-intensive piece that I haven't even optimized yet and will rewrite into Rust which should bring the memory down a lot more.
- loljabab 7y ago
  Its interesting that slack takes 1gb+ memory. Slack still uses the OS provided webview, right? That seems like the right way to do it (last time I used Slack, it was a 3mb download - glorious), but how is it using so much RAM? maybe its leaky?
  - jlongster 7y ago
    My guess is Slack likes to keep pages around, and each workspace is a separate page that are individually pretty heavy. So if I'm logged into 4-5 workspaces that adds up quick. Slack does not use the OS webview, it is Electron. I don't think it's a 3MB download - if it is it must just be an installer that installs the real thing? I haven't looked recently.
    - loljabab 7y ago
      It has been years so youre probably right. Bummer. That explains the ram usage. I do prefer the webview approach because I don’t need/want my chat app to bundle a browser :-/ Ive been a web and native app dev for a decade and do not agree that developer convenience could ever justify these sorts of choices. My webview backed native apps are all sub 1mb and I have no trouble developing them. I guess I just dont get it.
  - butteroverflow 7y ago
    Are you sure those 3 MB were not just a web installer?
  - wlesieutre 7y ago
    Electron ships its own Chromium-based browser view. Using the OS provided one does sound like an efficient option, but then you have to deal with all the same compatibility testing (different browsers, different releases, running under different OSes and OS releases) that makes web development suck. It's trying to provide a web-based stack while abstracting away most of those headaches. It also provides some Chrome specific functionality (loading Chrome extensions) that wouldn't work in an engine-agnostic system, though I don't imagine this is a commonly used mechanism. Extensions are more useful for shoving your own functionality into someone else's webpage, if you control the whole codebase surely it's not the best way to do anything. https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath https://electronjs.org/docs/api/browser-window#browserwindow...
    - monksy 7y ago
      > but then you have to deal with all the same compatibility testing Which means they choose the wrong way to go about creating an app. If you have to bundle a huge secondary app just to run your main application, you've done something wrong.
      - coldtea 7y ago
        If you have a multi-billion valuation while doing it, and millions of users, you could not care less...
  - danShumway 7y ago
    As someone who uses Slack only in the browser and not as a native app, Electron is not the reason Slack is slow. Electron doesn't help, of course. But Slack seems to either cache a lot of stuff, or have memory leaks, or something. It's weird, because Slack seems to re-fetch data whenever I switch rooms, so I'm not sure what all that RAM is being used for.
  - krzyk 7y ago
    Not every OS has a "provided webview", Linux doesn't, not sure if MacOS does.
    - mthoms 7y ago
      MacOS does (WKWebView)
    - yjftsjthsd-h 7y ago
      Doesn't it? I would say that WebKitGTK counts.
      - krzyk 7y ago
        You need to install it first, there are multiple Linux distributions
- weego 7y ago
  Making electron, the entire point of which was to lower the barrier to entry to app development, even vaguely reasonable in terms of memory use by having to code in Rust which is very much not low barrier to entry is an irony that strikes exactly to the heart of the point the person was making.
  - jlongster 7y ago
    I don't get what you are saying. Using 230MB of memory for a very data-heavy app is already somewhat reasonable, and more advanced optimizations are going to require more advanced engineering. It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725
    - Scarbutt 7y ago
      I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
      - fjp 7y ago
        Every single transaction on every account they have for starters, plus a data point for the total in the account at the end of each day I would imagine, plus all metadata you could ever want to associated with a transaction
        _dps 7y ago
        Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)
  - derefr 7y ago
    Electron lowers the barrier-to-entry for frontend app development. Or, more cynically: Electron allows you to hire cheaper, less-experienced frontend engineers. A background worker in an Electron process, however, can be thought of (depending on what it’s used for) as more of a “local ambassador of the server”, and thus isn’t really “frontend” at all. It lands on the client, sure, but it’s no more frontend than the client-side half of the Firebase library is frontend. It’s plumbing, and so it’d be the responsibility of a backend or infrastructure engineer to write and maintain. If you take this perspective, you still receive the main practical advantage that the system’s product manager was probably seeking by choosing Electron in the first place: the ability to hire inexperienced engineers to do UX tweaks, freeing up the senior engineers’ time to handle the hard stuff. UX tweaks won’t generally bubble down to the level of needing to modify the background worker (again, depending on how you’ve written the thing), so your [junior] frontend engineers won’t need to touch the background worker, so it can be written in a language more on the “good engineering” side of the spectrum than the “low barrier to entry” side—like Rust—without that causing you any headaches of the “everybody who knows how to fix it is busy” variety.
- coldtea 7y ago
  >Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB. You're not making it any better...
- dang 7y ago
  "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."" https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
CharlesW 7y ago
It's relative. Outlook is using 2.37 GB of RAM as I type this.
- Sahhaese 7y ago
  That's odd, OUTLOOK.EXE is using 44MB of ram as I type this and has been open for 7 hours.
  - LandR 7y ago
    Same here, Outlook has been open from 9am > 4pm and it's using 64MB.
  - toyg 7y ago
    Maybe a Mac. My Outlook on mac is idling at 150MB.
    - CharlesW 7y ago
      Yes, this is Office 365 on macOS. Neither the computer nor Outlook have been restarted in weeks, which is surely contributing to its current RAM footprint.
  - GrinningFool 7y ago
    Is it minimized? IIRC on Windows, when an application is minimized the working set is trimmed which can result in a significant reduction - but it jumps back up when you start using the application again.
- jeroenhd 7y ago
  That too is relative. My copy of Thunderbird with 6 open emails from six open mailboxes is consuming about 170MB of memory right now, and that's hosting a fully-featured browser to view emails. Granted, that's reserved memory, but that's the only memory you really need to worry about anyway. Of course, native doesn't make a program automatically use less RAM. It does start with a lower footprint through, meaning that you can keep an eye on memory usage without relying on ugly hacks in your code.

chrisweekly 7y ago

Thanks for sharing! Your post is full of things that might seem obvious in hindsight, but all too likely to be ignored absent a compelling writeup like yours. Bookmarked the linked repo, will revisit w/ my next Electron app.

edoceo 7y ago

I am an electron hater but this is a really good setup. Server reloading with that debugger is rad. I'm going to use these methods with a platform I don't like.

toyg 7y ago

300mb of memory to do a bit of money-counting, which you could probably do equally well with MSVC in 2mb. Such a wasteful world.

castis 7y ago
thats 300mb across several completely necessary helper processes. garbage in, garbage out
- favorited 7y ago
  garbage collected
chasd00 7y ago
In the author's defense, it's just an example he was using to explain a development setup and some techniques. You can also do a factorial on a sheet of paper at 0mb RAM
- jlongster 7y ago
  The 230MB (not 300MB) is from my real app Actual. The example project uses much less because it does nothing except start electron, which looks like it uses about 80MB baseline.
AlexandrB 7y ago
My favourite example is Etcher[1] which is effectively a GUI for "dd" and ships as a 227MB "app" that uses >200MB of RAM idling. "dd" is 37KB. [1] https://www.balena.io/etcher/ https://www.balena.io/etcher/
- kbumsik 7y ago
  Etcher is okay to me because you won't run it in background, you are gonna close it right away after flashing anyway. BTW comparing an GUI app with a CLI-only program sounds unfair.
- 7y ago

falcolas 7y ago

IMHO, good electron apps feel and behave like native apps. Or, in the worst case scenario, they feel like an equivalent web app. Specifically - I should not have to think of having to “ctrl-R” for a desktop application. Good electron apps do exist, but they feel like a vast minority. Most just feel like a bloated version of their web application.

jlongster 7y ago
I completely agree! Are you referring to the "ctrl-r" to reloading the server in the article? That's only for development - the user never has to refresh the app like that of course!
- falcolas 7y ago
  I think you’re saying “a user should never have to refresh the app”. Because ctrl-r has returned completely borked applications back to working. Specifically, I’ve had to use it almost daily to make slack recover from a freeze.
  - jlongster 7y ago
    Oh, yeah that's stupid. cmd+r or ctrl+r for refreshing doesn't even work in my electron app because it doesn't make sense for a desktop app.
  - btsheehy 7y ago
    I'm not sure what the point is, here. Is it that Electron apps can lock up or crash? That they can be refreshed seems pretty immaterial, given that any application in any language can crash
yoz-y 7y ago
> IMHO, good electron apps feel and behave like native apps. I second this, but there are a few reasons why they can't. For example Blink does not respect MacOS highlight color setting so any electron app won't either. I should not be able to select text in parts of interface (e.g.: text inside a button), but it is pretty common that a cmd+a selects everything including interface. Buttons should be in the correct order and have correct highlights depending on the platform.

jlongster 7y ago

I'm the author of the post and I should also say that I don't love Electron. It's a practical choice for getting an app of the ground, but I want something more lightweight eventually. I see it as a stop-gap until I can invest more resources into something more lean. But I'm focused on the product right now, not rewriting the world and wasting time because of engineering ideals.

grecht 7y ago
That’s the right mentality. I'd say don't change it if it works (and is nowhere near as bad as Slack). If the difference in practice is marginal it‘d provide no real value.
makkesk8 7y ago
From looking at your electron-with-server-example hastily, I would imagine adding typescript is not an issue?
- jlongster 7y ago
  I don't actively use typescript, the example is focused solely on the architecture for adding a background process. Typescript seems like a separate concern?
ulfw 7y ago
I agree with your statement but just have never really seen it work that way in real life. Slack is the best example. An app that just 'works' in Electron and the stop-gap became the permanent solution for eternity et voila -> still huge valuation and IPO. I am afraid once you go Electron, most will stay Electron.
- jlongster 7y ago
  Whatever it ends up being it has to be web-based. I'm definitely not going to rewrite the app. However, if something were to come along that uses the user's local webview instead and provided a way to bundle a node server with it, I could absolutely switch to it. In fact, I've played with the idea of providing an app that only sits in your menubar and runs the server, and opening the app just opens a tab in your browser. But most users don't care as much about all this as we think and would find that odd. You're right though - if something is working well enough it probably will end up sticking. Slack just goes to show that it's probably Good Enough despite what we feel about it.

chasd00 7y ago

I've never noticed Electron apps negatively impacting my computer. I use Slack all the time and I don't notice a difference when I have it running vs when i don't. Do most people not like Electron because the number seems high or does it negatively impact their computer in some way? (I have a MBP with 8 gig RAM, that doesn't seem out of the ordinary)

yoz-y 7y ago
As for impact it depends. Slack is not that bad except that it is slow (for example switching teams was sluggish when I was using it). But when I run Slack, Skype, Insomnia and VS Code at the same time I definitely saw the impact. I had 16Gigs of ram but half of that was eaten by a VM all the time.
luckylion 7y ago
I don't like Slack for that reason, but it's a Slack issue, not Electron. Other Electron apps (vscode, keeweb for example) aren't that resource hungry.
ckuhl 7y ago
It definitely negatively affects the battery life of my 2018 MBP. Using only native applications, I can get a full days work done. If I have Slack open, usually I can only work until noon.

makkesk8 7y ago

Some people seem to think that unused ram is good, quite the contrary actually. If you have 50 of these apps running doing work while playing a game while having a pc from 10 years ago, then I can actually see a problem. Laptop and battery-driven devices is a whole other matter though. I like to think the reusability and speed of development with electron is just terrific and is a trade-off that is worth it in the end.

falcolas 7y ago
Unused RAM is good. It lets the OS do things like pre-fetching and caching disc reads. That is, it speeds everything up to not be using all of your RAM. Plus, when you do fill your RAM, you have to start contending with swapping, which slows everything down significantly.
- makkesk8 7y ago
  Swap is not enabled by default by any OS that I know of. And I doubt any OS requires you to have several gbs free in order to work smoothly. My point being is, we are not stuck with 2 gbs of ram anymore and like games, apps will scale to use more resources for ease of development or better features.
  - VonGallifrey 7y ago
    As far as I am aware both windows and linux (several distros) use swap by default. On windows it will be a file on the C drive and on Linux it will be a swap partition. Of course they are not going to swap unless they have to, but they will swap in default configuration.
  - michaelmrose 7y ago
    Literally every major OS in existence has swap enabled by default. Linux, Mac, windows. The alternative is for things to start crashing when you run out of memory rather than swapping out.
    - 7y ago

emptyparadise 7y ago

I miss native apps.

grecht 7y ago

I use VS Code and it never felt sluggish. But it’s probably one of the best Electron apps out there. Honestly, if I had to develop a Desktop app today and wanted it to be cross-platform, I’d probably use Electron. No need for hacky workarounds like in a web app to make it run on every major browser.

0xffff2 7y ago
I use VS Code too and it's extremely sluggish compared to a text editor like Sublime. I use it only because the plugin experience is much better than Sublime and the responsiveness is infinitely better than JetBrains' products.
- hackandtrip 7y ago
  I find it not fair to compare VSCode to JetBrains' product: one of them is an IDE, the other one is an editor, different features and different targets!
  - 0xffff2 7y ago
    I disagree. VSCode is really a hybrid product. With plugins, it does intellisense and debugging, which are really the two major value-add features of an IDE for me. It's still light years faster than IntelliJ (and light years slower than Sublime). I switched from IntelliJ to VSCode and it minimally affected my workflow, so they're objectively not different targets in that regard.
    - winrid 7y ago
      Are there are VS Code intellisense plugins that beat Webstorm?

ionised 7y ago

I find the problem lies with the trade-off you are making. You are making your life as a developer easier in exchange massively increasing the resource requirements and battery usage on end-user machines. It's just bad practice and Electron encourages it. I feel like if we ever want to be taken seriously as a profession the way structural or mechanical engineers are for example, then efficiency and reliability need to be primary considerations, otherwise we are basically making toys.

jlongster 7y ago
I would easily forego the niceties explained in the article if it meant there were something better. The main reason to use Electron is that I can have happy macOS, Windows, and Linux users. Apps that focus on a single platform are exclusionary.
- krzyk 7y ago
  You can have that already - use web, the real one, not Electron. Everyone then can use their favorite browser for your app, not forced to use Chromium. And if you want to make an efficient desktop app, look at telegram source code.
  - michannne 7y ago
    If the goal was to have an online-only tool, wouldn't that have been developed from the get-go?
  - jlongster 7y ago
    The web's offline support sucks, and don't tell me to use service workers. Actual is a truly offline 100% local app. Most users love that they can simply launch a desktop app and it always runs no matter their network connection.

IloveHN84 7y ago

First rule: if you need Electron, change your requirements/design and move to something more cross platform like Qt or libui/C++.

matthewbauer 7y ago
I would discourage libui… The bus factor is 1 right now. There is now guarantee it’s going to be around in a few years. Qt5 on the other hand has a large community around it.
michannne 7y ago
You forgot a number of additional tips: - Hire a C++ programmer - Learn C++ - Adapt knowledge in your current language of choice to C++/Python - Find a designer who can use Qt - Adapt common tools normally found in npm to C++ - Rewrite your application logic to run in C++ Should be simple for any dev to do considering the pay off is lower RAM and "native" look and feel

gfodor 7y ago

If electron apps' claimed memory causes your computer to go slow due to swapping, you should complain. But most complaints I see on this topic stem from a discomfort over the reported figure by the operating system. With SSDs and modern virtual memory systems the claimed memory figure is not a sufficient measure to infer the resource utilization of a process. For example, if slack has a bunch of allocated memory that is rarely accessed, it's going to (at worst) land on your SSD and sit there, having no impact on your user experience. If you want to complain about applications' engineering, you should complain not about claimed memory but about things that are directly affecting resource utilization or user experience like power draw or excessive CPU utilization due to poor programming. Claimed memory must be combined with a profile to show that cold reads are common enough for the claimed memory figure to be correlated with a performance hit. But of course, this often isn't readily available without profiling for all but the most extreme cases, and so engineering types fixate on easily visible measures like claimed memory that likely have no actual resource utilization impact in most cases.

forgottenpass 7y ago
>If electron apps' claimed memory causes your computer to go slow due to swapping, you should complain. But most complaints I see on this topic stem from a discomfort over the reported figure by the operating system. I tried that once. But I'm sick of having to fight that my usecase is valid, that my laptop isn't too old, and that it isn't broken/misconfigured in some other way. It's 4 years old, and I can't run 2 electron applications and firefox at the same time without swapping so hard I can't get anything done. Fuck me for asking so much from a computer, right?
- iforgotpassword 7y ago
  No idea why you're getting downvotes. I think this actually is a problem in the dev world. They often have overpowered systems compared to the average user and as a result might not realize or simply don't care how their software performs on lower end systems. One example that's driving me mad is shotwell (photo managing software). For some reason whenever you start it, it is crawling your entire collection of photos again. There are countless rejected tickets from people asking to add an option to disable it. I personally manage my photos on an older laptop with a spinning 2tb drive, for when I travel... So I'm somewhere without a power outlet in reach, battery sitting at 12%, and would like to quickly show some photos to a friend, but opening up shotwell will make sure that remaining battery will be drained in an instant. But the neckbeards developing that software sitting in their basements with 4 SSDs running in raid 0 just fail to understand what my problem is. Sadly I haven't found a good replacement so far, feature wise. Edit: Also forgetting your password sucks ;-)

vijaybritto 7y ago

Unrelated: I really hope software like https://github.com/revery-ui/revery https://github.com/revery-ui/revery becomes mainstream! This node IPC debugging technique is pretty nice!

seddin 7y ago
What's the size of the built binaries?

bfrog 7y ago

The secret is don't use electron.

asdkhadsj 7y ago

So, I love the role that Electron fits, but boy do I hate how much we discuss Electron itself. What we should be discussing is providing the functionality of Electron without the cost. A protocol that behaves like React native. Ideally a spec, which any language can implement and provide a native UX to the end user. Some projects try (ProtonNative, for example), but I've not seen one go quite far enough. I don't want to be forced to write a JS app to get benefits here. After all, with ReactNative, it's basically a process RPC to a bunch of widgets. `process <-> UI`. So why be forced to write JS? An open spec would do wonders here. I've not invested cycles on solving this problem, of course. Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth. They're great projects, but a slightly wider vision would make them amazing projects. Thoughts? Am I missing something obvious?

hexmiles 7y ago
i really loved xul form mozilla. i build a lot of tiny apps with it, unfortunately it's no longer supported. I also used it to build the kind of bridge you mention, it was for dynamically build gui for cli apps that did job processing (but it was a basic bridge with few functionality), and also some crud form from the database schema.
nexuist 7y ago
>I don't want to be forced to write a JS app to get benefits here. Although most major Electron apps are written in node, it's pretty easy to have a backend in another (compiled) language. You can simply use the subprocess module in node and build your own bridge, for example to a Go CLI that accepts events from electron and does whatever you want it to do. It's a workaround for sure, but the point is you could do it in a pretty stable way. >After all, with ReactNative, it's basically a process RPC to a bunch of widgets >Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth I've used React Native in the past and I'm working on a Flutter app now. The problem with RN is that every platform has its own unique widgets. It's neat that you have one codebase, but you still need to build a separate UI (at least for certain pages) for Android and iOS. It just doesn't look right otherwise. Flutter gets away with this because it owns the drawing layer as well as the widget layer. I know that something drawn in Flutter is going to look exactly the same no matter where I run it. This means that widgets fail gracefully by default - in RN, things just straight up break or look weird. The worst that can happen in Flutter is that the user has to deal with an iOS picker on Android or vice versa. Electron is more akin to Flutter than RN in this way. It controls the drawing/rendering because of Chromium. Slack on Mac looks exactly like Slack on Windows. That's more enticing than needing to build new UIs for every platform you want to support. The only way to solve this is to basically invent another cross platform drawing layer. But why bother? HTML/CSS already exists. There's effort and tooling and docs and community and everything else you'd need for a successful framework. It's not worth the effort. I think the best solution will be just embedding Electron at the OS layer, so apps don't have to bring along their own Chromium runtime. This way it runs closer to the metal, which should help alleviate RAM and storage concerns (these seem to be the only major concerns most people have with it).

cpursley 7y ago

Thanks for the post. > I want something more lightweight eventually Check out https://github.com/revery-ui/revery https://github.com/revery-ui/revery

jlongster 7y ago
That's a very cool project (I've used OCaml before) and I hope it takes off. I should try it, but I admit I'm a little skeptical because there are so many details to get right like focus management, accessibility, and more. Unfortunately since I can't rewrite my project entirely, I'm going to need something that reduces bloat by using a local webview instead, so it's still web-based.
- ori_b 7y ago
  The local web view is the bloat. The rest of electron is not the problem.
  - jlongster 7y ago
    ? A local webview usually means that it reuses the user's already installed browser and uses that instead.
    - ori_b 7y ago
      The browser I have installed is the single most resource intensive program I have on my computer.
      - iforgotpassword 7y ago
        Why? Because you picked a particularly bad one or because you have 200 open tabs? Usually the browser is running anyways so adding another open tab or window increases resource usage much less than another program shipping its own browser engine.
        7y ago

mhd 7y ago

The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the average RAM at the time they were accused of bloat] It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc. Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign. In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).

jlongster 7y ago
I agree with this too but this problem can be addressed by caring. I care. You can find a bunch of non-native interactions in my app but every time I work on it I make it better and implement more of a native feel (like disabling selecting text when you shouldn't be able to, etc). It's a balance - personally I think apps that focus on a specific platform is exclusionary. So accepting some non-native feel means more people can use my app. I agree that browsers make it hard though.
- mhd 7y ago
  I'd argue that despite all cries about non-native styling and behavior, MacOS Classic, OS X, Windows 95, OS/2, Next, Swing etc. had more in common with each other than they do with webapps (unless we're talking about ExtJS enterprise apps or the like). This won't matter as much for rich-text chat apps or the like, which always looked horribly non-native, over-styled, skeuomorphic (cf. Trillian)… But let's picture a database client or IDE. Those used to resemble regular desktop apps. Nowadays? Note that I'm not arguing about your article or even approach, I was just chiming in on the dislike for Electron in general, where I think bloat is the least of our worries. All this wasn't something new, the downturn of desktop UIs started way before, as people are now used to mobile and webapps and expect that kind of look and feel everywhere. The OS manufacturers definitely seem to approve and comply. You saw this happening in other places, before. Just look at enterprise Windows applications that were targeted to people used to terminal UIs (3270, VT220). Current UI trends are the same, just with spurious rounded corners instead of closely-grouped form elements…

draw_down 7y ago

At least for Slack, you don't have to worry about this if you just run it in a web browser. Because it's a web app. Seems like good advice though.

wlesieutre 7y ago

Electron discussions often focus around the battery and memory impact, one other thing I'd mention is the poor access to native features. You get the stuff a web browser can do, but for anything else offered by the OS you might need to wait a while. For example, Apple shipped their first TouchID laptop in 2016, and Electron's support for that landed in v6.0.0 beta 1 just last month. https://electronjs.org/releases/beta?page=2#6.0.0-beta.1 https://electronjs.org/releases/beta?page=2#6.0.0-beta.1 I'd looked at switching off 1password to BitWarden and that's a pretty major feature to be missing for three years. Surprisingly, for as much as everyone craps on the touchbar, that got supported by Electron a lot faster than TouchID did. I guess because not all apps need authentication and they can rely on passwords instead, while it's really obvious when an app doesn't have touchbar support.

jbverschoor 7y ago
Not with nativescript.. you just use the brand new api
- mthoms 7y ago
  Does nativescript do desktop? Their site seems squarely focused on mobile (iOS/Android).
kitsunesoba 7y ago
There’s system feature absences that bleed over from Chrome, too. One that comes to mind is the total exclusion of the numerous bits of functionality that macOS provides in text fields, a great example of which is how Chrome has lacked support for macOS text substitution for coming up on a decade now. https://bugs.chromium.org/p/chromium/issues/detail?id=42434 https://bugs.chromium.org/p/chromium/issues/detail?id=42434

fmakunbound 7y ago

What are the 83 threads used for in that trivial budgeting application?

rmrfchik 7y ago

Not only memory is the problem with electron, but also app feeling. Skype left is the only electron app I'm using. And comparing to desktop messaging app (telegram): 1. Skype unresponsive. Opening chat takes up to few seconds. 2. I see how opened chat is literally updating -- messages, avatars, emoticons emerges from dust 3. Selecting messages as messages in native vs selecting messages as text with surrounding artefacts (chat is a html page with all what comes with it) Summarizing, electron apps are just feels like foreigners.

adgasf 7y ago

People love to bash Electron, but what is the alternative? Is there any other platform that provides: - Support for the 3 major desktop platforms from one code-base; - A decent choice of high-level programming languages (there are excellent compile-to-JS options now); - Reasonable tooling and community support; - MIT (or similar) license

barking 7y ago
Lazarus, Pascal only, but otherwise it ticks your boxes I'd say.
danieldk 7y ago
Qt. Supports Linux, macOS, and Windows. Supports at least one high-level programming language very well (Python). Has good tooling and a lot of support. It's LGPL, which is fine for most cases. But you could always buy a commercial license.
- golemiprague 7y ago
  What about the web? Electron apps can usually run also as web apps, can QT do that?
c-smile 7y ago
Sciter (https://sciter.com https://sciter.com) - Support for the 3 major desktop platforms from one code-base; - A decent choice of high-level programming languages... C/C++, Go, Rust, C# and other .NETs, Delphi, Python as host languages. - Reasonable tooling and community support Whatever host language provides. - License: Sciter is free to use in binary form. Contained in single dll/so/dylib without external dependencies. Size of DLL is 5-10 mb. Can be statically linked into host (C/C++) application to create monolithic executable.
- deleted 7y ago
  [deleted]
steve1977 7y ago

langitbiru 7y ago

The hate for Electron is strong in this thread. For Electron haters, here are the alternatives: OpenJFX (some people hate Java), Qt5 (it can be pricey in some situations), wxWidgets (not popular enough?). However, I have a lot of hope for Flutter in desktop. I hope the developers of Flutter framework can pull off the challenge. In my case, for opensource projects, I definitely use Qt5 (using PySide2). But for proprietary projects, I have to admit that most likely I will choose Electron.

Narishma 7y ago
AFAIK, as long as you don't modify Qt itself, you can use it just fine for proprietary projects without having to buy a commercial license.

fabiospampinato 7y ago

It sounds like a generally good approach for keeping the UI process responsive at all times. I wonder if the serialization cost behind all those IPC calls becomes an issue at some point, especially when passing large structures back and forth, have you found this to be an issue for your use case?

swiley 7y ago
Doesn’t (or didn’t?) X11 work by serializing every drawing operation and doing IPC? That’s been used on very old machines and is very responsive.
- ptx 7y ago
  The MIT-SHM shared memory extension was added pretty early on. And nowadays (in GTK etc.) everything is drawn on the client side and sent over as a bitmap. The old-style serialized drawing commands model is only responsive when you have a very simple UI that doesn't do much drawing.
jlongster 7y ago
I haven't noticed an issue - the only alternative would be to block the renderer and do it in the same process. The IPC uses a local domain socket which is very high performance (better than a web socket) so any overhead is quickly made up for with UI responsiveness. There may be specialized cases where it is a problem and you'll have to figure something out.
- codesushi42 7y ago
  How do you secure the socket and prevent a malicious process from connecting to it?

skrebbel 7y ago

I feel like the key idea here is somewhat unrelated to writing Electron apps. It's that you can set up any Node server app to run inside an Electron window during development and then you get cmd+r and all the devtools for free. Kind of like a node inspector on steroids. Pretty nifty!

UtahDave 7y ago

Vote for Linux support in Actual here: https://trello.com/c/A7XzJgJX https://trello.com/c/A7XzJgJX

jlongster 7y ago
Linux support was added in 0.0.99! See here (and download it): https://github.com/actualbudget/releases/releases/tag/0.0.99 https://github.com/actualbudget/releases/releases/tag/0.0.99 Somehow that card didn't get moved to done, sorry! Let me know if it doesn't work.

m48 7y ago

Obviously bundling nearly all of Chromium with an app is inherently inefficient, but out of curiosity's sake, has there been any objective analysis of exactly what makes this use a seemingly disproportionate amount of resources? Are JavaScript runtimes inherently inefficient? Is it Electron's node.js part? Is it the huge amounts of code needed to parse and render HTML and CSS? Is it the multimedia features, like WebGL and the video and audio players? Is the problem actually just badly written code running on top of Electron? And if so, what exactly are are most Electron apps doing wrong that one could avoid? Is it, as this blog post seems to suspect, that they aren't sufficiently taking advantage of Electron's node.js integration? In addition, once the actual bottleneck has been identified, doesn't this open the door to fix things on the WebKit/Blink engine side of things? Before, when Electron was managed by GitHub, one could say this would be unreasonably difficult, but now that GitHub is owned by Microsoft, isn't tweaking Blink to be more suitable for deployment environments outside of Chrome exactly the type of thing they would have a vested interest in doing, and the resources to actually pull off? After all, with VS Code, they are one of the highest-profile Electron users, and using Blink in Edge presumably involves working with the Blink code to some degree anyway. It's always struck me that a lot of Electron apps likely never use a single line of WebGL, while a lot of WebGL apps likely only use DOM APIs to pretend the DOM doesn't exist by plastering everything in a huge <canvas> element, and both likely don't want their binaries to include the Chrome devtools, but Electron includes all of these things anyway. I'm not sure how much space or resources it would actually save, but is Chromium/Blink refactoring their code and build process to facilitate Electron building different Electron "profiles" that include different sets of features even remotely a possibility?

ptx 7y ago

If you need a background process to call Node APIs because "it's the only place where it's safe to access them", what unsafe way is this meant to contrast with? Does Electron normally (but unsafely?) call Node APIs from the browser process?

jlongster 7y ago
You can enable "node integration" with any renderer process and call node from their. But you definitely should not enable it in your primary renderer process if any untrusted code is running their (if you pull in any JS from anywhere else)
deleted 7y ago
[deleted]

geodel 7y ago

Well to me it is thing that should not be done at all, instead of doing it diligently. I will put this in category of 'The secret of good user tracking on web', 'the secret of doing quality journalism on ads supported model' or 'the secret of nuanced political debate on Twitter' etc.

michannne 7y ago

I'm building an application using Electron and I've found the majority of memory consumption occurs when instantiating new components. When using a UI framework like Material, this can happen frequently, such that the simple act of hovering over a menu and showing an indicator can cause an increase of 3 MB of RAM. I love Electron, it allows me to create applications in an intuitive way using a language meant for building UIs, rather than slapping a library on a native codebase, and I can deploy it wherever Chromium is supported, so I'd like to make it efficient, wherever possible. Two solutions I have found during my development: 1) Keep your components light. Most of what I used from Material can be done completely with raw HTML and CSS in a simpler fashion without much going on in terms of state, so I created my own components that serve my purposes. A lot of libraries and frameworks are heavy because they are used on webpages viewed by multiple different browsers and require complex logic to work across different environments. Electron sandboxes your code in Chromium + node, you code only for 1 browser engine, so I hope more devs take advantage of that fact. 2) Load what you know you need in the beginning, and keep your cache to a minimum. Most Electron apps do not have view transitions, they are built as SPAs. One of the downsides of this is that you need to be mindful of your cache since it is not cleared when you display a new component. Clearing the things that don't matter to the view or data has been essential in keeping my memory footprint small. With a large app that does many things and loads many views, I'm able to keep the RAM usage to under 200, most times around 150, which, while larger than something like Excel running idle, is a small price to pay to have intuitive design features and access to a large and constantly growing library of reusable components and packages.

jlarocco 7y ago

I honestly don't know why people waste time building Electron apps. It's the worst possible combination. All of the downsides of web apps (poor performance, memory use, poor integration, etc.) and native apps (security problems, hard to update, etc.), without the advantages of either one. Why would I want to download your specially packaged browser, without adblock or uMatrix or any of that, just to basically view a website anyway?

joefourier 7y ago
Ah, but you don't waste time, that's the whole point of the idea. You just repackage your existing web app and distribute it as a "native" app, no effort required. You also have a cross-platform application with no extra work (the auld "Write once, run anywhere" slogan), and can use web developers instead of people who know QT/Java/what have you. Then the user can run your chat/music/text editor in the background, have it appear in the taskbar, and start boot, at the cost of requiring a few gigabytes of RAM and 25% CPU utilization while idling. Personally I'd rather have Progressive Web Apps but for some reason, those are still in an awkward stage.
- jlarocco 7y ago
  But packaging and distributing take a non-zero amount of time. And none of those "benefits" have any advantage over running the web app in its own window. It's a hack to use cheap web developers to check off the "standalone app" checkbox.
- steve1977 7y ago
  > and can use web developers instead of people who know QT/Java/what have you. Is that supposed to be an advantage? ;)
automathematics 7y ago
> I honestly don't know why people waste time building Electron apps. Yes you do. Because some people understand UI design and know how to program in javascript/html/css and have a need to make a desktop app. For example, a small budget indie startup has enough to make ONE version of their app to get funding. They can use JS with the same budget and launch on Web, PC, Mac, Linux, iOS and Android instead of just making a single Windows native app. There is 100% a place for electron. You can argue that after funding they should convert to native, sure. But if you're reading HN you are definitely smart enough to know why a lot of us use electron :) tldr; Smart use of electron is NOT for the end user. It's for the developer.

smith-kyle 7y ago

I made something similar a couple years ago: https://github.com/smith-kyle/electron-process https://github.com/smith-kyle/electron-process But I love the addition of defaulting to a node server for lower memory usage. The Atom editor (the first Electron app) has slowly been rewriting a lot of their modules in C++ for speed and lower memory usage, binding to them through NodeJs. Kind of ironic since GitHub created Electron to build desktop apps using web technologies.

sys_64738 7y ago

My simple rule of thumb for reducing the memory usage of Electron apps is to not run any of them. Problem solved. It's like why I never ever installed java which was subpar garbage. Gosling has a lot to answer for.

z3t4 7y ago

I would just skip Electron and make a PWA (add2desktop) instead.

imtringued 7y ago

The type of developer that chooses Electron isn't going to care about squeezing out the best performance possible. They already made a conscious trade-off to sacrifice performance and memory usage in exchange for productivity. They won't do some hacky things like use Rust instead of nodejs.

olliej 7y ago

I have never had an issue with electron apps being terrible because of networking - although clearly there are apps that do push more work than is necessary over the network, there’s plenty of native software that does too. My problem with electron apps is that they use way more memory and cpu than they should be - the architecture fix for that would be to not be a full browser. The problem I have is they lack basic app behaviors from the platform. My experience is mostly for the Mac, but my experience using vscode on Linux has been similar. But here we go, for a Mac: * cmd-e/f/g are so wide, not just app wide. Vscode goes even further and seems to achieve per-view behavior. * document editors and viewers are expected to have an icon for the file being edited, either in the window or in the tab. That is a draggable link to the file, and a drop down on right click for the directory hierarchy. * drag and drop of files into and out of the windows don’t work These are basic behaviors that even the simplest apps manage to get right on OS X, yet no electron apps seem capable of meeting this low bar.

ulisesrmzroche 7y ago

The argument about bloat is so weak tho. Engineering about trade-offs. If you can’t tell why people use Electron, you’re not a good engineer.