[laumars]

I do get that point of view but there are as many exceptions to that rule as there are examples.

Take mobile app development: half the products that run on Electron on the desktop will still have native apps on mobiles. And even those that don’t would still have to use the native renderer on iOS and Windows Phone thus you’d be testing your common code base across multiple rendering engines anyway (which was the argument against the tool in this discussion).... and I’ve not even meantioned the slew of cross-platform applications that exist which have successfully avoided using Electron.

There are quite a few cross platform frameworks out there these days and different languages that can leverage them, however the next point I think is the real crux of the problem:

I will grant you that Electron does lower the barrier for entry (which is ironic because I personally find the web stack more awkward to develop in than native widgets - but each to their own). And maybe that’s where the biggest cost saving comes for the business; you can hire cheaper engineers to build and support your desktop software?

In any case, I’m not blind to the appeal of Electron; I just don’t agree with how important it is in the same way as the GP does.

[Klonoar]

Eh, no - nowadays most Electron-based apps would opt for a React Native app on iOS, so they can reuse most of the JS logic from their web counterparts. The big players (Slack, Spotify, etc) will introduce native things because it makes sense to, but there's no reason the small players will do this.

Multiple rendering engines in this case also makes sense because the form factor you're designing for is inherently different. As a result, the usability factor comes into play... you're never writing one UI at that point anyway. The point of Electron is that you turn building and testing 3 rendering engines into testing 1.