ElectronJS, also referred to as just Electron, is a really good idea.
The implementation of it is what I have problems with. Now, there are a lot of better and smarter coders than me out there, but I feel as if I bring up some valid complaints. Here they are, in no particular order.
The size. A C# or C++ “Hello World” application (click for definition) is under a megabyte, and if memory serves, the C# one is less than 10KB. An Electron app published for the Mac is 115 MB in its “Hello World” application. That’s insane. RuneTale *wink wink nudge nudge* is 36 MB. A full-on videogame is more than 3 times smaller than a basic program to display a string. This makes making small programs like the Searchifier, for instance, a no-go. If every program on your disk took up 115MB+, you wouldn’t be able to have very many applications. Plus, every time an Electron app starts up, it has to load its libraries into the RAM, which also weigh a ton. If you had a few Electron apps open, you could waste gigabytes of volatile memory.
The redundancy. Speaking of having to load all those libraries into RAM, let’s talk about that. Every single electron app comes with Node.js and Chromium. This is what is making the app so big in the first place. As stated above, bundling a complete browser rendering engine that has almost the same number of lines of code as the Windows OS doesn’t make for efficiency. This slows down newer and older computers alike. On terrible machines (Like this piece of garbage I had the displeasure of owning for a couple of years), running even ONE Electron app with a web browser like Firefox or even Edge slows the computer to a crawl, and literally increases loading times to above 20 seconds per click. Those were hard days.
If I can add on to the other paragraph before you grind your teeth into dust, the fact that everything breaks at the slightest touch is a good one and goes hand in hand with the cluttered working environment. Every time you install the packages a project needs, you have to use the same version of those packages because one little change can break the whole thing. There are a couple of ways to denote what version you want, and it’s mostly taken care of for you. If you lock down your dependencies and specify that you only want specific versions of them, the dependencies themselves may not do the same. For example:
- You want version 0.9.3 of dependency “a”.
- “a” depends on package “b”, but allows versions 1.3.1 – 1.9.9, denoted by ^ (^1.3.1).
- Package “b” depends on any path version of 3.4.1, denoted by ~ (~3.4.1) of packages “c” and “d”, both of which depend on any minor version of “e”, which is currently on 1.4.1.
So even if you lock down your dependency versions, package variations can exist across identical installs of the same project. This can lead to small bugs popping up out of seemingly nowhere as bugs are introduced in packages you don’t have any control over. What’s the fix? Often, it’s “turn it off and back on”, by way of
rm -rf node_modules && npm cache clean && npm install
What does this do? In plain English, “Remove the node_modules folder, clean the cache, and reinstall”.
Luckily, at some point someone realized this was an issue and dependency locking was added in Node 5.x+, but a mountain made up of tiny obstacles is still a mountain.
Can’t help but wonder how much smaller and better performing Visual Studio Code would be as a native desktop application written in C++ though.
| My Website