📚 node [[the problem with electron]]
📕 text contributed by @enki 🔗

The problem with Electron

The problem with Electron is not Javascript.

The problem with Electron

The problem with Electron is not Javascript.

Javascript is just a basically-ordinary scripting language, and isn’t inordinately terrible (or even Perl-levels of terrible). It’s not great, but it’s OK, and that’s good enough for lots of people.

The problem with Electron is that browsers are terrible at literally everything.

Treating the browser as the logical sandboxing tech for javascript & treating DOM manipulation as the logical GUI toolkit for it dooms JS.

Essentially, the issue comes down to the web stack being a poor fit for general-purpose GUI tasks.

I maintain that browsers shouldn’t really be used for anything other than displaying HTML 1.0. No CSS, no javascript. Get rid of them. Browsers aren’t even great at displaying HTML 1.0, and HTML 1.0 isn’t even great at being HTML 1.0, but of all the things browsers do, it’s the only thing that’s marginally acceptable.

Cascading styles are potentially interesting. They might even be useful, if we applied the concept to something that wasn’t embedded markup. CSS is like Make — an ad-hoc implementation of three quarters of a broken Prolog-style constraint solver. Considering the kinds of amazing feats people are able to achieve with CSS, imagine what they could do if a CSS-like system was designed to be usable.

CSS has a high initial learning curve because of a large number of rules that lack consistent patterns & thus must be individually memorized. Every piece of web tech has that problem (and plenty of non-web-tech like C++ and Java), but it’s still something that’s absolutely unnecessary & rightly criticized. It comes out of standards being written by competing implementations trying to screw each other while maintaining maximum compat with what they already wrote.

There is no technical reason why CSS couldn’t have been written in such a way that the time it takes to get to current professional-level competence from zero experience is two hours. (This is a lie. There is exactly one technical reason: embedded markup makes everything difficult. But, CSS could have been made much easier to learn and much easier to use, had it not grown primarily organically.)

I don’t think these criticisms are particularly radical. I get a lot of push- back every time I make them, though. We’ve got a couple different bones of contention here:

  1. how easy is “easy enough”
  2. what is the appropriate domain for this tech

If you’re a professional in some area and you don’t spend much time teaching absolute novices, it’s easy to forget how steep the learning curve is for things. If you’re a professional with one stack and barely touch other stacks, you can mistake incidental complexity for essential complexity.

With regard to the first problem, I maintain that the learning curve could be made nearly flat, on the grounds that Tk’s learning curve is nearly flat compared to CSS and most other GUI toolkits have similarly nearly-flat learning curves for complex style and layout. However, CSS is limited in that it acts on the DOM, and the DOM is awkward and overly complex in ways that other representations of rich text documents aren’t. Thus, if we do not determine that web stacks are inappropriate for general GUI use, we are stuck with compatibility concerns that force every layer in stack to be more difficult to use than it would naturally be.

Of course, if you ditch the web stack, you can certainly still use Javascript. There’s literally no reason you can’t write code in JavaScript that uses Tk or GTK or QT or XCB or AWT or whatever the hell you want as a GUI toolkit. WINGs, even. At this point, you’re writing a desktop application. Why bother with trying to retain compatibility with something gross?

It’s not really a matter of platform-specific vs web — this is a popular false dichotomy. There are a lot of cross-platform GUI toolkits, with neither the learning curve nor the performance overhead of DOM manipulation.

I can understand why someone who made a web service might decide to repackage it as an Electron app as a placeholder for an eventual real native app. I don’t really understand why somebody would write something from scratch that way, other than basically unfounded fear that the learning curve for non-web stacks is as steep as the one for web stacks (something basically not found outside of esolangs).

It’s easier to write a simple GUI app with GTK when you don’t know GTK than it is to write the same thing as a web app when you’re already a pro at writing web apps. This difference in the difficulty curve becomes more extreme the further you get from simple forms (which web tech can do without significantly more trouble than other platforms) and closer to more abstract interactive spaces (which are trivial on most platforms but an exercise in futility on web stacks).

By John Ohno on May 1, 2018.

[Canonical link](https://medium.com/@enkiv2/the-problem-with- electron-162a70c3b29f)

Exported from Medium on September 18, 2020.

Receiving pushes... (requires JavaScript)
Loading context... (requires JavaScript)
📖 stoas (collaborative spaces) for [[the problem with electron]]