11 ms·

Looks like a thin wrapper around Tauri. The README doesn't do a good job at explaining why one should use this over Tauri itself. From what I understand, this

Looks like a thin wrapper around Tauri. The README doesn't do a good job at explaining why one should use this over Tauri itself. From what I understand, this project attempts to implement a subset of the Electron API so that the library can act as a "drop-in replacement" for simple enough Electron apps. If this understanding is correct, then I think Electrico has the potential to significantly boost adoption of Tauri. For those who don't know: Tauri is a collection of Rust libraries that allow using an operating system's "native web view" (WRY) and a Rust backend for the process backing a web view (there is an IPC layer between JS and Rust). The overall result is that, on Mac OS and Windows, one can distribute native executables without needing to bundle either Node.js or Chromium. There is no startup cost of loading Node.js, since a native Rust binary is used. As for the web view itself, startup tends to be faster than Chromium, since the libraries for e.g. WebKit are usually pre-loaded by the OS itself. Tauri apps have near-instant startup time, and I've found it to be a joy to use. The only downside is that the backend must be written in Rust. Electrico seems to help soften the learning curve by providing JavaScript APIs mirroring that of Electron. Overall, nice project.

DanielHB 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. 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...
cyanydeez 2y ago
Isnt another downside that the javascript in the OS web view could be different and lead to having to support a significant number of different webview versions. If you ship chrome with your app, you get to choose the conformance. This seems very overlooked in your evaluation.
- pipe01 2y ago
  Yes, but imo it's not a huge deal as we are used to this with regular websites
  - Sammi 2y ago
    It most certainly is a huge deal to handle all the browser differences with regular websites. A big reason people choose Electron is so they don't have to deal with all these differences.
wruza 2y ago
an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.
- Retr0id 2y ago
  It might be a minor compatibility pain, but I don't think it'd be any worse than developing for the web in general.
  - Sammi 2y ago
    The alternative to Tauri isn't the web - it's Electron which has a specific Chrome version. One big reason people go for delivering their web apps through Electron is so they can guarantee that they are on a specific modern version of Chrome. This is something you lose with Tauri. You gain some tighter memory consumption, but you do trade one thing in for another.
    - paxcoder 2y ago
      [dead]
    - creshal 2y ago
      > they are on a specific modern version of Chrome. For some value of "modern", usually "horrifyingly outdated".
- afavour 2y ago
  Not really. MacOS’s webview is kept relatively up to date with whatever version of Safari is current when the OS is released. Webview2 on Windows receives regular updates via Windows Update. You encounter the exact same compatibility issues you would on the web, with a somewhat slower uptake to new versions. Not ideal but entirely manageable. > why would one want to use it Primarily because (last I checked, anyway) any app using Electron has to bundle its own version of Chromium, which is massive. It also means each Electron-powered app is totally ignorant of the other, resulting in a lot of duplication and unnecessary memory usage. When you use the system webview you have minimal bulk and resources can be shared, as if they’re multiple tabs in one browser rather than each one being its own browser.

DanielHB 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. 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...

cyanydeez 2y ago

Isnt another downside that the javascript in the OS web view could be different and lead to having to support a significant number of different webview versions. If you ship chrome with your app, you get to choose the conformance. This seems very overlooked in your evaluation.

pipe01 2y ago
Yes, but imo it's not a huge deal as we are used to this with regular websites
- Sammi 2y ago
  It most certainly is a huge deal to handle all the browser differences with regular websites. A big reason people choose Electron is so they don't have to deal with all these differences.

wruza 2y ago

an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.

Retr0id 2y ago
It might be a minor compatibility pain, but I don't think it'd be any worse than developing for the web in general.
- Sammi 2y ago
  The alternative to Tauri isn't the web - it's Electron which has a specific Chrome version. One big reason people go for delivering their web apps through Electron is so they can guarantee that they are on a specific modern version of Chrome. This is something you lose with Tauri. You gain some tighter memory consumption, but you do trade one thing in for another.
  - paxcoder 2y ago
    [dead]
  - creshal 2y ago
    > they are on a specific modern version of Chrome. For some value of "modern", usually "horrifyingly outdated".
afavour 2y ago
Not really. MacOS’s webview is kept relatively up to date with whatever version of Safari is current when the OS is released. Webview2 on Windows receives regular updates via Windows Update. You encounter the exact same compatibility issues you would on the web, with a somewhat slower uptake to new versions. Not ideal but entirely manageable. > why would one want to use it Primarily because (last I checked, anyway) any app using Electron has to bundle its own version of Chromium, which is massive. It also means each Electron-powered app is totally ignorant of the other, resulting in a lot of duplication and unnecessary memory usage. When you use the system webview you have minimal bulk and resources can be shared, as if they’re multiple tabs in one browser rather than each one being its own browser.