Weave: part two
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Google Chrome was a web browser released after Google had already launched Gmail, and so doesn't particularly need to read email. But its Chromium backend is still one half of the Electron engine (together with Node), powering many applications today.
The gist of the previously linked Software disenchantment is that most of the architecture assembled to cumulatively support the sum of 30 years of web pages, including an Xbox 360 controller driver, is present and available and accounted for in the low-effort approach to desktop application development.
When Chrome runs several processes, it's for reasons of privacy, security, stability and decoupling; the sum of complex architectural deduction weighing in backwards compatibility and power consumption. For better or for worse, this is what a browser is forced to do to browse the web these days. When Electron does the same, it's because Chromium was cribbed and duct-taped together with Node, in a feat that is truly technologically impressive, similar to how a chicken with its head cut off still running around is zoologically impressive.
I'm getting mean, but the point isn't to piss on the arduous and precise work necessary to make Electron work, done by people who want to make it easier to make desktop applications. The point is that what you end up with is gross, from top to bottom.
Here's Ryan Dahl, creator of Node.js, explaining the things he got wrong, and who subsequently started the just-released Deno which takes a different approach.
Chromium isn't itself bad, but see above. Swatting flies by poking them with nuclear warheads gets even more dangerous once you realize that you're asking the same hand that would have held the fly-swatter to hold the warhead instead.
And the act of putting together desktop applications based on web UI is also bad. Maybe it's fine on ChromeOS, but an application is one point in a landscape. Every possible way that an OS could be of service now depends on being piped through two layers of abstraction, maintained by two different development teams. Not to mention the cognitive load of constantly deciphering new models of interaction. For web sites, that's okay – you're there to read something, and maybe add a reply every now and then, or maybe play a game where the game itself is the interaction mechanism. But anything put through Electron aspires not to be a publication but an application.
It's not impossible to create good UIs in a web setting, but it sure as hell takes effort and time and practice. It takes constant vigilance to keep up to date and well adjusted in the face of every device that can access it, and most of the frameworks that are there to help you add more heft and complexity for the developer.
Many web-based apps deal with tables/grids in one way or another. How many of them have rearrangable columns, resizable columns, sortable columns? In how many of them can you select several rows and use the copy shortcut to copy the text? Type the first few letters to jump the selection to the first row that starts with them? None of these things are there from the beginning. All of them have to be added. It's not that it's impossible to do these things, it's that it takes effort for the developer, it's that it erodes familiarity for users who can't get their work done faster and can't build an intuition about how things work and what things are capable of.
Of course Electron can be a good tool for someone with few resources or without extensive knowledge of desktop APIs. You've gotta start somewhere. But it's become the go-to tool for even large companies to use, under the debatable pretense that it solves more problems than it creates. And by redefining UI and usability to also include experience (which was necessary), we have opened the door to shift the "experience" away from "did this work well for me?" and towards "was this UI high production value enough to impress them?". What gets thrown away? Familiarity, respect for the user's computer and battery life, respect for the user's desire to master a tool so that they can capably get work done.
Polarization is the enemy of reasoning. I'm not the first to rail against Electron or web-based UIs. But the answer isn't always to switch, tomorrow, to the lowest native stack available on all platforms, and code as if you're using your grandfather's Pentium Pro. It's to be aware of what you're doing, to understand what you're buying into and what you're giving up; to respect your users and respect yourself by doing the best job you can for them. Be informed, be deliberate; be proud of the work you do, the bugs you fix, the complexities you manage and master. Be willing to improve.