Electron does what you won’t

I’m tired of listening to subhumans redditors complaining about electron and bloat, and not because I’m a bloat, electron, or web stack lover. I do think it’s ridiculous that every chat app, game, and even text editor ships with a full copy of google chrome and node.js to do its relatively trivial task. However, it is not enough to post angry comments in your degenerate SoCal subreddit ; you need to understand why people flock to electron (and web technologies more broadly) instead of your favourite GUI framework. By understanding the problem you can begin offering solutions instead of merely whining for upcummies. Desktop programmers are so spiteful that their holy cows are getting slaughtered that they are simply refusing to provide solutions.

There are real reasons why web technologies are so popular, and it isn’t because the people involved are too young, too stupid, and too plebeian to learn a real intellectual language like C, Rust, and Haskell. Rest assured there are plenty of young, dumb, and basic bitch programmers in those ecosystems as well ; for example, look at yourself in the mirror.

The web distribution model

There is literally no simpler way to distribute software than providing a link, having it load and run immediately. Even the simplest distribution formats, like AppImage, aren’t that simple. If I write software for a browser, I can put it in a static file host somewhere and have everyone I know run it. Compare this with getting anything else to run on a desktop or mobile device. You need only look at the insanely complicated tooling game developers use to distribute their video games. If I make a game for a web browser, whatever the performance problems, the user doesn’t have to care what libraries or tooling I used in making it. Note how non-web developers have started fancying that also. Several libraries and tools I use daily distribute their software by piping the results of curl to bash. It has its problems, but it is simpler to do, and simpler is better than full-featured or secure in the real world.

Even something as simple as installing a new version is miserable on the desktop. On the web, I simply tell the user to reload the page, maybe also clear the cache.

The web backwards compatibility

With the exception of having mixed encrypted and unencrypted content in a page, code I wrote for the web 20 years ago will still run today just fine. Even for the stablest of libraries, even for the C standard library, I will at bare minimum need to recompile everything. If you don’t believe me, try running Linux code written 20 years ago in a modern system. It’s absolutely miserable and requires tons of manual work that a normal user can’t and shouldn’t be expected to do. Making all software open-source so that it can be recompiled more easily isn’t going to happen any time soon. The easiest solution here involves AppImages, which bundle the binary and all of its assets and libraries together, kind of how electron works. It really activates your almonds.

More importantly, the techniques and APIs I learned 20 years ago are still valid today in the web platform. Yes, there are new APIs and data structures, but I don’t have to use them or learn about them if I don’t want to, incorporating them into my project as needed. Meanwhile, all major desktop operating systems have completely changed how their widget libraries or even display protocols work several times over the past 20 years. The only thing that has remained stable is maybe the choice of programming language and the basic command line plumbing.

Notice how many people create their applications as TUIs in the terminal. Have you ever wondered why ? Whatever its problems, I have to learn a virtual terminal’s escape sequences and/or ncurses once. Keeping up with with GTK, Qt, Win32, Metro and all the other shit is fucking miserable, and whenever they update, I have to change my application’s internal plumbing to keep up with their vision, recompile and redistribute. A virtual terminal can be xterm on X11 or cmd on Win32, which are vastly different in implementation, but it communicates with the same protocols, so the surrounding system is irrelevant to me.

The web platform compatibility

If I write code that works in a web browser, I can be mostly certain that it’ll run in any web browser. Yes, there are exceptions, but the vast majority of features are shared, regardless of the browser vendor or target platform. Firefox on OpenBSD and Safari on the latest iOS have so many commonalities that I have to make an active effort to stumble upon incompatibilities. I don’t even need to tell you how wacky compatibility is outside that very limited domain. There are entire pages dedicated to explaining how to cross-compile software on Linux so that it can work on Windows without having to maintain two separate build and dev environments, and they are not exactly light reading. Meanwhile, I can write a JavaScript bundle script that runs only in Haiku, and my users won’t notice any difference.

The only weakness the web model has is that it has limited ability to interact with the file systems or with network sockets due to security concerns. These are the problems electron solves, and that Firefox OS tried to solve. Rest assured efforts are ongoing to remove even that problem.

The web platform popularity

As a developer, I want my software to be accessible to as many people as possible. Since literally everyone has a web browser, there is no platform larger than the web platform. This popularity also means that all the problems I encounter have likely been already solved or at least encountered by other people, so I can easily look up existing discussions online. Additionally, the documentation is a lot better, not only because of the popularity, but also because it doesn’t change top-to-bottom every 6 months because a GNOME developer began mainlining oestrogen and reconsidered his design aesthetic. Compare this to finding literally anything about GTK, X11, or, god forbid, Wayland. The documentation is horrid if it is even present, and sometimes you have to look at the function’s implementation in source code to understand what arguments it needs and what it returns.

The web programming language

JavaScript is a nice, highly extensible, garbage collected language with a very fast JIT compiler that allows you to use whatever abstractions you want with few performance hits. Because it is the only language the browser allows, it is also the one, only, and obvious default for any programmer who wants to get into it. It is what documentation is written for. It’s what libraries are written in. To the extent you write in something else, you compile to JavaScript, and since it’s all JavaScript, it is all mutually compatible. I can have code that originated in F# and Python working together in the exact same scope.

Outside the web, it is a free-for-all, and nothing is compatible. Libraries are mostly written in C, which is the fast-track path to growing a heroin addiction to cope with the stress. The only way to remain sane is to use a batteries-included language and stay strictly within its standard library, like Python, but the moment you step outside it, you have to learn how bindings work, where to find them, and how to make them work cross-platform.

The web simplicity

If you have an idea for an application, the time to first blit to canvas is 10 lines. There is no equivalent in other platforms, unless you count writing to the framebuffer raw in Linux. You have to learn about the display stack of your OS and possibly other OSes, and I can’t emphasise enough that I don’t fucking care about your display stack. How Windows or Linux or macOS display graphics and handle windows ought to be completely opaque to me as an application developer, because in the end I just want a fucking surface to blip my JPEGs onto. This is the abstraction that the web browser provides, out of the box, in a language that isn’t C, with minimal effort on my part.

I understand that things like SDL exist in C land, but think about it from the perspective of a new programmer. Which is easier : teaching them how to get SDL and the correct bindings for their programming language of choice, or just firing up a web browser that they already have on their computer and learning how to write code for it ?

My first programming language was a C dialect, and my second was Python. The things that took me months to learn in Python were possible in 3 hours in JavaScript. For a new programmer, the web is a perfectly acceptable platform for almost everything they choose to do, with very rare exceptions like AAA games development, which, spoiler alert, won’t remain exceptions for long.

The web security model

Not to say that web browsers don’t have bugs, but when they do have bugs, it is less likely that they’ll nuke your entire operating system. A regular desktop application has all the rights my current user has, and since most computers are single user computers, that means they have basically infinite power. Security on the web is much tighter and more granular. Whenever you load any web page with JavaScript, you basically download, compile, and run the author’s software, and there is a reasonable (and mostly correct) expectation that this will complete securely without installing a cryptominer that runs as root on startup, a keylogger, or kernel module.

What to do

It’s obvious that web technologies have blindsided desktop developers, and their dysfunctional way of coping is lashing out on Reddit, 4chan, and rewriting everything in Rust. This attitude has no future and will result in more and more applications getting ported to web technologies, with traditional applications dying out. If this is a future you dislike, here’s what you can do to help.

Standardise protocols. Every operating system, even mobile ones, have some basic user interface needs, like blitting bitmaps on a region or having buttons. Do you honestly believe creating a button in GTK versus Win32 is so vastly different that you can’t standardise it ? Each platform and widget library can have its own implementation of the protocol, with perhaps some private extensions that can be gradually standardised. We know this is possible, because that’s how web browsers did it, and how it is done in Wayland.

Simplify package management. The current mess of C libraries with random bindings for every language is hell, and you know it’s hell. A library should expose some interfaces that don’t relate to what language it’s written in. Each language provides a way to access this interface. This is work, but it is work that is only done once per language, and then it is done forever.

Unify compilation. Languages are statically compiled, interpreted, or JIT compiled, and they are garbage collected or manually managed. There is no reason for each language to implement its own private garbage collector, build, and compiler toolchain. There can be a few standard garbage collectors that plug into any language that wants to be garbage collected. This can even be provided as a service by the system.

Simplify distribution. HTTP is now the de facto standard for transferring files, and you can use it to distribute, run, and update applications. Each distro and programming language having its own package manager is retarded, to say nothing of Windows programs each coming with its own private update service.

Standardise bytecode. Software should be distributed as platform-agnostic intermediate-level bytecode, which will then be compiled for the target platform upon installation using a service provided by the system. This is already how LLVM works.

Standardise granular security. All-or-nothing security is dumb and has always been dumb.

Stop using C by default. C is cancer and user-hostile. Use literally anything else. Give Standard ML a try.

Will this be done ? It’s highly unlikely. Desktop developers are content screaming at clouds and circling around existing dysfunctions rather than addressing them. Meanwhile, the web ecosystem is ever expanding, with things like WebAssembly being able to run outside a web browser context now. With more and more applications being ported to run on the web, it won’t be long before someone decides to write an entire desktop and window manager on the web as well. This will provide real benefits, as it can be run remotely through a thin client. We will be stuck with the bloat of inefficiency of the web, which will gradually improve, though not radically, but at least we’ll have standard protocols for all our applications and a unified ecosystem for all humans, not just redditors and X.org conference attendees.

Simply put, desktop developers refuse to collaborate and fix issues, while browser vendors and web interest groups actually put in the effort required to make their ecosystem flourish. In the end, you reap what you sow. Stay salty, stay mad, and kill yourselves.