undefined | Better HN

0 points__jonas1y ago0 comments

>From my understanding the main difference between electron and other WebView Containers (besides built-in APIs) is that electron runs your nodejs code in the same process as your browser code.

That is not correct: https://www.electronjs.org/docs/latest/tutorial/process-mode...

> So there is no cross-process communication, true synchronous communication between browser and nodejs code, ability to communicate without copying memory and without serialization, etc

From the Electrton docs:

> Arguments will be serialized with the Structured Clone Algorithm, just like window.postMessage, so prototype chains will not be included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will throw an exception.

(https://www.electronjs.org/docs/latest/api/ipc-renderer#ipcr...)

But yes they do build pretty heavily on Chromium, so swapping it out for a system WebView would probably not be possible.

0 comments

killcoder1y ago

Within a renderer you can access NodeJS APIs directly. The main process shouldn’t be used for any significant computation, as it will block GPU paints and cross-process synchronisation.

The other main difference is Electron bundles a known set of APIs, given the known Chromium version. There’s such a huge variance of supported features across the embedded web views.

cyanydeez1y ago

Yes, this is the best benefit of elecrron: you dont have to trouble shoot 10s of OS webview versions and their ixremental suppory, especially with MacOS.

But it is right that the ui for elwctron has to use a IPC layer to get a node backend running. However, chrome is moving a lot of things like FilesystemAPI into browsers so there may be a day were nodejs is dropped in favor of a sandboxed chromium.

killcoder1y ago

You don’t need IPC, you can either use a preload script to expose particular Node APIs in a secure manner or set ‘nodeIntegration‘ to ‘true’ to expose everything.

Source: https://www.electronjs.org/docs/latest/api/structures/web-pr...

DanielHB1y ago

oh wow, I was very wrong, I don't know why I got this notion that electron shared the runtime environment between non-browser and browser code. Thanks for the clarification.

I am pretty disappointed about this, it severely limits the usability of native code from inside the UI code and makes Electron much less attractive compared to Tauri, Wails or similar alternatives.

Do you know if at least moving objects between the electron processes uses direct memory-copying and not some heavy-handed serialization (Wails for example serializes to JSON). The links you pointed out don't mention that.

killcoder1y ago

You were correct. Electron lets you expose specific NodeJS APIs via the preload script or everything via the ‘nodeIntegration’ setting:

https://www.electronjs.org/docs/latest/api/structures/web-pr...

Separately the IPC lets you do zero copy in some circumstances via Transferable objects such as ArrayBuffers. Structured cloning is efficient but not zero copy, and json serialisation shouldn’t be used (since structured cloning is easily available).

__jonasOP1y ago

Thanks for adding this context! Guess I was mislead by the Electron documentation talking about multiple processes and IPC, appreciate the clarification!

j / k navigate · click thread line to collapse

0 points__jonas1y ago0 comments

>From my understanding the main difference between electron and other WebView Containers (besides built-in APIs) is that electron runs your nodejs code in the same process as your browser code.

That is not correct: https://www.electronjs.org/docs/latest/tutorial/process-mode...

> So there is no cross-process communication, true synchronous communication between browser and nodejs code, ability to communicate without copying memory and without serialization, etc

From the Electrton docs:

(https://www.electronjs.org/docs/latest/api/ipc-renderer#ipcr...)

But yes they do build pretty heavily on Chromium, so swapping it out for a system WebView would probably not be possible.

0 comments

killcoder1y ago

Within a renderer you can access NodeJS APIs directly. The main process shouldn’t be used for any significant computation, as it will block GPU paints and cross-process synchronisation.

The other main difference is Electron bundles a known set of APIs, given the known Chromium version. There’s such a huge variance of supported features across the embedded web views.

cyanydeez1y ago

Yes, this is the best benefit of elecrron: you dont have to trouble shoot 10s of OS webview versions and their ixremental suppory, especially with MacOS.

killcoder1y ago

You don’t need IPC, you can either use a preload script to expose particular Node APIs in a secure manner or set ‘nodeIntegration‘ to ‘true’ to expose everything.

Source: https://www.electronjs.org/docs/latest/api/structures/web-pr...

DanielHB1y ago

oh wow, I was very wrong, I don't know why I got this notion that electron shared the runtime environment between non-browser and browser code. Thanks for the clarification.

I am pretty disappointed about this, it severely limits the usability of native code from inside the UI code and makes Electron much less attractive compared to Tauri, Wails or similar alternatives.

killcoder1y ago

You were correct. Electron lets you expose specific NodeJS APIs via the preload script or everything via the ‘nodeIntegration’ setting:

https://www.electronjs.org/docs/latest/api/structures/web-pr...

__jonasOP1y ago

Thanks for adding this context! Guess I was mislead by the Electron documentation talking about multiple processes and IPC, appreciate the clarification!

j / k navigate · click thread line to collapse