4 ms·

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 sa

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. 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. All these capabilities are essential if you do a lot of processing between the two sides. It is also why electron must bundle a browser (and its v8 engine) and can't rely on the OS browser like other solutions do (which might not be v8 or might be the wrong version of v8). From my understanding this is not the case of any other WebView wrappers tech (Tauri, Wails). Which makes them unsuitable for some kinds of applications (invoking a function cross-process is extremely slow). I am not sure how correct I am with these claims as I never did a lot of electron. If you have a deeper insight I am quite curious about the topic.

koito17 2y ago
In the case of Electron, there is a "main process" that is a Node.js process. This process has the capability to spawn "renderer processes", each browser window is a "renderer process". Through ipcMain and ipcRenderer, Node and Chromium have bidirectional comminication. I don't think renderer processes run Node. Per the documentation, [C]ode ran in renderer processes should behave according to web standards ... [T]he renderer has no direct access to require or other Node.js APIs https://www.electronjs.org/docs/latest/tutorial/process-model#the-renderer-process https://www.electronjs.org/docs/latest/tutorial/process-mode...
- notpushkin 2y ago
  > Renderer processes can be spawned with a full Node.js environment for ease of development. Historically, this used to be the default, but this feature was disabled for security reasons. Makes sense.
- killcoder 2y ago
  Renderers can access Node APIs via the ‘node integration’ setting or via a preload script.
  - themoonisachees 2y ago
    Aren't these just IPCs disguised as normal function calls though? IIRC only the main node process does anything node, renderers can call "node functions" that really happen in the main process.
    - killcoder 2y ago
      Not at all, in a renderer the Node and Chromium event loops are bound together, they’re part of the same v8 isolate, no IPC shenanigans. The main process really shouldn’t be used for anything except setup. Since it controls gpu paints amongst other things, blocking on it will cause visible stuttering and a bad user experience. https://www.electronjs.org/blog/electron-internals-node-integration https://www.electronjs.org/blog/electron-internals-node-inte...
baumschubser 2y ago
In a recent podcast, Daniel Thompson from Tauri talks about the perspective of having shared memory between the Webview and the backend in Tauri as well. However, it is pretty vague. See here, search for "Topic 12": https://syntax.fm/show/821/is-tauri-the-electron-killer/transcript https://syntax.fm/show/821/is-tauri-the-electron-killer/tran...
- cyanydeez 2y ago
  You can used shared buffers in chrome so one could use webworkers for a lot of processing. However, we are still waiting for many Apis to be available in webworkers.
  - DanielHB 2y ago
    What you really want is to get a reference to those SharedArrayBuffers in the native code like you can do with WASM
__jonas 2y ago
>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-model 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#ipcrenderersendchannel-args 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.
- killcoder 2y 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.
  - cyanydeez 2y 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.
    - killcoder 2y 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-preferences https://www.electronjs.org/docs/latest/api/structures/web-pr...

koito17 2y ago

In the case of Electron, there is a "main process" that is a Node.js process. This process has the capability to spawn "renderer processes", each browser window is a "renderer process". Through ipcMain and ipcRenderer, Node and Chromium have bidirectional comminication. I don't think renderer processes run Node. Per the documentation, [C]ode ran in renderer processes should behave according to web standards ... [T]he renderer has no direct access to require or other Node.js APIs https://www.electronjs.org/docs/latest/tutorial/process-model#the-renderer-process https://www.electronjs.org/docs/latest/tutorial/process-mode...

notpushkin 2y ago
> Renderer processes can be spawned with a full Node.js environment for ease of development. Historically, this used to be the default, but this feature was disabled for security reasons. Makes sense.
killcoder 2y ago
Renderers can access Node APIs via the ‘node integration’ setting or via a preload script.
- themoonisachees 2y ago
  Aren't these just IPCs disguised as normal function calls though? IIRC only the main node process does anything node, renderers can call "node functions" that really happen in the main process.
  - killcoder 2y ago
    Not at all, in a renderer the Node and Chromium event loops are bound together, they’re part of the same v8 isolate, no IPC shenanigans. The main process really shouldn’t be used for anything except setup. Since it controls gpu paints amongst other things, blocking on it will cause visible stuttering and a bad user experience. https://www.electronjs.org/blog/electron-internals-node-integration https://www.electronjs.org/blog/electron-internals-node-inte...

baumschubser 2y ago

In a recent podcast, Daniel Thompson from Tauri talks about the perspective of having shared memory between the Webview and the backend in Tauri as well. However, it is pretty vague. See here, search for "Topic 12": https://syntax.fm/show/821/is-tauri-the-electron-killer/transcript https://syntax.fm/show/821/is-tauri-the-electron-killer/tran...

cyanydeez 2y ago
You can used shared buffers in chrome so one could use webworkers for a lot of processing. However, we are still waiting for many Apis to be available in webworkers.
- DanielHB 2y ago
  What you really want is to get a reference to those SharedArrayBuffers in the native code like you can do with WASM

__jonas 2y ago

>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-model 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#ipcrenderersendchannel-args 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.

killcoder 2y 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.
- cyanydeez 2y 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.
  - killcoder 2y 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-preferences https://www.electronjs.org/docs/latest/api/structures/web-pr...