[monocasa]

In this context, it means that it uses the UI toolkit provided by the OS/display env to do it's UI rather than opening a custom rendered surface and doing it all manually in your app (as a browser engine does). That includes using the browser engine on the system.

There's a weird impedance mismatch in the UIs of any non native apps that comes simply from recreating the UI elements and not using the system provided ones. This isn't an aspect of trying to 'feel superior' to JS devs, but a reflection of the real trade-offs of the technique. And I say this as the lead from a traditionally systems oriented team that's about to ship our first electron app. We took a look at the costs, and decided that in this particular case the tradeoffs were worth it, but it's not an easy decision.

And one thing I'll say is that a piece of what makes electron attractive at the organizational level is the fact that it doesn't use the system libraries. That greatly reduces QA burden by not having a spread of different versions of underlying infra to deal with. As an enduser I'd love if all the chrome/blink based apps on my machine (let's see, chrome, spotify, vscode, slack are all running) shared resources, but if they had to test against different versions of runtime or each version of their code they released, they probably wouldn't be using this model in the first place.