Long ago and far away, we had these things called “shared libraries” which allowed one to build code and reuse it, so that even if the build process was very long and complex, you only had to do it once. An elegant solution from a more civilized time.

If we assume that it’s a good idea to use chromium, very little of this is actually electron’s fault. I’ve had the pleasure of working with google’s build tools at work; everything from weird assumptions to gigantic downloads to weird build tools to including its own little Debian Wheezy is all on Google. (As a bonus, they start all their python scripts with #!/usr/bin/env python, but their scripts are entirely python 3 incomparable, so I have a short script to just toggle whether /usr/bin/python is a symlink to python 3 or python 2.)

Our C programmer tried to get a VM set up with Electron on OpenBSD so we could do testing. It was a massive time suck and never did get it working. It cost us a lot and the whole situation was very unfortunate.

At the moment, Electron is the easiest way to get a web browser app and packager. If there were something better, we’d try to use it.

It’s mostly chromium that’s the problem - for which you can blame Google. “everyone is on a 100Gbit connection to Google’s internal network, so who cares if we repeatedly download 500Mb build artifacts!” appears to be the thinking.

Makefiles are great for small Unix projects, not so much for something that needs to be built for Windows too… Windows developers live in a parallel universe of build tools and that coupled with the shear size of chromium helps to explain why they felt it necessary to make ninja.