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.
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
Makes sense.
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-inte...
See here, search for "Topic 12": https://syntax.fm/show/821/is-tauri-the-electron-killer/tran...
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.
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.
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.
Source: https://www.electronjs.org/docs/latest/api/structures/web-pr...
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.
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).
This seems very overlooked in your evaluation.
A big reason people choose Electron is so they don't have to deal with all these differences.
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.
There is still a long tail of versions you might encounter when using a (security supported OS), but for most Linux distros, macOS, and Windows the worst case in the long tail is now just 6 months behind. (You lose security support if you don't keep up with semiannual OS releases.) If you have reason such as a corporate overlord to also support LTS OSes the worst case is closer to 2 years depending on Unix distro. (Windows WebView2 remembers IE and still requires regular update cadence even on LTS Windows, so WebView2 on today's LTS Windows should still be closer to the 6 month mark than the 2 year mark if following Microsoft's LTS policies, staying within support, and not paying for more complicated LTS contracts.)
It should be very easy with caniuse/MDN statistics to write web apps for any browser of the last six months. If you plan to support macOS you still need to support two (related like siblings) renderers as macOS wants you to use WebKit/Safari and everything else is Chromium in one way or another today, but testing on two browsers shouldn't be a showstopper for many (most?) apps. There are definitely Chrome-only APIs that might appeal to you in building an app, but at that point many of them you can polyfill with a native dependency (a Rust dependency in the Tauri world).
Could you give some examples? This seems like a potential security risk.
App Name: Microsoft Azure Storage Explorer.app Electron Version: 25.8.4 -n File Name: /Applications/Microsoft Azure Storage Explorer.app/Contents/Frameworks/Electron Framework.framework/Electron Framework -e App Name: MongoDB Compass.app Electron Version: 30.4.0 -n File Name: /Applications/MongoDB Compass.app/Contents/Frameworks/Electron Framework.framework/Electron Framework -e App Name: Obsidian.app Electron Version: 25.8.1 -n File Name: /Applications/Obsidian.app/Contents/Frameworks/Electron Framework.framework/Electron Framework
And to answer your question: yes this is very much a security issue. There are many unpatched versions that are vulnerable to webp exploits, including chat apps (with the serious implications of that being obvious)
Web devs shouldn't be allowed anywhere near native APIs.
Personally I'd agree with this. I'd also include saving the RAM of loading an independent version of Chrome for every electron app would be nice. Last, I never understood what version of chrome gets bundled with these electron apps. Is it more or less secure than WRY?
On both Windows and macOS, the "OS webview" is just a framework binding to the OS-shipped browser (i.e. Edge, Safari); and both Edge and Safari get updated with pretty much every release of the OS (which, in turn, are kept up-to-date in a pretty pushy way these days by Microsoft and Apple.)
Also, in both of these cases, by relying on these OS webviews, you're "sharing" the renderer and other global context with the actual browser (if the user happens to use it), and with all other OS webviews on the machine — rather than each new app needing its own renderer and global context, wasting 1GB+ of memory per app and creating thousands of redundant files on disk for the app's own cache et al.
It's really a pure win vs. Electron for these cases.
On Linux, what you get depends on the distribution format. If distributed as a package, you get a dynamic binding to WebKitGtk — which requires the package manager to resolve and install this (and that might not work, if the distro doesn't ship that package.) If distributed as an .AppImage, you get a vendored-in copy of WebKitGtk — which is basically the same as what you get from Electron.
I think the median Android device out there in the world today — just by sheer volume of them produced — is probably a "Welcome" phone with a MediaTek 6580 chipset and a faked-capacity SD card; i.e. hardware that couldn't possibly run any Android version made in the last six years.
(Such phones could in theory run Android Go... but they often don't, because these devices are often running non-Google-Play-Store AOSP derivatives — and there's no un-Googled version of Android Go.)
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.
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.
For some value of "modern", usually "horrifyingly outdated".
A bit less uncertainty via: https://v2.tauri.app/reference/webview-versions/
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.