Slashdot Mirror
In Defense of the Popular Framework Electron (dev.to)
Electron, a popular framework that allows developers to write code once and seamlessly deploy it across multiple platforms, has been a topic of conversation lately among developers and users alike. Many have criticised Electron-powered apps to be "too memory intensive." A developer, who admittedly uses a high-end computer, shares his perspective: I can speak for myself when I say Electron runs like a dream. On a typical day, I'll have about three Atom windows open, a multi-team Slack up and running, as well as actively using and debugging my own Electron-based app Standard Notes. [...] So, how does it feel to run this bloat train of death every day? Well, it feels like nothing. I don't notice it. My laptop doesn't get hot. I don't hear the fan. I experience no lags in any application. [...] But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel. For context, the project I work in is an open-source cross-platform notes app that's available on most platforms, including web, Mac, Windows, Linux, iOS, and Android. All the desktop applications are based off the main web codebase, and are bundled using Electron, while the iOS and Android app use their own native codebases respectively, one in Swift and the other in Kotlin. And as a new company without a lot of resources, this setup has just barely allowed us to enter the marketplace. Three codebases is two too many codebases to maintain. Every time we make a change, we have to make it in three different places, violating the most sacred tenet of computer science of keeping it DRY. As a one-person team deploying on all these platforms, even the most minor change will take at minimum three development days, one for each codebase. This includes debugging, fixing, testing, bundling, deploying, and distributing every single codebase. This is by no means an easy task.
I had never heard of it so I googled it.
Oh, a new text editor, maybe I can use it. Click on the download link.
163MB for a text editor, ouch!
I do not know about RAM usage but that thing is already a hog on my hard drive...
Atom is vaguely OK, but I wouldn't care to try to maintain js, but Slack is like being trapped in a large echoing room filled with people madly shouting "ooh, shiney!"
It also dragged my 32 GB dev server into the weeds, so I probbaly agree with the criticisms of Electron proper.
davecb@spamcop.net
Let's face the truth: Electron delivers a Chromium engine, Node.JS and V8, all rolled into one package to you. So of course it's a memory hog, depending on what you are going to program, like a terminal, clipboard manager or tiny frontend to FFMPEG [all existant projects]. All those programs alone need 200 MB for the runtime engine, to just do really simple stuff.
It also needed 13% of CPU time to just draw a blinking cursor (!).
It's mostly used by shitty webhipster design startups, which are just way too lazy to learn a proper programming language, and it even doesn't fit well with the UI of your operating system. And since the underlying parts of it, when a program gets delivered, aren't for sure update as frequently as Chromium alone, it's a security nightmare as well.
So far my experience has been atom and mattermost desktop.
For atom, everyone was swearing*so hard* about how good an editor it is, and it's frankly not that good, a resource hog, and just generally a bit glitchy around the edges. Slow to start. Sure it's 'extensible', but the extensions have thus far for me been extremely ill-fitting and low quality. It reminds me of the 'plugin' fad of the late 90s/early 2000s when a lot of applications pretended to be incredibly extensible but really it was just providing clunky entry points to pretty much standalone apps.
For mattermost, it was basically loading the web gui in an app.... no value over the 'normal' web gui. For atom at least you have the excuse you are dealing with offline material so a 'normal' browser hosted approach doesn't fit, but in mattermost you are connecting to a server anyway. I might have found other reasons to be dissatisfied, but the complete lack of benefit over the browser version just made my interest evaporate.
I don't understand the fascination with using the web development trappings when you don't have to. It's one of the most tedious approaches to application development.
XML is like violence. If it doesn't solve the problem, use more.
Seriously. 'Framework' part is just a wrapper around a whole, full fledged Chrome browser. And there's your problem. If you have Atom, Slack and any other Electron app, along with your 'regular' Chrome, you have *four* copies of Chrome on your computer. If you think that is silly, yes. It is.
Which is why it's crazy to run any Electron app that is available on the web. Run Slack in Chrome, pin the tab, enable notifications and that's it. Identical, and one less Chrome installation.
[thing] which uses a LOT of [constrained resource] works just fine on my [device] which has [unusually large amount of constrained resource], maybe your [device] is too old? - Said every fucking developer ever.
Followed by; "What do you mean lag makes the game unplayable? It works just FINE on my LAN, asshole!".
"...as a new company without a lot of resources, this setup has just barely allowed us to enter the marketplace."
OK, so you've solved your problem as a startup. And you did acknowledge the user, barely.
"But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel."
And then you let us know what your priorities are. The users can pound sand, you're a Startup dammit! And you have Needs! All your users need to upgrade to High End Equipment for the privilege of using your indispensable App!!
You might want to rethink your priorities, before your precious startup collapses due to market disinterest in your bloated POS. Maybe Facebook can get away with that attitude, and maybe Twitter. You cannot.