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.
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.
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.
Telegram for example supports most of Discords features, is native, and is incredibly fast.
I use Discord and like it, but it is incredibly slow at starting, switching rooms, and even just loading new messages.
But the most aggravating thing is that I can't type a message on mobile if I don't have internet connection. It requires connection to load the input field. Affects me every day in elevators. Most native apps just lets you write your message and sends it when connection is back.
Fine, Discord is useful, but I must respectfully disagree that their app is good. And it is definitely possible to make natively.
How about trying to replicate all those things in Cocoa, GTK, or WPF? When people kvetch about Electron performance relative to native apps, this is what they mean. At least over here in Crazy Finicky Mac User Land, I tend to be at least as concerned that Electron apps are just lousy Mac citizens. It's not just that they don't look like other Mac apps, they don't support Mac UI conventions and frequently don't support system services and scriptability.
It seems to me that most apps are written in Electron for two reasons: it lets you write apps in JavaScript that are conceptually very similar to web apps, so you're not learning a new weird-to-you language like C# or Swift, and it lets you go cross-platform with far less effort--you're writing one app rather than three. But this doesn't mean that you're not making tradeoffs in both performance and usability when you choose to go this route.
There may come a point in time when a well-written native app won't trounce an Electron-based app in terms of memory footprint, startup time, and integration with the host platform. But that time is not now, and it's silly to pretend otherwise.
> ... I tend to be at least as concerned that Electron apps are just lousy Mac citizens. It's not just that they don't look like other Mac apps, they don't support Mac UI conventions and frequently don't support system services and scriptability.
Which is the case with Chrome itself too...a pretty unpleasant experience on the Mac if you have finger memory or want to use your apps together. Sigh.
I also understand this critique but feel it's a bit hollow. Or at least I feel that despite billions of dollars in available funds the big software producers failed to create a solution that is better. They are simply unable or unwilling despite having the resources and a lock on the top engineering talent in the space.
I wish and hope that MS moving Edge to chromium is to provide a single host level run time for PWAs. It's a space they have flirted with and seem to be inching towards more quickly.
Also note that there is nothing keeping developers from adhering to Mac UI conventions that I know of. That's not a fault of Electron at all.
tl;dr - If Javascript and electron are winning it's because others are continually _failing_.
Adhering to Mac UX conventions is harder with Electron, because a lot of little things that apps get "for free" with the native toolkit have to be explicitly included or even re-implemented under Electron. Visual Studio Code, for instance, has explicit support written in it to be able to use macOS Services; earlier versions of Code just didn't work with them. If its UI was written in Cocoa, this would have just come along for the ride. And at least off the top of my head, I can't think of a single Electron-based app that I use which fully behaves like a Mac app in other subtle ways; for instance, Slack, Telegram, Atom, and Code all do their own weird things to control their settings rather than bring up a modeless preference window the way every native Mac app does. Maybe it's modal! Maybe it's modeless! Maybe it's a JSON file! Who the hell knows. Does it bring up any internal windows that look like the native OS's windows? Does it support all the common text editing keystrokes that Macs have supported since 1984? Does it even integrate with the system font selection system? [shrug emoji]
I presume this is true for other platforms/toolkits as well, and it's a tradeoff that doesn't get talked about as often as it probably should be. I'm not using a Mac because I woke up one day fifteen years ago and said, "You know, I'd love to pay a lot more for hardware than I probably should just so I can get minimalist industrial design, too few ports, and dubious keyboards." I use them because I like Mac UX conventions. I've talked to many people who actively prefer Windows UX conventions, or KDE or Gnome. I am not thrilled with the notion of a world where everything is a pseudo-native PWA.
> There may come a point in time when a well-written native app won't trounce an Electron-based app in terms of memory footprint, startup time, and integration with the host platform. But that time is not now, and it's silly to pretend otherwise.
It's also silly to pretend that users will notice or care, assuming a well written electron app. Again, look at VS Code. Now assume that the app is aimed at a non-technical audience who aren't going to be examining their resource monitors and who would never describe anything as a Mac citizen. If the customer doesn't notice or care, then the superiority of native apps does not exist.
It doesn't take that advanced of a programmer to know that a simple chat client like discord or slack should not take seconds (on the order of 5 to 6) to load! We are running super computers here!
> Try using the global search feature on Slack and tell me how that already existed in IRC circa 1995.
Isn't that particular feature mostly implemented server side?
On the other hand, yes, I agree that modern messengers has a lot of features that my IRC clients missed (voice comes to mind). Also they are easier for mainstream users to use and administer, and, compared to old IRC, safer in a number of ways (although I'd add that we are seeing a number of new threats now).
Ok, perhaps that was an over simplification - they are "complicated chat clients", but that still doesn't excuse the fact that massive industrial programs start instantly nowadays if they are native - think Unreal Engine, 3ds Studio Max, Blender, Sublime Text, the list goes on
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.
The Facebook Messenger tab in my browser consumes way more memory than that if left open.
Heck my Digital Ocean dashboard tab is consuming 155MB of memory right now (WTF DO?)
That said, I am blown away whenever I install an "old school" native Win32 app. The 90s APIs may have sucked to program for, but the end results stood the test of time.
Exactly, look at the "system" requirements for AOL Instant Messenger:
Windows 2000 or higher
Internet Explorer 6.0 or higher
128MB RAM/512MB for enhanced multimedia features (TOTAL RAM in the system!!!!!)
Macromedia Flash
Microphone and speakers/headset for voice/audio chat
It takes about 0.5 GB for me as well, but shared across three processes (main app and two "helpers"). Maybe parent commenter looked only at the main app's usage?
Could be, but I just checked again and the App takes ~29MB, and the two background processes take ~24 and ~136 for a total under 190MB. Whether it uses 1.5% or 4% of my RAM is meh either way in this case. Windows 10
Who are all these masochists using Tkinter? There are a ton other APIs to consider, and even more if one wouldn't mind updating an old one to be current (think XUL). I think this is the second or third thread where that particular toolset has been named as if it were the only alternative to Electron
I hate Electron too but is everyone really so new to the game that they do not remember desktop programming?
I'm working on an app that uses both PDF and web content to build a document repository that allows you to manage your reading with tags, annotations, etc: https://getpolarized.io/
The issue with memory consumption is definitely there.
But the issue for us is that if you're doing ANYTHING with 'content' you just have to use the web platform.
You need CSS, HTML and with pdf.js we have somewhat first class PDF support (though a few features are missing).
If it's a calculator app, then sure. Don't use Electron. It would be too bloated.
One feature in Polar that simply wouldn't be possible is support for web content caching.
We support downloading web pages for offline usage to allow annotation and to prevent bit rot.
It wouldn't be possible without some sort of web control but having full chromium (plus a webserver) means that you can setup a near perfect clone of the web but on the desktop.
[aside] @burtonator - what do you use for your pdf rendering? pdf.js? When I used electron a while ago it didn't natively support PDFs so you needed to roll your own with pdf.js. And the UI code to get full-featured PDF support (like a native browser) was quite complicated. Just curious if you found an easier way.
These are the same people who don't understand that a default, do-nothing app on something like macOS will be minimum 20MB due to the window backing.
I have a theory that the loudest complainers about this are the leftovers of the computer ricer era, who liked to display a bunch of metrics on their screen that mostly amounted to fluff. Electron solves real problems.
Signed, someone who's built and shipped native apps on the various platforms, and groans anytime he has to do a basic chart or whatever because it'd be 10000x easier in a web browser.
Edit: furthermore, the browser handles caching things like images and what not, which bloats up the memory in Electron. There is a way to force the browser to flush that stuff out, but nobody does it. If you have a local image cache for a native app and you don't flush it, you will get the exact same situation.
I have to restart Discord on a daily basis on macOS to avoid having it use multiple GB of RAM. Currently it has 3 processes running which are using 100 MB, 120 MB, and 1.2 GB of ram respectively.
Is someone forcing you to use Electron based tools against your will? The last three comments you’ve made on HN are gripes about it, it sounds like you’ve got an axe to grind.
Back when I had four megabytes of ram I wouldn’t have been furious over a 50kb editor. 200mb isn’t a lot when most developers are working on systems with 16gb or more of memeory.
My last comment on HN was four months ago, and incidentally also about Electron. No, nobody has a gun to my head, but a sadly increasing number of applications are Electron based, some of which I'm "forced" to use.
Yes, I hate Electron with a passion. It's a slow, wasteful framework for lazy developers who can't be bothered learning Qt or something else non-silly. IMHO.
The comparison is silly: in 4mb-era one didn’t have to run docker instances and assorted VMs and databases (yes, you can do it in the cloud, but that’s not cheap). Most dev stacks were CPU-bound, now they are mostly memory-bound. That’s why devs are memory-hungry, not because they want 3d emojis.
I’ve had no problem running 10+ containers while running Slack, Chrome, and a few other Electron based apps simultaneously and have never really had problems except for the heat it generates.
If a dev is working on a less capable machine I guess I can see why this is a problem, but a rather simple one to solve, close Slack, it’s a distraction to focused work anyways :)
On the other other hand, my WhatsApp is currently using 87.6MB (WhatsApp) + 115.3MB (WhatsApp Helper) + 99.8MB (WhatsApp Helper) for a total of 302.7MB.
(Creative Cloud is using 234.9MB and that's nothing more than a damn launcher!)
I just downloaded the latest WhatsApp update, ( I think it was released a few days ago ).
Now it is 164MB + 104MB + 85MB! And these measurement were not under high memory pressure! This isn't small by any means, still a total of ~350MB for a simple tool, but it is similar to Telegram which is a native Mac App. The two WhatsApp helper were previously using 700MB each!
And the major major improvement is compressed memory. Previously it didn't compress much at all. It was the same 700MB. Now it is 4.6MB + 5.2MB + 8.5MB, that is total of 18.3MB!!!!
I have no idea what happened, but in terms of compressed memory that is nearly 99% reduction in memory!
( Actually I am really interested in what happened, I wish they have changelog or blog post on the fix )
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.
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.
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.
> 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?
Um because a lot of them already know HTML/CSS/JS (because they've worked on websites). This the the major reason why Electron is popular - the barrier to entry is very low. That combined with the fact that users don't complain, just makes it a "pragmatic" choice.
I've made a few Electron apps, I don't use other cross-platform UI toolkits mainly for these reasons:
- I'm a JS/TS developer, with it I can make CLI apps, websites, Electron apps and mobile apps. This means I can also use the same set of UI widgets I'm familiar with across all platforms, I can't do that with any other native UI toolkit so far, maybe the situation will change with the advent of WebAssembly, but so far JS has basically been the only language capable of providing this.
- I don't think I've ever used a Java GUI app that didn't look like crap and wasn't a game, I've also never made a GUI app in Java, so this is just a guess, but maybe it's just easier to make prettier apps with web technologies.
It's easier to make GUIs that suit the developers own tastes with web tech than with real toolkits. Whether or not that is a desirable quality in applications is a matter of debate.
Personally, I liked it back in the Win95 days when everything used the native toolkit and I could change its appearance significantly through a simple control panel [0]. Back then, if I wanted a "dark mode" I just adjusted colors to make things darker, but with modern GUI bullshit it's a newsworthy item when someone adds "dark mode" as a feature.
If you've tried VS Code, is it of desirable quality to you? If not why?
Customizability-wise I actually prefer Electron apps to native ones, with a few lines of CSS I can remove stuff I don't need and tweak the UI a bit, I'm not quite sure you can do the same as easily for native apps.
Also you mentioned dark mode, an Electron app could support dark mode too, taking as an example macOS native apps they also have to explicitly support dark mode, so I'm not sure what you lose in this regard by non going native.
I would argue that going full-native win95 style has more downsides than benefits, for most people simply being able to change the wallpaper is enough.
> Customizability-wise I actually prefer Electron apps to native ones, with a few lines of CSS I can remove stuff I don't need and tweak the UI a bit, I'm not quite sure you can do the same as easily for native apps.
That's a fair point. GUIs have tended towards being less customizable, not more, and that's a huge failure in my eyes. However, the customizability of Electron applications is really a side effect of the fact that it runs on top of a web browser. I find it difficult to count that as a point in its favor.
Looking at it from that perspective, there are native GUI systems that load XML files for their GUI that could also be called customizable by your standard.
VS Code uses almost as much memory as a full IDE but does less. Sublime Text does almost as much as VS Code and uses much less memory, loads large files much faster, and opens new windows instantly. The last time I checked, VS Code didn't support Services on macOS or standard menu keyboard shortcuts on Linux.
Native apps use system colors by default. Electron apps tend to use static colors.
It's a bit of a circular argument: "I'm invested into using X therefore X is a good choice". This tells us nothing about the quality of X, although I'm sure it means the world to you personally.
I've no idea how good Xamarin is at doing the things that it does, but even if I hadn't invested X into my web-based components Xamarin would still force me to reimplement them again in case I need them in my website. That's not cross-platform enough for me, Electron in better in this regard.
My 2 cents is that tk apps look ugly AF as you mentioned and that GUI programming is a hard and thankless job... so people want to skirt around it by leveraging CSS which they already know.
Also if it's not built in JS, it's not cool these days
> Also if it's not built in JS, it's not cool these days
To me, it feels like if you want to be cool these days, you look down on JS/JS devs.
JS has plenty of issues, but it's undeniably successful - isn't it more beneficial to either improve the problems or figure out why it continues to be successful despite them and adapt that in your language of choice rather than dismiss the success as being "cool"?
I've developed in a few languages, with JS being the latest, and while I do in fact enjoy it (mostly), it's not because I'm cool. I'm almost never cool, and being a JS dev involves people telling me that remains the case in tech forums regularly.
</rant>
All of my bitterness aside, your point about GUI development is completely correct. I've been happy to see CSS slowly taking lessons from desktop GUI layout and hope for more in the future.
> To me, it feels like if you want to be cool these days, you look down on JS/JS devs.
The true hipster developer needs to be able to sneer at JavaScript with true derision while also having JavaScript be their go-to language for everything. Holding incompatible views at the same time about mostly inconsequential things is, after all, the true essence of being a hipster...
The pervasive belief that how it looks is better than how it works. End-users can be conditioned to wait for the application to catch up if it looks nice. If it's ugly, most folks will simply lose interest.
I prefer functionality over appearance, but I'm just a crusty old RDBMS DBA so I'm not sure my opinion can count for much.
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.
I wrote one GUI app in PyQt, and (ab)used the ability to put keyboard accelerators everywhere. Combined with a menu system, the whole thing was as-fast-you-can-think, like vim, but well a GUI.
Because people don't want to write Python or C++ and I don't blame them. Why is it that people don't recognize that people don't want to marry an ecosystem for a UI?
If we could just get a modern UI lib w/ a C FFI you'd see a node wrapper and the complaints would reduce (yes I am aware of lots of efforts and could enumerate them all, but many are lacking).
I think it’s primarily due to ease of use. Granted, I’m not an Electron dev, but I believe most “modern” developers would have an easier time writing a UI and application using HTML/CSS/JS, than a language like Python/C++/Java.
I’m incredibly partial to Qt and love the framework (particularly the ability to style it and its C++/Python bindings). But even after making a small GUI application I can see why some would prefer more simple to use frameworks, whatever the resource or performance costs may be.
Ease of use? What's easier, MS Visual Basic/Embarcadero Delphi, or the application-oriented parts of HTML/CSS/JS? Even Python (which is freely available) is not exactly hard, and there are plenty of native apps using e.g. WxPython. It's not "ease of use", it's more like webdev "brogrammers" wanting to have their cake and eat it too.
Agreed! tkinter is blazing fast and frankly I don’t give a damn about the looks if it means I can solve problems faster and with less errors (ex when I keep a lot of data in my wetware memory).
I'm dealing with this same issue. One thing contributing to the hand-in-toilet feeling is that you go and look for tutorials, books, even documentation on Tk and how it works with any given language, and most of what you find is 10 years old or older. Nobody appears to be using the cross-platform toolkits, unless you count QT and/or GTK.
It looks like Python is your only option if you want a community of any sort who is actually doing GUI development with a scripting language (Perl/Python/Ruby)
> 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?
Because it very much feels like so, especially with tkinter. And it's not only the toolkit, it's the OS integration, and installer and so on.
Because making a cross platform app with Electron is relative low effort and you get very good results.
Most of the other options are not even close.
I’ve been tinkering along that same path (for small utilities that wrap CLIs and file manipulation libraries) and have used ttk for a “native” look and feel that isn’t quite right.
I think an updated, nicer ttk would help considerably, as well as a bigger widget library, but there is little information on improvements to Tk as a whole (I can’t even find enough examples for asyncio...)
> 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.
Up until 2005 or so Qt had indeed a relatively complex licensing scheme where the available (i.e. the license of Qt) and compatible (i.e. the license of the application, due to their GPL exception allowing applications to use MIT, BSD, ...) differed by what was then Qt ports (e.g. Qt/X11, Qt/OSX, Qt/Windows). After that they always had a uniform licensing model for Qt, were the licensing was independent of the platform.
I have found installation of tkinter on Windows and MacOS is easy, which I can't say is true for GTK, QT or Kivy.
I wanted to like Kivy but it was more clear how to get asyncio support running w/ tkinter. The Kivy folks say they will go to py 3 only soon and support asyncio officially soon but I am in a good place with tkinter.
I am also thinking about a 2-thread architecture which may work well for Kivy since it is so heavily Cythonized.
You have to parse it anyway, and in either case (native or JS) you'll be using a pre-built facility for that. Plenty of "native" languages can have good JSON support these days, and the "create a wrapper for the API" part is trivial if there's one available already, even if it's JS.
For simple UI you need to understand how layout works and then use the drag and drop designer. IMO is much simpler then learning and debugging CSS issues.
If you want to create custom elements I assume is simpler to do it in html with a couple of nested divs, background images and some css rules and some trickery and most probably your custom widget is not accessible and missing some nice features. As an example I know toolkits(Qt,Flex4) that can render huge tables of data, allow customization and are very efficient and you don't need third party libraries for that.
...and I have 5 years of professional experience as a JavaScript developer, yet I strongly prefer to write desktop apps and utilities with Qt (both PyQt and C++/Qt) than Electron.
You do you, I tried to make a simple list on PyQt and everything went wrong, a lot of signal issues, a lot of debugging compile issues, missing dependencies, wronly versioned dependencies despite downloading QT straigt from the site, never again going away from CSS and JS. And with flexbox and SASS is a pleasure to write CSS anyways.
> 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.
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...
> 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.
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.
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.
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.
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.
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.
> - 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.
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.
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.
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.
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.
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
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 is doing something similar.
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
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.
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.
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.
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.
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".
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.
Thanks for the response, then we need to ask developers to offer a download option without electron, If I remember right when I download Intellij products there is an option to download with or without a bundled Java.
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?
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.
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.
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.
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)
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.
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.
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.
>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)
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.
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.
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.
I've been heads down into the Electron internals for 2-4 months now and working on a document manager for PDF and web content: https://getpolarized.io/ (self plug)
The inevitable thing that always gets brought up is memory usage.
It's really not insanely bad if the app is important. I wouldn't use it for a calculator but if it's an important app allocating 150MB of RAM seems worth it.
The biggest change here seems to be the build system and the upgrade to Chrome.
The Chrome updates are what's important here. Since Chrome is evergreen if your behind a few versions the standard libraries in NPM just stop working.
I got bit a while back when when they were a bit behind in releases.
I use some old laptops, the light one I'm using now (good for python dev) has 2GB. The reasonable option (bulky, heats up) has 4GB, the dev rig which I'm not using because age defects are showing up has 6GB. I don't use Chrome because my proliferation of tabs locks it up. Firefox manages fine (must have over 600 tabs open but FF loads just the current tabstrip bufferized segment.) Technology should be efficient in bad conditions.
I don’t think it’s reasonable to expect modern software to perform on hardware that’s 5+ years old. The standard ram for midrange laptops now is what, 8gb? At some point you just have to upgrade.
It's one thing when more resources allows you to do something that was not possible without them and entirely different thing when you need to throw gigabytes and gigahertz at programs offering less (because minimalism!!!1111!1).
What innovations Electron brings to the table? That web devs can now not only bloat websites but also desktop apps?
More resources should mean that I can do things that were not possible before, or that I can do more things at the same time and not that I can do less because someone is to lazy to learn something new.
You can tell when the average viewer of this site learned to program by how irrationally clingy they are to things like the concept of memory management.
It used to matter a lot more, when those people were learning, so now it has to still matter!!!111oneoneeleven
~5 Slacks! Oh, my! How will the proletariat survive?!?!
And yes, obviously if your computer is less powerful you can do less with it. Are you trying to argue that computers are classist because they don't work the same for poor people?
My 1st point is the same everyone criticizing performance bloat is trying to make: running our software in such inefficient way, even though we can, is not good. We could accomplish way more for the users if the underlying stack didn't by default eat so much of our performance budget.
The 2nd point is simply that unless you're only targeting upper class and tech savvy users, 16 free Gb of RAM will not be your baseline.
I have heard a lot of complaints about Electron on various aspects, but one thing it has done well is to open the niche of cross platform Desktop apps to an average regular developer like me.
It can be also used to quickly test an idea before dedicating platform specific resources.
I hope the team adds more features keeps Electron alive.
It's a feature, they feel like a part of the web, which is the more important platform, for the majority of people who spend most of their time using web apps.
For a while I though native mobile web apps had it, but now with PWAs, WebAssembly and the return of mainframe, sorry cloud, I guess they are here to stay.
IntelliJ has the same problem.
so does everything adobe creates
and ... honestly, almost everything that caters to a niche doesn't really try to be native, as that would often create an inferior product for that specific usecase.
though there are very bad examples as well.
all these chat apps like discord, slack and rocketchat for example.
Exactly, as a solo developer I can't imagine making a cross-platform app in 3 different languages and perhaps developing a landing page for the app in a 4th completely different stack.
I'd much rather learn 1 stack well, write the app once, and spend time _optimizing_ it rather then _reimplementing_ it.
Good point, right now I use Electron as a quick MVP for basic apps. If the apps become more complex, then we will talk about moving to a native platform if we need to focus on native libraries or performance. Pick the tool for the job at hand.
There are always many negative comments regarding Electron apps, so as a developer who has made a couple Electron apps let me briefly illustrate to you what the advantages are:
- I can use the same UI components that I use for making websites and easily share code between all platforms. Maybe this will change in the future with the advent of WebAssembly, but right now no other stack gives you this.
- Bundling a cross-platform auto-updating app is wonderful. I just have to configure electron-webpack [1] and everything is taken care of. In the past I've made a password manager with GTK3 + Python, bundling it was a real nightmare and I don't think the situation improved much in the last few years.
- Sometimes, like when you're going to need a HTML renderer anyway, using basically a browser for rendering the UI can actually be an advantage, a couple of examples:
Example 1. Evernote needs to render their notes, basically arbitrary HTML, and the macOS app uses Safari's engine for this. Now they have to check across all platforms if their notes are always rendered the same, even for rendering a simple note they show you a spinner, and the native UI is arguably ugly anyway. In comparison my soon-to-be-released Electron note-taking app [2] looks more native to me, it's faster, requires less resources, and I get cross-platform support basically for free.
Example 2. I was using Ship [3], an app for managing GitHub issues. The native parts of the UI were written in Objective-C, the issue/comments part were written using web technologies, and their server was written in C#. What you get is an app that doesn't work across platforms and sharing code between all the parts of your application is basically impossible.
- Lastly I'm by no means an expert on other cross-platform UI toolkits, but some of them try to mimic the native widgets and do an awful job at that, as a result I don't have any Java GUI app installed because they all looked like crap to me, how many do you have installed on your desktop?
>I propose that using web components for desktop/mobile applications is not a good thing.
Agree, every platform has it's distinctive look & feel and as a user I expect that my apps follow this for 100%.
Recently I checked out Flutter, with the 1.0 release i thought it's worth to play around with it. The first thing i did, was installing their demo app on my iPhone they showed on the release event. Within seconds I noticed that there was something wrong. They tried hard to reimplement the bounce effect during scrolling on iOS, but it just didn't feel 100% right.
I totally understand, that not every user out there has this sharp eye for things like that and that there is definitely a business value going cross platform, but this is not something I would be proud as a developer. It's the cheap root for the developer ending up in a cheap experience for their users. Share your business logic between platforms if appropriate, theme it for your CI if needed, but do the UI as expected.
I disagree. I think cumulative hours across the average spectrum of users, they spend far more time on the web / in a web browser / in web tech-based apps than they ever spend (or at least notice they spend) in a "native" app. The web platform has won. It is native toolkits that have to follow web conventions now (hyperlinks, routing, deep linking, system back buttons, etc), and there are users starting to complain when they don't. The platform distinctions are starting to be meaningless to users so long as basic "web" usability is met. (I've met people that switch between Android and iOS regularly based upon whatever was a cheaper device or had a better plan with their carrier. Those sorts of people absolutely don't care about "native" widgets and see the differences in platforms as a silly barrier to the web.)
(Arguably that's a problem with Flutter too because it isn't "native" nor "web", it doesn't entirely meet the expectations of web users currently either.)
For better and worse, the web is a ubiquitous platform, and I think getting to be just about the only platform that matters today, regardless of the remaining fan wars between the "native" platforms.
Even though they are old, the trend at the time was clear: people are spending more time in apps (most of which are probably native) than on the web. The idea that the web is universal and what most people spend their time on isn’t a fact you have established.
Web technologies are loved by developers for their speed and ubiquity. But as a user, I strongly prefer the feel of mobile apps for my day to day interactions. I find the web, particularly on mobile, to be a mess. The interaction models are all unique and confusing and typically not well implemented, while native UI widgets work well and are understood.
But your mobile device is also only one device you interact with in a day. Very few people have the same OS across all their devices, even if you allow for the "close cousins" scenarios like people that only use iOS and macOS. Everyone uses the web everywhere, though, it's the one thing guaranteed to tie all of a user's devices/accounts/actions/"digital life" together today.
I don't have numbers to back it up, I have a lot of anecdotal evidence I've seen, but it does look like there seem to be at least as many people that don't care what widgets an app uses, so long as the app works, as there are people such as yourself that even notice native UI widgets and care about them (deeply and vocally, as often the case may be).
Perhaps, but I surmise that most people spend a large amount of their personal time and life on their mobile devices while people who are using full computers are generally doing so for work. I have seen it personally in my work that native mobile app usage has surpassed both desktop and mobile web usage.
> I propose that using web components for desktop/mobile applications is not a good thing.
It may not be, but it can be the difference between a developer releasing something that has real value to end users versus not releasing anything at all.
One could say that building an Electron app is an example of doing things that don't scale.
As a solo developer using Electron means that I don't have to reimplement all the UI components I already have, and I can publish a decent cross-platform app, where instead of spending time reimplementing everything across platforms I can spend time optimizing it.
I know of no other framework that gives me this power.
We use websites with different UIs every day, can you imagine if we were also complaining that Facebook doesn't feel "native"?
The difference boils down to feel and behavior. You can style web controls to look very close or identical to native controls, but they’re always going to feel “off” with issues like increased latency, wrong animation curves, and lack of support for system features (such as spring loaded dragging and drag and drop on macOS).
Electron is amazing for dev velocity. I love it there.
However, most importantly for my day job, it's not good for security. Adopting Electron requires me to accept the same structural weaknesses that led to all of the NPM malicious commit issues that have cropped up lately, and with Electron it runs as me, the user, not inside a browser sandbox. As a dev in a security team, not inadvertently creating attack vectors is literally part of my job, so that combination of factors is scary. In hindsight... I'm putting Discord in a sandbox.
Other native languages/SDKs/frameworks don't have this issue if only because so much of them come from first party entities and it's very viable to cut implicit trust to the repositories.
That makes Electron not a viable option for anything related to my day job unless it's guaranteed to be running in a VM, closed off from everything else. When some of the Node.js permissions related stuff gets put in, I'm going to like Electron much, much more than I do now.
> and with Electron it runs as me, the user, not inside a browser sandbox
You could actually not use any external modules in your main process and have the renderer process sandboxed [1], node integration [2] can be disabled too.
Thanks for bringing this up, I wasn't aware of the option. This changes how I look at the trade-offs of using Electron.
Unfortunately, that only covers the rendering code, and it still backtracks a lot of the reason putting JS into a native environment is convenient in the first place. But it's a lot better than the "nothing at all" I thought it was before.
We know that, it is the attitude of making it easier for developers and then letting the customer have to make quite big sacrifices that create the negative comments.
VS Code is built on Electron, which means it has a huge advantage from my point of view as a user: I can just remove stuff from the UI that I don't need and tweak it a bit with a few lines of CSS. I'm not sure what quite big sacrifices I'm making for this.
There are definitely awful Electron apps, but that's usually because of the developers, not because of Electron.
You can do the same with emacs because it's hackable enough, but you probably can't do the same with other native non-hackable apps like Word or Photoshop. I could do the same almost as easily with any Electron app, kind of like you can customize any website on your browser.
You have to separate performance of the application and the runtime. There are a lot of applications out there that are based on electron that are perfectly reasonable that are used by loads of people who by and large don't complain about performance issues. I tend to have several open at any time. Yes, they use a bit more memory. That's why you have virtual memory, ssds, and cheap ram these days. It's a complete non issue for anyone with decent equipment from anywhere in the last five years.
If you are so unlucky to be stuck on an ancient laptop with not enough ram, spinning disk, and an OS that doesnt't do the right things with virtual memory (non stop swapping for no good reason), that's going to be noticeable and annoying. Been there, done that, and it sucks.
If that is the case and you are a professional developer, get some decent gear, set it up properly, and stop whining. If on the other hand you are an end user, adjust your expectations accordingly to the fact that you are running old crappy hardware and don't try to install everything and the kitchen sink; or alternatively just be patient. Most users need nothing else than a browser running these days.
All fine and good but if there is a native app that has the same feature list, I’m going to choose that one 70% of the time and go without the other 30%. So long as you are also aware of that demographic it’s hard to argue with any of your other points from the dev POV.
There are definite a lot of advantages to building with web technologies, it's just that Electron is an excessively heavy way of enabling it since it basically just gives you a webapp with a whole browser bundled in. PWAs are a much better alternative since you can just use the one browser instead of having one running for every Electron app.
Yup, another good example of this is Hyper vs. Terminus. Both Electron apps, but Terminus is way more performant and less memory hungry. I've taken that (along with Slack vs. pretty much every other Electron app) to mean that yes you're going to get some sort of inherent performance hit going Electron over native, but a huge performance hit can arise from a crappy architecture/implementation. For instance, doesn't Slack use a different webview for each channel?
The MS team worked very hard to make it snappy; e.g. it doesn't dump the entire file into the DOM if it is big (but rather materializes it as needed, and removes sections not viewed).
That's the kind of tricks that the DOM (so web and also Electron) were supposed to make irrelevant.
Write an app "naturally" with Electron, and it will likely be slow because of the DOM <-> data impedance mismatch. That's what slack is guilty of, but the ability to do so is Electron's claim to fame.
That's an area where Mozilla could have distinguished itself by being very developer friendly. A few years ago I was looking into embedding a browser and XUL would have been a good fit but it was pretty obvious that it wasn't supported well.
Same for their Javascript engine. Node could be running on Mozilla code instead of V8 if Mozilla had been more developer friendly.
GeckoView is going to be the basis of new products, so I think it will have a more secure future than some past Mozilla efforts: https://wiki.mozilla.org/Mobile/GeckoView
There's more to Electron than that, but this might make it more feasible.
This was actually a thing a decade ago. But Mozilla did not keep engine and browser well enough separated, causing a lot of overhead for app developers basing their programs on the gecko engine.
I like Electron's features, but I don't like how it runs its own Chromium. I'd really like a small, local server launcher that just runs whatever default browser the user has selected, with a borderless window. No attempt at auto-integrations between client-view and server code, just let me do it like a regular SPA. Bonus points for letting me specify my own server executable, so I can do it in whatever language I want.
EDIT: seriously, it could run its own local server for privileged OS integrations, giving you an IPC API over REST.
There was a rumour that with Edge going to chromium MS wants to make the engine available on windows so that electron on windows wouldn't need to ship with a copy of chromium.
Given that Microsoft recently acquired the primary Electron developer, GitHub, that concept seems plausible. And I have a difficult time finding fault with it.
You see endless 'concerns' about Electron resource usage. What you don't find are complaints that it's unstable, or that it only works on some desktops, or that it's hard to understand or use. It's solid, it works on all desktops and it's about as easy to use as such a thing can be for contemporary full stack developers.
For better or worse I think the whinging about resource usage isn't going to hinder Electron much.
For Chrome users that leave the browser open all the time, is there a reason to choose an Electron based chat-app, that usually sits in the background, over just installing its PWA on the desktop?
Chrome now supports native notifications on Windows/macOS and even apps without full PWA support seem to work fine by just creating a shortcut and setting it to open as a new window without the browser's UI.
For me the reason would be first-class status in the taskbar/dock. I like having some apps only a click away and in its own window, not lost among many open tabs.
For some time you could do that with any web page in Chrome, with "the create a shortcut" option. But now Chrome opens them in a new tab, not in a dedicated window.
After adding the new shortcut you can go to chrome://apps and right-click on any app to select "Open as window". This should bring back the desired behavior and these app shortcuts now have their own entry in my taskbar/dock.
Yeah, there's lots of little things in the Electron API that would be good to see adopted into PWA standards. Probably also some Node native modules out there that would be good candidates for PWA standards.
With so many Electron apps in the wild these days, it seems like a great opportunity for the standards bodies to comb them for good ideas for greater platform-wide adoption. (What are people doing in Node processes in Electron that would be tough to do in {Service, Web} Workers? What APIs for deeper native integration would be of benefit?)
One major issue with Electron that I don't see talked about much is backwards compatibility. This release states that because Chrome no longer supports Mac OS 10.9, Electron doesn't either.
Resource usage aside, there's far too much control of a given app being given to the Chrome team.
Ouch. Thanks for mentioning the issue. I'm still happily using 10.9 on my main laptop and in no rush to change, and I was hoping to look into using Electron for a project, so that's going to be awkward.
Having used all of the subsequent iterations of OS X, now I will be reverting to my Time Machine copy of 10.9 because really, the usability of it has gone downhill from that point on. Or even 10.8, I'm not yet sure.
Who cares if it's secure but sucks so much that I'm not using it anymore?
The performance really isn’t that bad at all in my experience. The complaints you see are developer complaints, where they’re talking about resource usage that ordinary users would never notice or question, or UI lag that most users wouldn’t care about (I only add this because someone else in this thread claims to have encountered it, but I never have, or have never noticed). If you find web apps running in chrome to be acceptably performant, then electron is fine for your use case. But naturally, a native solution will be faster if you’re doing something that really is resource intensive.
VS Code is electron, I use VS Code every day without noticing any issues. I think the complaints about electron are moot.
> where they’re talking about resource usage that ordinary users would never notice or question, or UI lag that most users wouldn’t care about
But this is such poor logic. We can notice these things, while regular users just suffer not knowing why their battery drains so quickly, unable to pinpoint the problem.
No, it’s not. It’s at most a trade-off. Some developers will doubtless make this their hill to die on, but I suspect it really has nothing to do with performance or battery life, and it’s likely motivated by resistance to web technologies being used on desktop vs what they’re used to.
Also I’d like to see some actual battery life benchmarks for electron, because I don’t imagine that it’s a huge deal, but benchmarks would prove the matter. It also ignores actual desktop users or users who just use mains power all the time.
If you’re on a Mac, open up activity monitor and watch which apps use the most energy. For me, the energy used by Atom, Slack, and Chrome is vastly higher than the energy used by other apps (inc. Safari loaded with tabs). It’s possible to make an energy efficient Electron app — you just need to aggressively shut off event loops when there’s nothing to update, which is hard so most app (and site) devs don’t bother. (I make complex animations on the web, so I’m hyper attuned to perf and energy use)
Not yet, though I'm keeping my eye on WASM and will pursue it if the need arises. The sort of work I do has relatively little overhead from the JS, and is mostly bottlenecked by rendering (SVG, mostly). WASM wouldn't help my load/parse times since I rarely ship more than a few Kb of JS, and it wouldn't help my per-frame times or latency because I'm usually done the JS part of the frame in around 1ms.
Now imagine if they were all electron based and therefore consuming 1GB+ each?
Also we need to take into account that it feels slugish and they are not as responsive as other apps, and i guess it has to do with JS VM reaching the tipping point of what it can do and optmize..
Anyway, my main point is that the big problem will happen when you stack those things.. than a computer that should be more than enough, just isn't.
Even the user with low tech awareness, will close the app and feel his computer is working better.. and they will blame the company who makes the app for making their computers feel slugish in the end.
Except that they don’t need to consume 1gb+ and they don’t need to feel sluggish. We’re also not talking about replacing every native app with electron.
> Except that they don’t need to consume 1gb+ and they don’t need to feel sluggish.
The problem is that is built around V8 tied up to Node.js, so i cant see how it will get any better giving V8 is a state-of-the-art VM already very optimized and using little resources as possible. Also you are tied to blink/webkit which together with V8 will consume a good chunk of memory and you as a dev will be unable to optimize further, giving you can use anything other than JS and blink.
> We’re also not talking about replacing every native app with electron.
Of course not. But the problem here is the trend. Companies will see how cheap it is to just reuse cheaper human resources being used to the company web dev, and how fast you can prototype an app.
The other companies who create better products because they care more, will have a hard time competing with the cheap sketchy software that cost less to build, and the worse products will likely win.
> The other companies who create better products because they care more, will have a hard time competing with the cheap sketchy software that cost less to build, and the worse products will likely win.
They’re not cheap sketchy products, you keep mischaracterising electron apps so that you have a point.
Let the market decide. If the native apps are superior, then customers will choose them more often and companies will feel the pressure to use them. Unless of course customers don’t care, as I believe, then any argument about their superiority is meaningless.
It's not a free market, though because right now there isn't really a direct competitor to e.g. Slack, because the trade-off of developer convenience vs performance seems to be working in Electron's favour in that nobody else has brought a native competitor to "market".
> They’re not cheap sketchy products, you keep mischaracterising electron apps so that you have a point.
I still have a point even if/when the electron based ones have more quality or are better from the consumer point of view, because my point was not about the final quality of the finished product, but about scale and economics. Im not saying that every electron app will be inferior, this is illogical and unsustainable..
Rather im arguing that the whole model that the Electron represents will flood our desktops and even phone with cheap, memory hog apps, even when some of than are great, collectively they will be a nightmare to our computers. Users will blame the OS, or they will figure it out when they close the Electron apps, seeing their computers working better (And i guess when they get to this they will blame the company that created the product, and the bad word might start to spread).
Even with all the computational power we have now, we will have a even worse user experience than we had in the 90's with very limited computers compared to nowadays.
> Let the market decide. If the native apps are superior, then customers will choose them more often and companies will feel the pressure to use them.
My point being in the end, you wont have any options, and in some cases great products might vanish.
Im very critical of all things Apple, but this is one of the things i think Steve Jobs got right, and no wonder Mac OS and now iPhone worked out as a shield for great products that would not survive in the "worse is better" environment of Windows and the Web.
They are also great, accessible, popular, etc.. But if they were the only game in town a lot of great products would not have survived and others would not have been created. Thats what i fear about if the Electron trend gets too much hyped.. We will move fast and break a lot of great things in between.
If it gets popular, but not the monopolistic kind of popular, then its great, and good that its there as an option. But in tech we use to jump from hype to hype. (And you also can see what im trying to elucidate here by following whats happening in the NoSQL vs SQL database front)
No one is hyping electron Oscar, quite the opposite: HN is ceaselessly negative about it, and for very thin reasons that just don't cut it for me.
I think you do get close to the real reason for this negativity when you say that you're afraid of it - I suspect that electron is threatening to many developers exactly because it has so much potential. It dramatically lowers the bar for access to desktop development, works on all platforms, and if it really catches on (and this is probably worst of all) it renders much of their native development experience useless.
The criticisms that it doesn't automatically look and behave natively and that it is more resource intensive are true, but I don't think they really matter. Developers here seem to be deliberately overstating the case against it in an attempt to make it go away.
Anyway, the argument doesn't matter all that much either. Electron is such a good value proposition from a development standpoint that it'll continue to see growth, and with it further optimisation, and eventually it or a web tech orientated successor will end up being pretty big.
Try the applications and judge for yourself. There are tons of them. Most people are probably OK with the performance of apps like Spotify, and have never come close to exhausting their memory or disk space. I think being able to use HTML and CSS for layout, but with full access to native APIs, is a huge reason electron keeps winning despite the hn complaints. I’d be happier without it being JavaScript-based, but there are nice languages that compile down to it, like Elm and clojurescript.
I would also like to echo this. Yes most of everyone on HN hate Electron and they can point out any number of reasons why it's bad, and they would correct. In spite of the technical problems Electron is still seeing growth and continues to ship in new products.
If you think Electron works for what you need I would say use it and just ship, once you have more resources reevaluate if it is or is not working.
Well, performance and memory usage are two separate things. Electron's performance is quite good and if your audience is "computer users at large", they won't care at all about the memory usage. I'd say you should almost definitely use it if you want to target Mac + Windows + Linux. Just know that you'll get wrecked on HN ;-)
> if your audience is "computer users at large", they won't care at all about the memory usage
I'm quite sure that you got that backwards. Your dev machine may run Electron apps fine with 16GB RAM, but a huge majority of average folks are on 4GB and often less. And they're already running Windows 10 (or at best OS X) and a web browser with a bunch of open tabs!
I used to be an Electron hater, but I realize the problem is less Electron itself, and more has to do with how well it was used to develop the app.
VSCode and Discord to me are notable exceptions, whereas most other Electron apps feel pretty sluggish. They must be doing something right that other devs using Electron are not.
That said, I do still prefer the performance of native apps. Even though VSCode is fast for an Electron app, when I switch back to Sublime Text, I still realize the performance gap is there (especially for launch times, when I'm opening a bunch of small files at once)
Consider that each Electron app runs its own instance of Chromium.
Chromium itself is a memory hog and apps like Slack routinely take up to a gigabyte of memory. For a fucking chat app.
How many Electron apps does the average developer run on his machine now? I'm back-end developer and I still need four or five Electron apps running to do my job.
All in all they are taking up between 4-7Gb of memory. That's just absurd to me, and we are all on 2017 MacBook Pros with 16Gb RAM. Combined with Docker, IntelliJ, Robo3T etc, I'm pushing up against my RAM limit frequently, because Electron apps are all a bloated mess. Every single one of them.
It's even worse if we start getting multiple end-user apps are written with Electron, because the average consumer machine doesn't have a lot of memory like developer machines tend to have.
This kind of development shouldn't be encouraged in my opinion.
The performance complaints are mostly from developers. Users of your application, if it is important to them, will not care.
The big thing about Electron which most developer discussions miss is that it enables low-cost multi-platform development, especially if you already have a web app. In this age when people would like to pay as close to 0 as possible for software, this is important. I have a SaaS app and people keep asking me about apps for iOS, Android and native Mac/Windows. There is no way I could afford to develop+maintain for even one of those platforms. Of course most people who ask about this would like to get the additional platforms for free :-)
Electron makes it possible for me to re-package my app as a native one, with certain benefits (easier file uploads, access to printers and peripherals, etc), and with a reasonable cost.
Less advanced users complain when their computer is slow. Developers know how to locate the problem and that it could be fixed.
Everyone here knows that Electron is the cheapest way to wrap a web app. It's obviously the fastest way for someone with web but not desktop experience to create a minimum viable desktop app. It isn't the only option for low-cost multi-platform development.
You have good reasons for producing a hybrid app instead of a native app. It's questionable whether Slack does.
Slack, Spotify, VS Code, Insomnia and many other apps use it. They use excessive amounts of resources for what they are, but really any modern machine shouldn’t have a problem with it.
I use Electron as a quick MVP for basic apps. If the apps become more complex, then we will talk about moving to a native platform if we need to focus on native libraries or performance. Pick the tool for the job at hand.
I have high hopes for Electron. In some regards, it feels like the new Java. I remember in the early days, using Eclipse and thinking how bad the performance was, but appreciated all the functionality it brought, despite being written in Java. Now days, I am in love with the JetBrains IDEs, and don't think twice about the fact they are Java. The performance is great, and they look good (IMHO). I suspect that in the future we will feel the same way about Electron apps.
So someone should clearly fork it to Firefox. Not me. Not if you want it done right. There has been a lot of talk on HN about Chrome having to big a slice of the pie. Whelp.
I've worked with Electron and previously NW.js for over 6 years. Here's what you need to know – if an apps performance is bad 99.9% of the time it's the developers code, not Electron that's the issue.
Sure, the bundle size is large and the memory footprint is ~200Mb but those should not be limiting factors if you have a computer from this decade.
A lot of people express concerns about Electrons resource usage. I wonder if people are aware of projects like zserge/webview [1]? It provides a cross platform API on top of the built in platform browsers and thus is very lightweight.
Of course, it means you have to deal with cross-browser issues, but I guess webdevelopers are used to this anyway. I'm also aware that these projects don't provide all the APIs that Electron provides, but many apps that are really just a wrapper around a webapp this is totally fine IMO.
That doesn't seem like it would solve anything, unless I'm missing something substantial. Which specific browser engine it uses isn't as important for resource consumption as the fact that it's spinning up an entire browser engine per process.
Isn't it funny the Palm Pre was in some sense what Electron apps have become? Just an anecdote - I understand all the differences between them but I didn't even think at the time the Pre came out that it was "ahead of it's time" but I suppose it was - then again there was also the iPhone that killed it as well.
The thing about Electron (that is often drowned out in these threads) is that it's a web browser, which means... like any website, there's a litany of weird performance tricks you need to know and be aware of to make a good performant UI that doesn't have performance degrade over time.
Like many websites in tabs in a browser, sometimes... it's easier to just kill the tab or window, and re-open it. Usually a sign you've done something wrong in your UI handling code.
One of the less obvious reasons why Electron has become so widely used is that Apple hasn’t invested anything meaningful into improving AppKit in the last 5-10 years. If Cocoa was a joy to use I’m sure there would be more native apps.
It was going to be, but they didn't have enough minorities and woman giving talks, so they cancelled it. Looks like they deleted the announcment, but here is an old reddit post where people are talking about it.
I stay away from Electron and JS desktop apps in general because:
- Huge distribution size. Your code is 1% at most. 99% is redundant. I want 10 meg at worst hello world dist size.
- This is more a problem in JS ecosystem in general: No good enough standardized or not way to do the frontend part of the app. Angular is not good enough, neither is React or anything else. Though it is gradually getting better.
Think this is bad? Just wait until everyone adopts asm.js. So we can compile C++ code to "fast web apps" which will run in the asm virtual machine, in the javascript DOM sandbox, in the thin webbrowser client, and finally in the OS.
You can laugh, but that day is coming and I fear getting armies of college grad hipster-coders creating unreliable slow layered software until we have nothing but "Material" UI flat buttons and cursor lag when typing simple messages in a simple application. AHHHH
You forgot the new OS wars, which happen on top of this "platform". Remember guys, one more layer of abstraction is all we need, then there will be no more problems forever!
ROFL, at some point there will be a javascript CPU (https://twitter.com/steipete/status/1047415826083729408) - and the entire OS will be asm.js. Then the cycle will begin anew with web browsers being built for the OS. God help us all D:
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.