Electron is Cancer

You Wouldn’t Want to Spread Cancer, Would You?

A little while ago I posted some benchmarks comparing Nano, Vim and Sublime against Atom and Visual Studio Code, the latter two being Electron based applications and the results were somewhat expected. Electron applications are fat bastards that like to munch on your memory and I’m definitively not the first one to make note of that.

In that article however I went fairly soft on Electron and did not really dig into it, just ran through the numbers I got on my daily carry laptop.

However the feedback for that article was overwhelmingly along the lines of something like the following;

Well, it works fine on my machine, and I only have 32 gigabytes of ram.
- Silicon Valley Developer, 2017

If that’s you, well then that’s good for you, but just because something performs “well enough” on your machine doesn’t mean there are not any performance problems. You are not your end-users, and you if you are a developer most likely do not run average hardware.

Performance Still Matters

To me it seems a little bit absurd to have to even say this, perhaps it might even be a little condescending but it really seems that the more processing power we get the more sloppy developers are getting with writing good code.

So here it goes, performance matters, just because your process could hog the processor and memory does not mean you should. This is especially true if your application is one that has native equivalents, like a text chat client would have a minimal footprint, there really isn’t any excuse for being this kind of slacker.

An operating system is a cooperative environment, just as I won’t go back on a webpage that is intrusive and annoying I will not use an application that is intrusive and annoying.

A few years ago we could do amazing things with a few hertz of processing power and a few megabytes of memory, these days we get to use it all so we can render a blinking cursor icon!

Electron Is Easy

In one form or another, the argument that Electron improves productivity comes up a lot.

Electron is so great, we did not have to hire new people we can just use your web designers that we already have in-house and it is so easy!
- Someone Actually Said That

Okay, sure having a plumber cut out a square wheel from a plank is also a lot easier to do than having a woodworker carve a perfectly round wooden wheel, but it is gonna be one hell of a bumpy ride, and square wheels are actually fine, right?

To me, this seems more like a symptom of the general performance characteristics we see, if the only cache the developer knows about is function memoization or http caching then well you can’t really expect that application to stay within any sort of cache lines.

Bottom line; as an end user I really could not care less about how easy it was for you to make the application, if it is not working properly it is not working properly, being slow on today’s super fast hardware is a bug.

Let me just re-iterate that, as an end-user I do not give two rats asses about how you wrote your application, you can make excuses for the tools you used for it and praise it all day but slow is still slow and bad is still bad.

Electron Is Not Native

I tend to call Electron applications web pages whenever I talk about them, which in turn tends to piss off a lot of web developers but really that’s all they are. There is nothing desktop like about Electron applications, they always feel out of place, even the simplest elements like the native menu bar is not available.

They just don’t integrate with the operating system the way a native application is expected to do, is this not the reason that why we vowed to kill Flash in the first place?

Even stranger, lately there have been projects popping up that compile from C# to Electron. Yes, let that sink in, from native code (C# can be AOT compiled to native, has tons of GUI frameworks) to JavaScript, so that it can run as a webpage in the Electron browser.

I do not even…