This is Electron scapegoating. The real issue is twofold: 1. Electron makes it trivial for developers who don't regularly reason about native performance to re

This is Electron scapegoating. The real issue is twofold: 1. Electron makes it trivial for developers who don't regularly reason about native performance to release desktop apps. The result: a flood of apps that "don't do much" but use more resources than you'd expect. 2. At the other end, Electron makes complex apps easier to build. The Slack app might be low-to-medium complexity, but the Spotify app has a ton of functionality, and I bet dev effort was orders of magnitude lower than for a native app like iTunes. The result: in this day and age, complex cross platform apps with higher resource requirements are more likely to be built with Electron. In short, there's some selection bias going on in both cases, and it isn't directly related to Electron. Electron is just the enabler. I agree with the author on point 1: performance matters, memory usage matters, and we as web developers should broaden our horizons and learn lower-level languages. I feel that way regardless of Electron though. On point 2: I spent the last year building a cross platform continuous sync app (basically, a Dropbox V1) in Electron [0]. We were a team of 2. I also write C and C++ for a living, and I simply can't imagine building the same thing in a lower level language in the same timeframe. It's not just a UI concern either: writing a sync engine in node (the backend half of any Electron app) worked out amazingly well. Node is a great I/O orchestrator. The app runs at < 1% cpu when not actively syncing, 40MB backend process, 70MB frontend process. Reasonable for what it does. Dropbox uses more than double that although, granted, it's also not native code. [0] https://blend.io/download https://blend.io/download