By: +David Herron; Date: September 24, 2017
But a nagging thought came to mind yesterday. That Electron application requires running a large portion of the Chrome web browser. Meaning, my laptop not only has the regular Chrome browser running, but another in GitKraken, another in Visual Studio Code (and I'd been running Atom before discovering VSCode), and yet another for the application I'm developing. That's four Chrome instances, and the result simply is not scalable. Each additional running Electron-based app causes a whole new Chrome instance to exist. Is Electron an unscalable mess?
According to Activity Monitor the memory consumption is:
- GitKraken: 2.10 GB
- Google Chrome: 461 MB
- VS Code: 289 MB
- My application: 76 MB
The first three have been running for several weeks - it's been 52 days since my last reboot. A little experiment - I restarted GitKraken, and its memory footprint now stands at 86 MB.
Chrome has over 100 tabs open, except I use The Great Suspender to force idle tabs to go idle, which minimizes memory consumption. VS Code has several windows open with a few dozen files open.
This doesn't seem TOO excessive if I compare with the other app's I have open. Eclipse is weighing in at well over 2 GB. I started it up fresh this morning. I restarted it, and now Eclipse is consuming 560 MB of memory.
I have a copy of Enterprise Architect (a high end UML editor) running under Wine, at 400 MB of memory consumption.
Preview, Apple's PDF/image viewer, is open, with several PDF's open, and it's consuming over 1 GB of memory.
The Trello title-menu-bar app is running, and is consuming 199 MB memory.
This is the application I'm writing - an editor meant to be used with
AkashaCMS, the static website content management system I've developed. The editor is a little sketchy at the moment. It uses the Ace editor component in one pane, and a simple
<iframe> to view the rendered web page in the other pane. I'm using Bootstrap 4 for the UI framework, and the app can have multiple editor tabs open simultaneously. And to prove that we have Chrome, I've opened up the Developer Tools.
That is oh so very cool to have Chrome Developer Tools as part of your desktop app development platform. I've never seen a desktop GUI toolkit that automatically includes such a powerful tool. Usually tools of that caliber are purchased separately at a large price per developer.
But - having Chrome Developer Tools simply means that yes indeed the application runs on Chrome.
For some reason there are over 90 processes involved with keeping VS Code running. I have 13 top level VS Code windows, each with a few files open. Yes, I've got a lot of files open, but isn't the memory footprint excessive?
I'm not sure the article reaches any particular point. However, from my experience with cross-platform GUI toolkits I can describe what would be required to build cross-platform GUI applications with Node.js:
- A GUI widget library bound to Node.js. For Java there's AWT and Swing, unless you're from the Eclipse camp in which case it's SWT. For Tcl there's Tk. For Gnome there's GTK, for KDE there's Qt, and so on.
- A set of compelling GUI widgets
- Compiling that widget library for every platform, and a staff to keep the semantics straight while interpolating to the API's on each platform
It's extremely difficult to get it right, and every GUI toolkit I've dealt with was buggy.
That Electron does such a good job is because Google does all the hard work that I've just glossed over. Trust me - developing a cross platform GUI toolkit is excruciatingly difficult.
A detour - JavaFX
I first time heard of using HTML or CSS for desktop application about 10 years ago when the JavaFX project was starting up. I was there, in the JavaSE team, when JavaFX was announced, and watched over the next couple years as more and more people were sucked out of JavaSE to work on JavaFX.
In any case, JavaFX developers came to the Swing team for a discussion. The JavaFX developers tried to convince the Swing team that getting regular web developers on board with using JavaFX meant using CSS and other web technologies in desktop application design. I remember thinking that an extremely odd suggestion.
Back on track with Electron
What about the Chrome Applications model?
One way to skin this cat is the Chrome App's model that Google developed for Chromebooks. I've been using a Chromebook for several years, and for about a year used one as my primary laptop.
There's a whole App store running on Chromebooks, with a large number of applications available.
What's important for this conversation is that you have one Chrome instance running several applications.
In other words - what if you installed an Electron runtime on the computer, and then installed Electron applications to use that runtime? That would limit the memory footprint since the Chrome instance would be shared across multiple applications.
I'm not finding that Electron is as heavy-weight as you might think considering it carries along most of Chrome.