Electron sucks, but so does the rest

Published on the 11 March 2020 on Jamie's Blog

In the early days of Electron, it was pretty cool — allowing hobbyist developers to quickly build desktop applications, reusing skills from the fast-emerging Javascript frontend frameworks for the web. For those non-web developers, it presented an opportunity to build desktop applications with an emerging technology and learn web development in the process.

With the obvious exception of Atom, Electron applications seemed to be restricted to hobbyist developers — making freely available software, with little to no financial backing… Then came Visual Studio Code, then Slack, then Discord, and so on.

Electron increasingly became used by those who could not reasonably make the low-barrier-of-entry excuse. There is so many major companies using Electron now, its saddening — particularly to see the world’s largest company embrace it so hard. Electron’s image to me was tarnished, it was no longer the cool framework for hobbyists — it was a sinister force replacing traditional desktop applications.

Crash Bandicoot developers took to overwritting the Sony C library to use more memory. Ars Technica

This is such a stark difference from development 20 years ago, where programs were extremely well optimised — given the limitations in hardware. Its a shame that the craft of efficiency seems to becoming extinct, with individuals and companies seemingly lost the desire to maintain this…

Though perhaps Electron is just a choice in a sea of bad choices…

A Case Study

Feed The Beast and CreeperHost have just launched their new modpack API and installer (FTB App), revitalising their own services after their partnership with Twitch (formerly Curse) came to a close. It is a replacement for their older Launcher, and distributing their packs through Twitch’s service

While I give exception to a small business (who don’t do desktop development) and a group of content creators, there is a certain performance regression moving from their previous, Java-based, launcher — only a 150 megabytes or so in memory, though I’d still rather the game have as much as it can.

Process Hacker open, showing process information for the FTB App
Process information for the new Feed The Beast App
Process Hacker open, showing process information for the old FTB Launcher
Process information for the old Feed The Beast Launcher

Though this is perhaps somewhat of an apples and oranges comparison, since the new FTB App doesn’t handle launching and can be closed down when playing the game — effectively making the overhead when playing 0. Still, nearly 600MB in memory for a glorified installer is overkill.

(For those not in the know, use MultiMC)

So what should developers use?

Now while I would like to discuss fantastic alternatives, native cross-platform desktop GUI development is near none-existant or inaccessible to many developers…

The stalwarts Gtk and Qt are written in C and C++ respectively, and while bindings for many popular languages exist — they are often either don’t feel native to the language at hand, are difficult to develop with (a particular issue on Windows), or are more opinionated than many developers would like.

Gtk is difficult to develop with on Windows, Qt is increasingly turning its back on the FOSS community — requiring developers to sign up to download their SDK, and more recently alegedly considering not releasing code until 12 months later.

The Rust community is struggling to determine how to build a GUI solution; and in the Go community, Google’s GXUI was shelved, and other than bindings for Gtk, Qt and frameworks to similar effect of Electron, there is little.

One promising library is libui, though that isn’t quite there yet…

So perhaps — just maybe — Electron is a sane solution, despite its horrendous memory usage. I guess for now, until a viable native cross-platform solution thats accessible becomes available, we will have to accept Electron.