Why Electron?

Posted by on in

It’s cool these days to disparage Electron apps as bloated monstrosities produced by developers that have a limited understanding of native software (and it shows). And that complaint isn’t entirely without merit:

  1. A complete and independent copy of the the Chromium browser is bundled into every Electron app so you’re looking at a roughly 32 MB memory footprint and 128 MB install just as a baseline. This makes Electron unsuitable for (or at least inefficient for) command-line utilities, ultra-lightweight GUIs or for frequently-launched but short-running applications (that are mean to start and finish quickly).

  2. The Electron architecture, by design, makes it easier for developers with little or no experience outside of the client-side web stack to build and distribute desktop applications.

But the fact is Electron is a pretty powerful tool for cross-platform desktop application development:

  1. Say what you will about Chromium, it is a battle-tested platform. Between Chrome and a handful of extremely popular Electron-based apps like Atom, VS Code and Slack—not to mention dozens of other Chromium-based applications, Electron or otherwise—Chromium apps are used all day every day (often more than one at a time) by millions of users on diverse platforms. Chromium represents a ridiculous level of investment in engineering and testing, much of it focused on performance, security and cross-platform compatibility.

  2. Despite the lingering notion that web-development is somehow “less-than” real software engineering, we’re a solid 15 or 20 years into the era of Web 2.0 and single-page applications. While cheesy “webmaster” jobs building static sites and simple request/response transactional forms still exist, modern web development is often full-stack development of robust, responsive and richly-interactive user-interfaces. And a sophisticated collection of methods and tools have been created to support that. It’s foolish to think there’s nothing of value in that ecosystem.

  3. When used appropriately, the web stack not only supports but encourages an architecture that clearly separates data (HTML/JSON/XML), presentation (CSS) and logic (JS). Independent of the framework, platform or technology stack, that’s a pretty good way to organize any user-facing application.

  4. Like it or not, the basic web paradigm—a hyperlinked collection of rich-text and multimedia content—addresses the scope of a large number of applications. A browser-style UX is a reasonable foundation for those sorts of applications. (Although, to be fair, text-editors, IDEs and chat apps may not be among them. An intelligent tablature viewer might not either.) Moreover, while native OS look-and-feel is an important and not trivial topic, people spend a lot of time in their web browser and are very comfortable with web-like UIs.

  5. Electron development is refreshingly different than web development. One of the most frustrating (and expensive) aspects of developing for the web is worrying about cross-platform and cross-browser compatibility. It can take years for cool new features to become broadly available in the wild while we wait for browsers to implement the feature and for users to upgrade to the latest browser. And even when a feature is technically supported by all the major browsers there’s often minor variations in behavior between different browsers, platforms and versions. And then there’s user-specific customizations, preferences and things like extensions and add-ons to consider. Consumer-facing web developers have very little control over the context in which their code is executed and as a result they have to do a lot of testing to make sure the feature works as expected on each platform, and waste a lot of energy on complicated shims and feature-detection logic to work-around the differences between browsers and platforms. But when building an Electron app you are building for one browser, a modern browser for which you have much more control over the version, plug-ins and configuration. When you have access to the latest web technologies and can ignore most (but not quite all) cross-browser compatibility and consistency issues, it’s a different world than the web development you may be thinking of.

  6. It’s not exactly non-native anyway. Chromium itself is a native C/C++ application. Your JavaScript code is interpreted of course, but you can always extend Electron with native modules, or really anything that be compiled into to a C-style so/dll interface. (The PSPDFKit team shared a nice introduction to this topic in their blog.)

That’s why at FATpick we use the Electron platform to build both our Windows and MacOS desktop applications. We’re not wedded to the idea—it’s a tactical rather than strategic decision—but it’s one that has worked well for us so far, and one that brings some distinct advantages for our specific team, domain and product. We’ll say more about that in a future post…

From Liner Notes, the FATpick blog

Also see more posts by or in .

Copyright © 2018 - 2020 FATpick LLC.