Things people get wrong about Electron - Felix Rieseberg

Electron's choices, especially the very idea of building interfaces with web tech and shipping large parts of Chromium to render them, are not uncontroversial. Reasonable people wonder why we made those choices. Operating systems already have user interface libraries. In those libraries is usually also some kind of WebView, often actually based on Blink (Windows) or WebKit (macOS, many Linux distributions). … ## Electron pits JavaScript versus native code The argument: JavaScript isn't the right choice for everything. Native is better. Electron is not native. This misconception is likely the fault of Electron's maintainer team and especially me. Most of the talks I've given in the earlier days of Electron highlighted its ability to interact with the operating system from JavaScript. … All `UIWebViews` run in a single process, which ends up using less CPU and Memory when directly compared with Electron. However, when running the actual Slack web app, users would report slow performance. Whatever the user wanted to do, it'd be faster in Chrome. Eventually, Apple moved towards a multi-process architecture with shared utility processes as popularized by Chrome et all with `WKWebView`. This "catch up" game remains – the very best web app rendering engines and runtimes can be found in our best browsers. Operating system WebViews will eventually catch up — but I have yet to see them ahead. … But: You might be surprised to hear that performance is not the primary reason why many Electron developers prefer a bundled engine. The primary reason is allowing developers to control the stability, security, and reliability of their applications independently from a WebView that's tightly coupled with the operating system and therefore out of their control.