[a85]

It's not just an embedded instance of Chromium. There are APIs that bridge the gap with the operating system. One way to look at this is that the UI layer runs on HTML/CSS/Javascript. VS Code, Slack etc. are other common examples.

[Electron APIs]: https://electron.atom.io/docs/api/

[paulddraper]

Right. It's Chromium + JS APIs + some packaging.

E.g. an API to write a file.

[JSDave]

Electron gives you a view process, background process, and a way for the 2 to communicate.

The view process is very limited, just standard web APIs.

The background process is basically a node process and can do anything you can in node.

[derefr]

Including, importantly, the ability to fork+exec other native processes. You can ship an Electron client app that spawns and then interacts with a native C background service, if you like. (I believe that's how Keybase's native client works, in fact.)

[yblu]

> The view process is very limited, just standard web APIs.

Nitpicking here, but the view (rendering) process in Electron can actually use the Node API [1]. The difference in API access privilege between the two types of process is in what Electron API (not Node API) they can use. For example, main process can use native GUI API but renderers can't and must IPC to main if they need to, say, show a system dialog.

[1] https://github.com/electron/electron/blob/master/docs/glossa...

[Rapzid]

That's a bit too simplistic of an explanation IMHO. It's a mashup of chromium and nodejs; the entry point is a nodejs app.

[pininja]

Window, Menus, clipboard, etc.. (not just being able to write to a file) https://electron.atom.io/docs/api/

[pier25]

All OS related functionality is through Node.