11 ms·

I always read about how Electron is very resource-intensive, but I'm curious as to how the performance improves as time goes on? Does the Electron team have a

I always read about how Electron is very resource-intensive, but I'm curious as to how the performance improves as time goes on? Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I assume it's some of both, but curious if anyone with more experience in electron can provide any insight as to how the performance changes over time.

accatyyc 8y ago
The issue itself is that Chromium uses a lot of memory. And electron basically just runs Chromium. Except that since each Electron-based app ships its own very isolated copy of Chromium, the following problems occur: - The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory. - The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps. This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.
- alex_suzuki 8y ago
  The last point is something that in theory could have been achieved (shared runtime) with Java or .NET, but in reality there are real, tangible benefits to shipping self-contained applications, and the disk size argument is just no longer that relevant. This is in no way an endorsement for Electron, just an aspect common to all platforms that rely on an intermediate runtime that could in principle be shared.
  - realusername 8y ago
    > the disk size argument is just no longer that relevant. But the memory one definitely is, I don't want each app to take 1GB of ram.
  - fredley 8y ago
    Disk size argument no but memory yes. Keeping this massive binary duplicated in memory for every trivially small (memory-wise) app, like Slack, is bananas.
  - wodenokoto 8y ago
    Actually disk size argument is still relevant. My brand new MacBook pro has the same disk space as my 10 year old MacBook pro. While hard drive space is cheap on spinning drives, space on consumer devices has stagnated or even decreased with the move to ssd
    - rubber_duck 8y ago
      We are still talking ~100MB (from what I can see my entire VS Code install folder is 170 mb - 100 probably goes off to chromium stuff) - even if you use 10 electron apps 1GB of memory isn't going to kill your drive - really not worth the tradeoff and effort considering the alternatives.
  - PavlovsCat 8y ago
    > there are real, tangible benefits to shipping self-contained applications Here's one that doesn't suck: https://sqlitestudio.pl/ https://sqlitestudio.pl/ Maybe that was very complicated to make, all I know is that it's blazing fast and doesn't hog memory. Or hey, take OggDrop and LameDrop, I'm sure there's programs that do the same, are 100 times as big and have 3 options. I don't know if there are 10x programmers, but I know there are 100000x programs, with not one electron app among them.
    - kimmel 8y ago
      I love SQLiteStudio. On my machine it starts up in < 2s. Version 3.2.1 takes 99MB disk space and is built against QT5. I just ran some queries and the memory usage is only 80MB for a not too large database. Another self-contained application I like is racket/drracket.
- PaulHoule 8y ago
  Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? Lately I have been building apps with tkinter/python/asyncio and I can't get over how fast the apps are to load and to use. There is none of this "let's not respond to the mouse for 5 seconds" that is staggeringly common on my mac (particularly for apps like Safari and iTunes that come from Apple) nor the "go for a walk around the block" loading times for Java-based apps on my i7 Windows laptop. True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are as responsive as Windows 95 apps were back in the day.
  - eddieroger 8y ago
    Do they think that? I think more what thing here is that Electron apps are popular with UI developers who want to make the jump from web apps to native apps without taking the time to learn the platforms, or wish to reuse components they use on their web apps.
  - androidgirl 8y ago
    The aversion is mostly that a lot of devs have learned to use html, css, and js for styling ui's. I love Kivy as well as QT. You can make some decent looking apps with the former and some incredible ones with the later. I have never personally worked with Electron. But yeah, most devs use JS, HTML, and CSS for ui creation because of the Web. I think something like QML could replace the html and css parts, though.
    - giobox 8y ago
      To add to this point, virtually all software companies have devs with web dev experience that can be very easily leveraged with Electron. Native app development skills aren’t nearly as prevalent in most organisations in my experience. The success of electron has never been that much of a surprise to me: write once, ship (almost) everywhere, use the team you already have. Often cheaper than upskilling the team as well.
  - jniedrauer 8y ago
    > Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? tkinter specifically does not look very pretty without some effort. I would much rather use GTK or QT. The problem is GTK support on windows is limited, and QT has a weird license model.
- jf- 8y ago
  Is there a reason it’s not done as a runtime, i.e. have a single, electron-modified, backwards compatible install of chromium which all the electron apps run on? Then ship each app with the installer for that electron-chromium which gets installed if it’s not already present. Though I feel like even if that happened people would still complain about it, mostly motivated by web technologies encroaching on the desktop space, threatening other developers “turf”, so to speak.
  - megous 8y ago
    No there isn't. For example on Arch Linux, you can do pacman -S electron and share the same runtime for all your electron apps. Though, I don't use any third party ones.
    - jf- 8y ago
      That’s interesting. Is there something specific to arch that allows this? It would definitely help to alleviate people’s concerns about electron if this could be replicated on other platforms.
      - megous 8y ago
        Nothing specific. You can do it with electron executables downloaded from the official website. Just run them, and drag'n'drop directories with the application's source code onto the electron window, or create desktop shortcuts that run "C:\somewhere\electron.exe C:\your\app\dir".
    - simion314 8y ago
      This would work only for packaged apps from the repos right? Better then nothing.
      - megous 8y ago
        I didn't find any apps in the repository. This works for apps you write yourself. You just run "electron ." in the directory with the app's source code. You can probably unbundle thirdparty apps, becuase what electron apps are, are basically "electron" + "other code/resources". But I've never even seen someone else's electron app distribution package, so I don't know how hard/easy it would be. And I wouldn't trust it anyway, if the code is transpiled/minified/unreadable. I run all my electron apps using a shared runtime.
- ancorevard 8y ago
  The root cause of the problem with Electron is that its performance on the Mac is just like the Chrome browser. Compared to Safari, Chrome’s performance is like a fat pig hogging your memory and devouring your battery life.
- felixfbecker 8y ago
  When I tried out Windows tabbed shell in the Insiders build I found myself using the web versions of Electron apps (e.g. Slack) way more than the apps. They can do everything the app can nowadays (including native notifications), and with tabbed shell, they can appear next in a tab right next to a native app - but with all the benefits of web apps: linkability, hackability through browser extensions, accessibility, no annoying update prompts. And of course only running one browser engine instance. You can even pin them to your task bar like native apps. I feel like on macOS many people install native apps only to have a dock icon. We really overvalue packaged apps
  - drb91 8y ago
    > We really overvalue packaged apps I think splitting out services from the browser makes it easier to focus on notifications and use window management to change contexts. It is confusing and frustrating that Apple has not allowed saving websites to apps yet.
- SigmundA 8y ago
  Wouldn't memory compression and disk compression resolve those issues to some degree? Sharing libraries is definitely more efficient but at the cost of isolation and versioning issues. Similar to some of the reason vms and containers are used. Over time I have come to appreciate self contained apps and deal with redundant bytes at a lower level.
- seanalltogether 8y ago
  > This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. On the other hand, requiring a shared runtime has been one the key reasons that a lot of cross platform apps failed in the past. How many times have others decried the fact that they had to install Java or Adobe AIR or XYZ in order to run an app they needed.
  - sime2009 8y ago
    Well, there was a solution to that last problem. Just bundle the whole runtime with the product each time. And just like that we're back at square one again...
  - Splines 8y ago
    Steam seems to solve this fairly well. If you need a runtime it is installed along with the product.
- jackpeterfletch 8y ago
  - If electron worked like the JVM and each app shared a runtime You mean like eerr, chrome - and the web :P
- blinkingled 8y ago
  > - The operating system cannot share memory between different Electron processes [..] That should not be a significant issue in 2018 - all popular operating systems have same page merging support now and at least latest Win10/macOS also have transparent compression of memory pages.
  - ryacko 8y ago
    Woudldn’t that break ASLR?
    - blinkingled 8y ago
      ASLR applies to virtual memory / process address space. Merging or compression is of physical pages - the page is uncompressed on the fly when the process accesses it. It works because the OS is in control of the Virtual->Physical mappings and can, on a page fault do the decompression transparently for e.g.
  - ahartmetz 8y ago
    Compressing working memory is quite expensive in CPU cycles compared to just using it. Identical page merging is also reasonably expensive and only works if pages are, well, identical. Your Electron runtimes are probably not going to be bit for bit identical, not even small sections, due to offsets not divisible by page size. Tuning for better deduplication is possible, but then you're at an awkward mix of caring and not caring about performance.
    - blinkingled 8y ago
      Compression is pretty fast on modern CPUs so I would disagree about that. But yes depending on the compiler/switches/versions the Electron run times are not going to be bit for bit identical but it's a stretch to say there will be nothing in common - all the dependent library code for e.g.
- scoopdewoop 8y ago
  It is absurd the people that show up out of the woodwork every Electron article to complain about performance. Meanwhile, I have not closed Discord for more than a day or two in years. A quick Ctrl-Shift-Esc shows that it is using 180MB of RAM right now with ~20 rooms open, as well as DMs. Meanwhile, Discord has fantastic uptimes and never impedes performance while competitive online games run alongside it. The idea of trying to replicate the interface in something like tkinter is cringeworthy at best. Discord supports animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations right in the chat! Please, please try and replicate that with Tkinter, an API where you'd need to roll your own drag-and-drop. If i want to run discord as a website, using the same resources as any other website, i CAN! Its the same codebase and interface. I run the full desktop client for the better filesystem, game, and chat integration and it is worth the measley RAM on my modern machine. Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.
  - zozbot123 8y ago
    > animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
  - seba_dos1 8y ago
    Not commenting on anything else, but Discord app consuming 180MB RAM sounds like a mismeasurement. Here it takes almost 0.5GB right after launching.
    - mbell 8y ago
      They are most likely only looking at the RAM used but the 'Discord' process, which is just the native launcher code and OS hooks (on MacOS here, may be different on other OSes). The electron processes are called 'Discord Helper' and will be using quite a bit more RAM, though I still wouldn't consider it 'heavy'. The same process structure is true of Slack as well (maybe all electron apps, I'm not familiar enough to say). Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
- Aaronmacaron 8y ago
  I don't think a JVM like chromium engine would really solve the problem. Most JVM end user applications ship their own JVM. By shipping your own JVM one can avoid compatibility problems and most importantly the user doesn't has to install the JVM which makes for better UX. The same would apply for Electron. The only way I think a common runtime could work is if Electron used the Runtime of the Browser. If every browser exposed an API to run JavaScript and Render HTMl using the browser's Engine that'd be great.
  - vincnetas 8y ago
    Why expose api. One could run web server on localhost and thats it. Open it with any browser and enjoy your crosplatform app. I think https://blockstack.org https://blockstack.org is doing something similar.
  - vincnetas 8y ago
    Adding to my previous comment, you can even run chrome webpage without address bar on macos : /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=https://google.com https://google.com
- manigandham 8y ago
  Why does this matter on any modern operation system and hardware? What is the point of unused RAM capacity given fast mem/disk IO, compression and seamless paging?
  - zozbot123 8y ago
    Disk IO is not always fast. Memory bandwidth is a huge bottleneck on current-day systems, especially on high-frequency, high-core-count processors. And so on and so forth. If you want a snappy and truly usable system you still need to care about performance issues, particularly given the rise in non-reducible system requirements e.g. for browsing the modern web.
- Sindisil 8y ago
  > If electron worked like the JVM and each app shared a runtime Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance). On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.
sergiotapia 8y ago
Either they start working towards performance/memory issues or this will very likely go the way of Cordova/PhoneGap. Feature rich, but ultimately forgotten and not used for new projects.
- NatW 8y ago
  I don't think VSCode is going away. It's built on Electron[1] and performs quite adequately for me, personally. [1] https://en.wikipedia.org/wiki/Visual_Studio_Code https://en.wikipedia.org/wiki/Visual_Studio_Code
  - nni 8y ago
    I've only very rarely seen performance issues with VSCode...
  - intertextuality 8y ago
    VSCode seems to be one of the exceptions. It's also not as fast as Sublime Text.
    - 0xCMP 8y ago
      Agree, but because it's JS and well designed plugins also affect the editor experience much less. Where in Sublime the Python based plugins which aren't designed around async and promise-like patterns often can lock up the editor waiting on them. VSCode is pretty much the best Emacs there is right now. Uses JS, has good package management, allows changing settings per "workspace" including enable/disable plugins, has great git support, pioneered LSP, and more. I literally want to hate VSCode, but there isn't much to hate and any weakness it has can/should/likely-will be addressed by a plugin.
    - GuB-42 8y ago
      Performance is the reason why I stayed with Sublime Text. I gave VSCode a try, and it is really great, and transition from Sublime Text is easy. They probably stole most of their good ideas from it, while improving on others, a practice that I definitely support. However, it is not as responsive. By that, I mean sub-second stutters, nothing game breaking, but enough to affect the feel. Note: coding in C++, using the LSP plugin on Sublime, and the standard language support on VSCode. Building and source control done separately on the command line. I use "modific" on sublime to see the differences, and the built-in support for VSCode.
CyberDildonics 8y ago
The biggest issue by far with every electron based program I've used is actually not the huge memory foot use or the hundreds of megabytes for a simple program, it is the latency of the interface. Every interaction ends up lagging like molasses, whether it is text input, window resizing, startup time etc. We have video games that run 3D environments with gigabytes of geometry and textures at 144hz yet people are making simple text editors and interfaces with a dozen simple components (like the ethereum wallet) that run xwindows streamed over a 56.6 modem.
- jeffbax 8y ago
  Nevermind the small but incredibly obvious stuff like keyboard shortcuts, drag and drop behavior and text selection…
- spiralganglion 8y ago
  I think this is an excellent criticism of Electron that seems to be buried. Sure, it’d be nice if the RAM usage and disk footprint of electron were smaller. Maybe the creation of some sort of shared single instance of chromium will happen, someday. But even if it does, the browser rendering process is really latent unless you’re extraordinarily careful. It’s very challenging to make sure that your app responds to input within one frame — batching updates with requestAnimationFrame creates a visible delay when dragging and typing. It’s possible to do better, but it’s hard and almost nobody does. And it’s easy to do a lot worse — RAIL isn’t aggressive enough. (My angle on this — I do high-performance 2d/3d animation work in the browser and in electron, with extensive testing of latency, energy usage, frame rate stability, etc)
  - ahartmetz 8y ago
    I've heard a similar story about an app implemented in HTML5 and node.js (no good JS UI frameworks existed at the time). The fine-tuning took an extraordinary amount of time. I was on a project that redid it in QML in a fraction of the time with a fraction of the headcount and performance was great right away.
fabiospampinato 8y ago
Performance improves as each new version of Electron basically ships with an updated V8 engine, which usually improves performance, but they also work on optimizing Electron itself (for instance: [1]). I think most of the times if an Electron app is not snappy enough then the developers didn't spend enough time optimizing it, take a look at VS Code vs Atom for instance, I haven't used Atom in a while so maybe the situation in different now, but both are Electron apps, VS Code is fast and Atom is (was?) not. [1] https://github.com/electron/electron/pull/14633 https://github.com/electron/electron/pull/14633
- InGodsName 8y ago
  I think it's because VSCode uses typescript and it had better plugin architecture. VSCode also uses lazy loading so doesn't initate everything at once you click the launcher icon but does it progressively.
  - fabiospampinato 8y ago
    VS Code doesn't provide direct DOM access to extensions authors, that's definitely a deciding factor. But a couple of years ago even simply writing inside Atom without using any extension felt sluggish to me. TypeScript gets downcompiled to JavaScript anyway, so I don't think that's directly a contributing factor, but maybe because of the type system they can spend less time debugging and more time optimizing.
  - bitwize 8y ago
    It's because much of the guts of VSCode is written in C++ and optimized. Because, you know, Microsoft.
    - InGodsName 8y ago
      So eletrons lets you code part of it in C++?
      - fabiospampinato 8y ago
tschellenbach 8y ago
Lately Atom is running quickly for me, but Goland is very slow and resource intensive. So I guess it varies, but Electron starts at a disadvantage.
simion314 8y ago
>Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I think the main issue is the developers, some apps don't use so much memory where others seem to use too much for the features they provide, IMO most JS developers do not understand how GC works and how you can by mistake keep objects alive. There is also the issue where you do not have a default UI toolkit and some frameworks like angular are bad for performance(I mean how in angular codes I seen data binding trigger tons of unnecessary updates but maybe some will blame the developers using it wrong)

accatyyc 8y ago

The issue itself is that Chromium uses a lot of memory. And electron basically just runs Chromium. Except that since each Electron-based app ships its own very isolated copy of Chromium, the following problems occur: - The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory. - The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps. This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.

alex_suzuki 8y ago
The last point is something that in theory could have been achieved (shared runtime) with Java or .NET, but in reality there are real, tangible benefits to shipping self-contained applications, and the disk size argument is just no longer that relevant. This is in no way an endorsement for Electron, just an aspect common to all platforms that rely on an intermediate runtime that could in principle be shared.
- realusername 8y ago
  > the disk size argument is just no longer that relevant. But the memory one definitely is, I don't want each app to take 1GB of ram.
- fredley 8y ago
  Disk size argument no but memory yes. Keeping this massive binary duplicated in memory for every trivially small (memory-wise) app, like Slack, is bananas.
- wodenokoto 8y ago
  Actually disk size argument is still relevant. My brand new MacBook pro has the same disk space as my 10 year old MacBook pro. While hard drive space is cheap on spinning drives, space on consumer devices has stagnated or even decreased with the move to ssd
  - rubber_duck 8y ago
    We are still talking ~100MB (from what I can see my entire VS Code install folder is 170 mb - 100 probably goes off to chromium stuff) - even if you use 10 electron apps 1GB of memory isn't going to kill your drive - really not worth the tradeoff and effort considering the alternatives.
- PavlovsCat 8y ago
  > there are real, tangible benefits to shipping self-contained applications Here's one that doesn't suck: https://sqlitestudio.pl/ https://sqlitestudio.pl/ Maybe that was very complicated to make, all I know is that it's blazing fast and doesn't hog memory. Or hey, take OggDrop and LameDrop, I'm sure there's programs that do the same, are 100 times as big and have 3 options. I don't know if there are 10x programmers, but I know there are 100000x programs, with not one electron app among them.
  - kimmel 8y ago
    I love SQLiteStudio. On my machine it starts up in < 2s. Version 3.2.1 takes 99MB disk space and is built against QT5. I just ran some queries and the memory usage is only 80MB for a not too large database. Another self-contained application I like is racket/drracket.
PaulHoule 8y ago
Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? Lately I have been building apps with tkinter/python/asyncio and I can't get over how fast the apps are to load and to use. There is none of this "let's not respond to the mouse for 5 seconds" that is staggeringly common on my mac (particularly for apps like Safari and iTunes that come from Apple) nor the "go for a walk around the block" loading times for Java-based apps on my i7 Windows laptop. True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are as responsive as Windows 95 apps were back in the day.
- eddieroger 8y ago
  Do they think that? I think more what thing here is that Electron apps are popular with UI developers who want to make the jump from web apps to native apps without taking the time to learn the platforms, or wish to reuse components they use on their web apps.
- androidgirl 8y ago
  The aversion is mostly that a lot of devs have learned to use html, css, and js for styling ui's. I love Kivy as well as QT. You can make some decent looking apps with the former and some incredible ones with the later. I have never personally worked with Electron. But yeah, most devs use JS, HTML, and CSS for ui creation because of the Web. I think something like QML could replace the html and css parts, though.
  - giobox 8y ago
    To add to this point, virtually all software companies have devs with web dev experience that can be very easily leveraged with Electron. Native app development skills aren’t nearly as prevalent in most organisations in my experience. The success of electron has never been that much of a surprise to me: write once, ship (almost) everywhere, use the team you already have. Often cheaper than upskilling the team as well.
- jniedrauer 8y ago
  > Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? tkinter specifically does not look very pretty without some effort. I would much rather use GTK or QT. The problem is GTK support on windows is limited, and QT has a weird license model.
jf- 8y ago
Is there a reason it’s not done as a runtime, i.e. have a single, electron-modified, backwards compatible install of chromium which all the electron apps run on? Then ship each app with the installer for that electron-chromium which gets installed if it’s not already present. Though I feel like even if that happened people would still complain about it, mostly motivated by web technologies encroaching on the desktop space, threatening other developers “turf”, so to speak.
- megous 8y ago
  No there isn't. For example on Arch Linux, you can do pacman -S electron and share the same runtime for all your electron apps. Though, I don't use any third party ones.
  - jf- 8y ago
    That’s interesting. Is there something specific to arch that allows this? It would definitely help to alleviate people’s concerns about electron if this could be replicated on other platforms.
    - megous 8y ago
      Nothing specific. You can do it with electron executables downloaded from the official website. Just run them, and drag'n'drop directories with the application's source code onto the electron window, or create desktop shortcuts that run "C:\somewhere\electron.exe C:\your\app\dir".
  - simion314 8y ago
    This would work only for packaged apps from the repos right? Better then nothing.
    - megous 8y ago
      I didn't find any apps in the repository. This works for apps you write yourself. You just run "electron ." in the directory with the app's source code. You can probably unbundle thirdparty apps, becuase what electron apps are, are basically "electron" + "other code/resources". But I've never even seen someone else's electron app distribution package, so I don't know how hard/easy it would be. And I wouldn't trust it anyway, if the code is transpiled/minified/unreadable. I run all my electron apps using a shared runtime.
ancorevard 8y ago
The root cause of the problem with Electron is that its performance on the Mac is just like the Chrome browser. Compared to Safari, Chrome’s performance is like a fat pig hogging your memory and devouring your battery life.
felixfbecker 8y ago
When I tried out Windows tabbed shell in the Insiders build I found myself using the web versions of Electron apps (e.g. Slack) way more than the apps. They can do everything the app can nowadays (including native notifications), and with tabbed shell, they can appear next in a tab right next to a native app - but with all the benefits of web apps: linkability, hackability through browser extensions, accessibility, no annoying update prompts. And of course only running one browser engine instance. You can even pin them to your task bar like native apps. I feel like on macOS many people install native apps only to have a dock icon. We really overvalue packaged apps
- drb91 8y ago
  > We really overvalue packaged apps I think splitting out services from the browser makes it easier to focus on notifications and use window management to change contexts. It is confusing and frustrating that Apple has not allowed saving websites to apps yet.
SigmundA 8y ago
Wouldn't memory compression and disk compression resolve those issues to some degree? Sharing libraries is definitely more efficient but at the cost of isolation and versioning issues. Similar to some of the reason vms and containers are used. Over time I have come to appreciate self contained apps and deal with redundant bytes at a lower level.
seanalltogether 8y ago
> This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. On the other hand, requiring a shared runtime has been one the key reasons that a lot of cross platform apps failed in the past. How many times have others decried the fact that they had to install Java or Adobe AIR or XYZ in order to run an app they needed.
- sime2009 8y ago
  Well, there was a solution to that last problem. Just bundle the whole runtime with the product each time. And just like that we're back at square one again...
- Splines 8y ago
  Steam seems to solve this fairly well. If you need a runtime it is installed along with the product.
jackpeterfletch 8y ago
- If electron worked like the JVM and each app shared a runtime You mean like eerr, chrome - and the web :P
blinkingled 8y ago
> - The operating system cannot share memory between different Electron processes [..] That should not be a significant issue in 2018 - all popular operating systems have same page merging support now and at least latest Win10/macOS also have transparent compression of memory pages.
- ryacko 8y ago
  Woudldn’t that break ASLR?
  - blinkingled 8y ago
    ASLR applies to virtual memory / process address space. Merging or compression is of physical pages - the page is uncompressed on the fly when the process accesses it. It works because the OS is in control of the Virtual->Physical mappings and can, on a page fault do the decompression transparently for e.g.
- ahartmetz 8y ago
  Compressing working memory is quite expensive in CPU cycles compared to just using it. Identical page merging is also reasonably expensive and only works if pages are, well, identical. Your Electron runtimes are probably not going to be bit for bit identical, not even small sections, due to offsets not divisible by page size. Tuning for better deduplication is possible, but then you're at an awkward mix of caring and not caring about performance.
  - blinkingled 8y ago
    Compression is pretty fast on modern CPUs so I would disagree about that. But yes depending on the compiler/switches/versions the Electron run times are not going to be bit for bit identical but it's a stretch to say there will be nothing in common - all the dependent library code for e.g.
scoopdewoop 8y ago
It is absurd the people that show up out of the woodwork every Electron article to complain about performance. Meanwhile, I have not closed Discord for more than a day or two in years. A quick Ctrl-Shift-Esc shows that it is using 180MB of RAM right now with ~20 rooms open, as well as DMs. Meanwhile, Discord has fantastic uptimes and never impedes performance while competitive online games run alongside it. The idea of trying to replicate the interface in something like tkinter is cringeworthy at best. Discord supports animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations right in the chat! Please, please try and replicate that with Tkinter, an API where you'd need to roll your own drag-and-drop. If i want to run discord as a website, using the same resources as any other website, i CAN! Its the same codebase and interface. I run the full desktop client for the better filesystem, game, and chat integration and it is worth the measley RAM on my modern machine. Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.
- zozbot123 8y ago
  > animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
- seba_dos1 8y ago
  Not commenting on anything else, but Discord app consuming 180MB RAM sounds like a mismeasurement. Here it takes almost 0.5GB right after launching.
  - mbell 8y ago
    They are most likely only looking at the RAM used but the 'Discord' process, which is just the native launcher code and OS hooks (on MacOS here, may be different on other OSes). The electron processes are called 'Discord Helper' and will be using quite a bit more RAM, though I still wouldn't consider it 'heavy'. The same process structure is true of Slack as well (maybe all electron apps, I'm not familiar enough to say). Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
Aaronmacaron 8y ago
I don't think a JVM like chromium engine would really solve the problem. Most JVM end user applications ship their own JVM. By shipping your own JVM one can avoid compatibility problems and most importantly the user doesn't has to install the JVM which makes for better UX. The same would apply for Electron. The only way I think a common runtime could work is if Electron used the Runtime of the Browser. If every browser exposed an API to run JavaScript and Render HTMl using the browser's Engine that'd be great.
- vincnetas 8y ago
  Why expose api. One could run web server on localhost and thats it. Open it with any browser and enjoy your crosplatform app. I think https://blockstack.org https://blockstack.org is doing something similar.
- vincnetas 8y ago
  Adding to my previous comment, you can even run chrome webpage without address bar on macos : /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=https://google.com https://google.com
manigandham 8y ago
Why does this matter on any modern operation system and hardware? What is the point of unused RAM capacity given fast mem/disk IO, compression and seamless paging?
- zozbot123 8y ago
  Disk IO is not always fast. Memory bandwidth is a huge bottleneck on current-day systems, especially on high-frequency, high-core-count processors. And so on and so forth. If you want a snappy and truly usable system you still need to care about performance issues, particularly given the rise in non-reducible system requirements e.g. for browsing the modern web.
Sindisil 8y ago
> If electron worked like the JVM and each app shared a runtime Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance). On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.

sergiotapia 8y ago

Either they start working towards performance/memory issues or this will very likely go the way of Cordova/PhoneGap. Feature rich, but ultimately forgotten and not used for new projects.

NatW 8y ago
I don't think VSCode is going away. It's built on Electron[1] and performs quite adequately for me, personally. [1] https://en.wikipedia.org/wiki/Visual_Studio_Code https://en.wikipedia.org/wiki/Visual_Studio_Code
- nni 8y ago
  I've only very rarely seen performance issues with VSCode...
- intertextuality 8y ago
  VSCode seems to be one of the exceptions. It's also not as fast as Sublime Text.
  - 0xCMP 8y ago
    Agree, but because it's JS and well designed plugins also affect the editor experience much less. Where in Sublime the Python based plugins which aren't designed around async and promise-like patterns often can lock up the editor waiting on them. VSCode is pretty much the best Emacs there is right now. Uses JS, has good package management, allows changing settings per "workspace" including enable/disable plugins, has great git support, pioneered LSP, and more. I literally want to hate VSCode, but there isn't much to hate and any weakness it has can/should/likely-will be addressed by a plugin.
  - GuB-42 8y ago
    Performance is the reason why I stayed with Sublime Text. I gave VSCode a try, and it is really great, and transition from Sublime Text is easy. They probably stole most of their good ideas from it, while improving on others, a practice that I definitely support. However, it is not as responsive. By that, I mean sub-second stutters, nothing game breaking, but enough to affect the feel. Note: coding in C++, using the LSP plugin on Sublime, and the standard language support on VSCode. Building and source control done separately on the command line. I use "modific" on sublime to see the differences, and the built-in support for VSCode.

CyberDildonics 8y ago

The biggest issue by far with every electron based program I've used is actually not the huge memory foot use or the hundreds of megabytes for a simple program, it is the latency of the interface. Every interaction ends up lagging like molasses, whether it is text input, window resizing, startup time etc. We have video games that run 3D environments with gigabytes of geometry and textures at 144hz yet people are making simple text editors and interfaces with a dozen simple components (like the ethereum wallet) that run xwindows streamed over a 56.6 modem.

jeffbax 8y ago
Nevermind the small but incredibly obvious stuff like keyboard shortcuts, drag and drop behavior and text selection…
spiralganglion 8y ago
I think this is an excellent criticism of Electron that seems to be buried. Sure, it’d be nice if the RAM usage and disk footprint of electron were smaller. Maybe the creation of some sort of shared single instance of chromium will happen, someday. But even if it does, the browser rendering process is really latent unless you’re extraordinarily careful. It’s very challenging to make sure that your app responds to input within one frame — batching updates with requestAnimationFrame creates a visible delay when dragging and typing. It’s possible to do better, but it’s hard and almost nobody does. And it’s easy to do a lot worse — RAIL isn’t aggressive enough. (My angle on this — I do high-performance 2d/3d animation work in the browser and in electron, with extensive testing of latency, energy usage, frame rate stability, etc)
- ahartmetz 8y ago
  I've heard a similar story about an app implemented in HTML5 and node.js (no good JS UI frameworks existed at the time). The fine-tuning took an extraordinary amount of time. I was on a project that redid it in QML in a fraction of the time with a fraction of the headcount and performance was great right away.

fabiospampinato 8y ago

Performance improves as each new version of Electron basically ships with an updated V8 engine, which usually improves performance, but they also work on optimizing Electron itself (for instance: [1]). I think most of the times if an Electron app is not snappy enough then the developers didn't spend enough time optimizing it, take a look at VS Code vs Atom for instance, I haven't used Atom in a while so maybe the situation in different now, but both are Electron apps, VS Code is fast and Atom is (was?) not. [1] https://github.com/electron/electron/pull/14633 https://github.com/electron/electron/pull/14633

InGodsName 8y ago
I think it's because VSCode uses typescript and it had better plugin architecture. VSCode also uses lazy loading so doesn't initate everything at once you click the launcher icon but does it progressively.
- fabiospampinato 8y ago
  VS Code doesn't provide direct DOM access to extensions authors, that's definitely a deciding factor. But a couple of years ago even simply writing inside Atom without using any extension felt sluggish to me. TypeScript gets downcompiled to JavaScript anyway, so I don't think that's directly a contributing factor, but maybe because of the type system they can spend less time debugging and more time optimizing.
- bitwize 8y ago
  It's because much of the guts of VSCode is written in C++ and optimized. Because, you know, Microsoft.
  - InGodsName 8y ago
    So eletrons lets you code part of it in C++?
    - fabiospampinato 8y ago

tschellenbach 8y ago

Lately Atom is running quickly for me, but Goland is very slow and resource intensive. So I guess it varies, but Electron starts at a disadvantage.

simion314 8y ago

>Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I think the main issue is the developers, some apps don't use so much memory where others seem to use too much for the features they provide, IMO most JS developers do not understand how GC works and how you can by mistake keep objects alive. There is also the issue where you do not have a default UI toolkit and some frameworks like angular are bad for performance(I mean how in angular codes I seen data binding trigger tons of unnecessary updates but maybe some will blame the developers using it wrong)