the case for electron.js

This is a document I wrote for myself when I was looking for a software development platform to replace Delphi for implementing large business applications. I was interested in Electron because it offered the possibility of yet another area of development where TypeScript could be used. I like the idea that a single language (TypeScript) could be used as a standard in developing business applications for all the major places where code can run: web servers (node.js), web browsers, mobile apps (react native), and now desktop apps (with electron).

intro

Electron is a way to make cross platform desktop applications that are built with a single code base. This is done by making desktop apps entirely out of JavaScript (TypeScript) and having them execute in special Chromium browser windows without any visible browser controls (i.e no tabs, no location edit, no back and forward buttons, etc.). The key part of Electron is that those special Chromium windows interpret an extended JavaScript language that can access parts of the system unavailable to normal Chromium browser windows (like the file system). This allows general purpose desktop applications to be built. I’ve laid out some pluses and minuses for using Electron to create real world business applications. (All of the minuses are followed by a blurb where I talk myself out of them actually being minuses.)

pluses

• one code base written in JavaScript (TypeScript) that runs on Windows, Mac and Linux.
• apps look good and behave the same way on all OSes. (Ex. VSCode, Spotify¹ , MS Teams, Slack)
  (¹Spotify doesn't actually use Electron, but it's based on the same technology.)
• JavaScript (TypeScript) is a powerful (and even fun) language with a huge development community.
• can share expertise and code libraries with front-end web developers as well as back-end developers.
• all tools in the development stack are open source

minuses

• large footprint: every app requires the entire Chromium executable to be deployed with it (50mb for a Hello World app!)
  🙂 however, business apps that do anything useful are going to be large no matter what language / development platform they are written in, so only small apps would suffer from this.
• speed: JavaScript is an interpreted language so it’s slower than compiled native code.
  🙂 however, hardware and network communication have gotten so fast that typical business applications no longer suffer from sluggish interpreted language UIs. (Look at the success of the other interpreted or semi-interpreted environments used in business: Java, .Net, Python)
• sloppy code: JavaScript is notoriously loose with data type declaration and initialization which causes hard to fix bugs--many of which only appear at runtime long after deployment.
  🙂 however, this can be completely eliminated by using TypeScript, which is an extension to JavaScript that enforces strict types and provides error checking at “compile time”--which these days also means “coding time” because IDEs are able to compile and check code on the fly as you write. Actually, I would never create any JavaScript project without using TypeScript. The automatic code documentation, and checking for silly JavaScript errors is indispensable.
• non platform specific UI: apps on all platforms look the same so the user experience will be somewhat awkward to a user used to working with native apps.
  🙂 however, tweaks for each target platform can mitigate much of the awkwardness. (ex. putting Ok/Cancel buttons in the right order, implementing standard keyboard shortcuts for the target platform, and providing a clean look to the UI with any platform specific adjustments.)
• precarious development stack: the technologies needed to develop and deploy an Electron app are made by numerous groups of developers, companies and organizations. It is easier to understand the big picture when one company like Microsoft or Oracle provides most of the development tools and processes. Bugs and security flaws in downstream libraries can cause major problems.
  😐 however, competition drives innovation and it can be good to have other choices for various parts of the development process and not have to rely on one company for everything. Albeit, I don’t have a good answer for the worrisome security aspects of relying on multiple libraries and in turn those libraries relying on other libraries. If anything was going to turn me off of electron / typescript / javascript, it would be this troubling aspect of the node ecosystem. See these articles on the node-ipc package author's deliberate malware addition and the colors package author's deliberate sabotage. | -- updated Apr. 19, 2022
• “wild west” community atmosphere: it’s hard to settle on the “best” JavaScript technology to use for one’s next project because of the vast number of extensions to JavaScript being introduced (and deprecated) so rapidly.
  🙂 however, the amount of innovation in JavaScript during the second decade of the 21st century was probably made possible by all of this frenzy and excitement. Also, it seems like JavaScript interpreters in browsers, node.js, and therefore in Electron are settling down. The ECMAScript standards in 2022 now seem mature enough to be relied upon with confidence.
• no universal solutions: I mean AT ALL. Each and every thing you’ll want to do has lots of different ways to do them. Having lots of different technologies, loads of differing opinions, and having heaps of outdated and deprecated ways of doing things posted on-line makes development in this space particularly vexing.
  😐 All I can say about this is that it does offer a lot of flexibility--but yea, it’s rough.