A word on Electron.

ElectronJS, also referred to as just Electron, is a really good idea.

Someone, at some point, thought to themselves, “Hey, web developers build websites all the time with HTML, CSS, and JavaScript. Why can’t we just render the same web pages people use as desktop applications?” Which is a brilliant idea. Put into practice though, I’m not sure that Electron should be your first choice when developing a Desktop application.

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.

The cluttered working environment. What’s Yarn? A year ago I would have told you it’s for knitting. Now? It’s a dependency manager for JavaScript. How do you get it? Through NPM. What’s NPM? A dependency manager for JavaScript. The first thing you do when you want to work on a project using React.js or Electron is “npm install” through the command line. Then, you wait as NPM installs the entire internet onto your local project. It gets ridiculous after a while when you have a couple projects on your hard drive all with their own “node_modules” folder that takes AGES to transfer all the tiny little files in it. Committing in git takes forever.

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.

Electron produces some great looking results, however. Since anyone can use the power of CSS and JavaScript, applications can look very fancy and feel nice. Listed on Electron’s showcase page are a few applications that you might not have thought were built with this, including Discord, Skype, and Slack, and I can’t say I hate all Electron apps because I use Visual Studio Code almost religiously in my work and I love it.

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 Patreon | My Website

Treat finishing like a skill.

When working as a game developer, I’ve noticed something that sticks out at me quite often, and that’s actually finishing a project. Whatever you’re trying to build, if you’re a creative person, guaranteed you have a stack of unfinished projects or grand ideas that you’re too lazy to finish. Or maybe you just don’t have time. Either way, finishing something, especially a game, is hard. I heard this a long time ago, but it was “treat finishing like a skill”, not just a verb. It’s great advice. Grinding through to the very end of any project is hard, hard work. Sometimes, it’s just not fun. And that’s okay! A lot of creative projects are work sometimes, which is why it’s hilarious to me whenever anyone puts playing video games and making video games even close to the same realm. Yeah, because sitting here trying to convert a Quaternion (which is a mathematical formula representing something in 3d space), to Euler angles is the same thing as scoring a goal in Rocket League. Speaking of Quaternions, there’s a cool simulation here that gives you an idea of what they look like.

Recently, I saw a reddit post on /r/gamedev where someone asked when they know they’re done with their game. The short answer? You don’t. You’ll never be done. There’s always stuff to tweak, and there’s always more to add. But here’s the thing: You need to give up. Yeah, weird, huh? You need to know when to quit. It’s very important. A little ironic, considering many people tell you never to give up, but it’s actually also a very important skill. Listen, if we all had unlimited time to make video games, guess what they would all be? CoD mixed with Overwatch mixed with World of Warcraft mixed with… you get the idea. Because we have a shortage of time, we’re forced to make cuts. You have to decide what really fits in the game and what doesn’t. It makes you create a concise experience that ultimately would be better than a meandering mess of a game with no real theme anyway. You just have to get things finished enough and then quit. Release and move on to the next project. You can always go back and update it if you have a great addition or the like, but you do need to be done with it so you can work on other creative endeavors at some point.

So, how about it? Got a project lying around that you’re thinking about taking a crack at again? Why not give it a shot and work towards finishing it?


My Patreon | My Website

How I learned about Google Play App Signing Keys.

Recently, I received an email from Google Play services. “Your app has been removed from the Google Play Store for a policy violation”, or something like that. How odd, I thought. I don’t remember doing anything against their terms of service. The email revealed that I didn’t have a valid privacy policy inside the app or on the store listing.

Oh. Right.The GDPR fiasco. It was time to write some privacy policies. After doing so, I began the process of digging up old files to old apps to make the necessary changes to the code. After about 2 hours of reinstalling Android Studio (my hard drive was wiped as some readers may remember), I began the arduous process of exporting the app from Unity to an .APK.

Eventually, I was able to upload the finished .APK to Google’s servers. However, the Play Console threw an error at me; “The signatures do not match”. Wait, what? It’d been too long since I’d actually done this process. I googled the error and broke out into a cold sweat.

Apparently, you generate a .keystore file upon first creating an Android app to sign the application with. It prevents people from uploading versions that aren’t from you I guess? In the unlikely event that a developer’s account got hacked, or something. There was no way to recover said .keystore file if you didn’t have it anymore, meaning there was no way to update my app. Ever. A full, in-depth system scan revealed no .keystore files. Luckily, with the two brain cells that were still functioning, I managed to remember that the other day I had deleted the app-which-I-was-updating’s Android version off my hard drive, because there was no real difference between the iOS and Android version, and I thought it was redundant. Perhaps it was in there?

I checked my Recycle Bin and breathed a sigh of relief. I hadn’t emptied it. It was still there. Opening the folder, the first thing I saw was a “user.keystore” file at the very bottom of the file list. A quick test later confirmed that was the one. Phew.

Apparently those things are important. Don’t lose ’em, kids.


HEY, LISTEN! It’d be really cool if you checked out the app here on the play store, since it just got updated. 😉


My Patreon | My Website