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.
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.
At this point most operating systems are ahead of Electron on average, not behind it. Electron takes longer to bundle a new Chrome version than it should. Then it takes a while for applications to actually upgrade Electron versions because that includes the compatibility headaches of keeping up with all of Chrome changes, Node changes, and Electron API changes at the same time. Some apps are years behind on Electron today simply because they don't want the headache of rebuilding Node native dependencies or fixing Electron API breaks and think being on an old build of Chrome and the subsequent risk of unpatched security problems is an okay risk to take.
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).
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.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework.
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.
What do you qualify as a "modern mainstream Android device"?
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.)
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.
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.
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?
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.
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
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.
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.
> 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.
>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
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.
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.
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.
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.
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.
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).
Thanks for adding this context! Guess I was mislead by the Electron documentation talking about multiple processes and IPC, appreciate the clarification!
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.
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.
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.
Is it possible to have some kind of electron/tauri/,.. based runtime, but without the actual app? The users would need to install this runtime only once.
The apps would need to be installed separately.
The apps could be just the plain html/js/css/assets maybe packed within a zip, with a dedicated extension. The runtime would take care of the installation.
That way the devs could develop with their FE-stack of their choice and ship just the small packages.
Does this make sense?
It does sound a lot like what Progressive Web Apps (PWAs) are supposed to be. It's very close to how the original Manifest.json worked when given an html/js/css/assets list.
Only a couple of browsers supported that version of Manifest.json. Chrome developers thought it was too much of an 80/20 solution and decided to get deep in the weeds of the 20% instead of delivering the 80% solution while they worked. That's what got us the way too low level and hard to reason with Service Worker APIs for PWAs. It's over-engineered for the 20% of use cases in a way that makes "easy" 80% so much harder than it ever should have been. Chrome developers still randomly promise the web that the "easy high level API" will arrive any day now, but looking at the mess that is Workbox (their team's supposed-to-be high level building block library for Service Worker PWA APIs) it still doesn't look like it will happen any time soon.
It's more the shame because we briefly had a simple JSON manifest format for assets. That JSON format should have been easy to emulate in the Service Worker APIs if those APIs truly were meant to solve the problem, not just solving more interesting problems in a related space that a minority of use cases needed. Google doesn't currently have enough incentive to make PWAs easy to build, and as long as Chrome is the majority browser, Google is the major obstacle.
This doesn’t work. Developers move on to a next version for reasons out of their control. Now a user has a version hell, just like c:\python{all, sorts, of, versions}, and probably a versioned file extension. Bundling tens of megabytes is not a problem for the last ten years. Having everything you need right in your backpack is a good thing for everyone.
It could be feasible if software communities didn’t tend to underimplement features and then solve them by intertwining all sorts of dependencies and their maintenance policies. For example, for as controlled thing as typescript, there are at least four popular ways to “just run” projects, all with different quirks and issues (tsc & node, ts-node, swc-node, tsx). Although it was obvious that people would want to run and watch .ts files based on tsconfig.json, without an explicit compilation step.
I guess that sounds like the normal web/progressive web apps/web archives (especially with the push to more platform APIs in browsers)? Also, Tauri uses the system's WebView2/Webkit runtime, so it essentially works like this already.
This is a pretty standard type of architecture, it's essentially how anything that runs on a virtual machine works. Back when visual basic was popular, it actually surprised me that Microsoft never ended up bundling the VBDLL files with the OS itself allowing developers to ship significantly smaller installation bundles.
Those projects in general have Alot of problem, AND this is a wrapper on top of them.
>Wry also needs WebKitGTK for WebView.
WebKit have a lot more security problems and compatibility issues and are not as updated as chromium based, electron.
There's nothing wrong about chromium based engines like electron. They are just a little bigger for download a little slow to start but that's it. If your code is well developed they are fast and snappy.
Discord is one good example also vscode
WebKitGTK has some really bad performance issues. I've written an app using Tauri and it works very well on Mac and Windows, and it does nothing particularly intensive. On Linux the performance is awful. The Tauri devs acknowledge this and seem to have plans to move off it, but moving to another solution (basically packaging chrome like electron does) is obviously a lot of work.
Yeah, I tried Tauri for a bit, and this was the primary issue I quickly found as well. Generally you use these kinds of tools to be able to easily do cross-platform UI. With Tauri every single OS you target will use a different underlying web browser engine, which means you'll still be running into many platform specific issues.
Especially webkitGTK is just a drama, it's barely able to do layout for basic tables in a performant manner.
In my experience in the current implementation Tauri is not ready for production. I've seen some preliminary work by the Tauri devs to investigate if they could use some standardized webview engine, but that's still very far away.
Zed team also being the creators of Electron should have been the best people for this. They themselves opted to write a new immediate mode UI library.
Yeah,atom too back in atom, they tried really hard to improve speed of atom by rendering in GPU as texture but before that properly implemented MS took over.
Well as a user I appreciate a software that make improvements all the time. Discord add good features, why should I complain about a lot of updates?
VSCode use as much memory as you add extensions. I agree it uses up memory but Jetbrain and Fleet performance is also as bad if not worse then vscode and they use alot more mem.
If u want vscode as just text editor Just disable all the included default extensions.
I like this, as the author of LRCGET (which is made with Tauri), I hate debugging something that works on Windows (Microsoft Edge WebView2) but doesn't work well or doesn't work at all on Linux (Webkit2gtk) or macOS.
One of the example is audio playback. Chromium and in turn Edge WebView2 have great support, but make it work in Webkit2gtk is a big pain in the *s. I then decided to switch the audio playback feature to Rust side (using Kira and Symphonia) instead.
Having Chromium bundled eliminates all the pain about inconsistency between webview engines, and using Rust means we don't have to pay for the NodeJS size in our app bundle (plus better performance).
For Tauri, I think something like Servo will fit well as bundled browser engine. Hopefully some day it will happen.
I’m honestly just waiting for someone to add Rust bindings for Electron (instead of gluing Node to C++ in the main process, and using WASM for the renderer process instead).
Someone may ask why - simply to have options. Tauri is great but there are many users complaining (with justification) that relying on the platform webview sucks, especially on Linux.
In general, there’s no reason Electron can only have a Node API.
I still don’t understand why we’re using any of these Electron-style “apps.”
Ship a web application, or write actual native apps. Electron and that flavor of “app” development is the worst of all worlds.
Just like the JavaScript web frameworks have turned what should be small web applications into huge monsters — Electron has made what should be relatively small, high performance applications into these bloated resource hogs.
I get it, JavaScript developers want to be part of the fun and there is definitely a use case for tiny resource-constrained startups still changing product-market fit. But companies like Slack for instance — worth billions of dollars and can’t find a way to write a high performance desktop app in Swift for MacOS instead opting for Electron.
Think of the climate! All that extra power required to run these resource hog Electron apps on tens of millions of computers isn’t trivial, not to mention a neutered user experience that results from not taking advantage of actual native applications.
JavaScript isn’t the panacea people want it to be.
Electron makes it easy for companies but it makes it rougher for the victims.
And Tauri and all the others are simply different flavors of the same shit sandwich.
Go to app store on your iPhone, swipe refresh and see how heavy all those native SwfitUI apps are and we are talking only about app updates. You will barely find app less than 100MB and few that are even 300MB+. Didn't check if they are also as heavy on desktop. So that's at least regarding app size on environment impact native apps at least using SwiftUI not making it better - I would say they make it even worse since javascript apps can just autoupdate non native part without downloading whole bundle (and I think this is what slack and discord doing for some updates). SwiftUI apps are also not as fast as UIKit apps not sure about memory performance.
In practise I will take any JetBrains IDE or VSCode over native XCode IDE anytime - XCode is such a big heavy hog.
It's great that you mention the climate impact of Electron apps, because those bloated monsters truly are a huge problem; though I think you underestimate how much the Tauri team's focus has been on shrinking app size to alleviate the environmental impact made by the download of said huge Electron apps.
One of the things that actually made me interested in Tauri in the first place was their 1.0 Release[0] which included information on just how much CO2 output would be saved by switching from Electron to a similar Tauri app (600Mb vs 3MB)
Of course you're right that if, instead of using Web UI in the first place, companies went straight to native apps then there'd be even more savings to be made -- but there's trade offs to be made with regards to aligning OSs and reusing components and onboarding engineers and writing good cross-platform tests when working in native that just aren't there when working with a WebUI, and something like Tauri which has many of the upsides with fewer of the externalities of Electron should be applauded at least as a step in the right direction.
I understand where this guy was coming from with the comment about Tauri being the same type of thing, but when you really take a look at Tauri, it seems to really hold up. There are some Tauri apps that have performance that is easily on par with native.
The only thing is that Tauri apps seem to be quite easy for the developer to botch and end up with performance problems. One of the worst performing apps I ever used in my life was a Tauri app.
> The only thing is that Tauri apps seem to be quite easy for the developer to botch and end up with performance problems. One of the worst performing apps I ever used in my life was a Tauri app.
I'd say that's generally true with web-based UIs. It's possible to create web UIs that perform fantastically. But you have to know the platform and be disciplined, and it's easy to mess it up.
For me, writing JS is not great, but using HTML and CSS is what just resonates for me when it comes to building front end applications. If I need some device privileges that a browser cannot grant me, then I will use a HTML/CSS based renderer for that app.
Now, I have grand visions for an embedded servo renderer that can be driven using native compiles rust, not JS. But who knows if we will get that one day
This does make sense from a "crafting great software" perspective.
But building three separate codebases in comparatively niche GUI frameworks full of platform-specific quirks when you could achieve 95% of the quality with a single JS/TS codebase comes across pretty terribly as a business decision. It's hard to justify what is likely a 10x-ish cost multiplier with "it uses less RAM" or "the scrolling feels more natural". While large companies can afford it, the cost-benefit still doesn't look good to them.
If Lazarus supported other languages beside Object Pascal, that would be the truly native multiplatform integrated development system the world is looking for.
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.
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.
At this point most operating systems are ahead of Electron on average, not behind it. Electron takes longer to bundle a new Chrome version than it should. Then it takes a while for applications to actually upgrade Electron versions because that includes the compatibility headaches of keeping up with all of Chrome changes, Node changes, and Electron API changes at the same time. Some apps are years behind on Electron today simply because they don't want the headache of rebuilding Node native dependencies or fixing Electron API breaks and think being on an old build of Chrome and the subsequent risk of unpatched security problems is an okay risk to take.
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).
> Some apps are years behind on Electron today
Could you give some examples? This seems like a potential security risk.
Random output from my system:
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.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework.
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.
Tauri is indeed heading to mobile.
https://v2.tauri.app/blog/tauri-mobile-alpha/
On modern mainstream Android devices, the Webview is based on chromium and regularly updated through the play store
What do you qualify as a "modern mainstream Android device"?
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.)
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.
Took note, thanks!
It might be a minor compatibility pain, but I don't think it'd be any worse than developing for the web in general.
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.
> they are on a specific modern version of Chrome.
For some value of "modern", usually "horrifyingly outdated".
> I guess to save distribution space.
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?
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.
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,
https://www.electronjs.org/docs/latest/tutorial/process-mode...Renderers can access Node APIs via the ‘node integration’ setting or via a preload script.
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.
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-inte...
> 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.
>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.
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.
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.
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...
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.
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).
Thanks for adding this context! Guess I was mislead by the Electron documentation talking about multiple processes and IPC, appreciate the clarification!
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/tran...
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.
What you really want is to get a reference to those SharedArrayBuffers in the native code like you can do with WASM
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.
Yes, but imo it's not a huge deal as we are used to this with regular websites
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.
Is it possible to have some kind of electron/tauri/,.. based runtime, but without the actual app? The users would need to install this runtime only once. The apps would need to be installed separately. The apps could be just the plain html/js/css/assets maybe packed within a zip, with a dedicated extension. The runtime would take care of the installation. That way the devs could develop with their FE-stack of their choice and ship just the small packages. Does this make sense?
It does sound a lot like what Progressive Web Apps (PWAs) are supposed to be. It's very close to how the original Manifest.json worked when given an html/js/css/assets list.
Only a couple of browsers supported that version of Manifest.json. Chrome developers thought it was too much of an 80/20 solution and decided to get deep in the weeds of the 20% instead of delivering the 80% solution while they worked. That's what got us the way too low level and hard to reason with Service Worker APIs for PWAs. It's over-engineered for the 20% of use cases in a way that makes "easy" 80% so much harder than it ever should have been. Chrome developers still randomly promise the web that the "easy high level API" will arrive any day now, but looking at the mess that is Workbox (their team's supposed-to-be high level building block library for Service Worker PWA APIs) it still doesn't look like it will happen any time soon.
It's more the shame because we briefly had a simple JSON manifest format for assets. That JSON format should have been easy to emulate in the Service Worker APIs if those APIs truly were meant to solve the problem, not just solving more interesting problems in a related space that a minority of use cases needed. Google doesn't currently have enough incentive to make PWAs easy to build, and as long as Chrome is the majority browser, Google is the major obstacle.
That's genius! I propose we call this system of apps "the World Wide Web" and call the runtime you install, a "Web browser".
Yeah the problem is web sites are way more restricted than apps in what they can do. Apps need to use native APIs. They need to be more active. x
This doesn’t work. Developers move on to a next version for reasons out of their control. Now a user has a version hell, just like c:\python{all, sorts, of, versions}, and probably a versioned file extension. Bundling tens of megabytes is not a problem for the last ten years. Having everything you need right in your backpack is a good thing for everyone.
It could be feasible if software communities didn’t tend to underimplement features and then solve them by intertwining all sorts of dependencies and their maintenance policies. For example, for as controlled thing as typescript, there are at least four popular ways to “just run” projects, all with different quirks and issues (tsc & node, ts-node, swc-node, tsx). Although it was obvious that people would want to run and watch .ts files based on tsconfig.json, without an explicit compilation step.
I guess that sounds like the normal web/progressive web apps/web archives (especially with the push to more platform APIs in browsers)? Also, Tauri uses the system's WebView2/Webkit runtime, so it essentially works like this already.
This is a pretty standard type of architecture, it's essentially how anything that runs on a virtual machine works. Back when visual basic was popular, it actually surprised me that Microsoft never ended up bundling the VBDLL files with the OS itself allowing developers to ship significantly smaller installation bundles.
Sounds like Adobe Air. It was pretty nice as a development platform. Something similar for Electron is an interesting idea!
Those projects in general have Alot of problem, AND this is a wrapper on top of them.
>Wry also needs WebKitGTK for WebView.
WebKit have a lot more security problems and compatibility issues and are not as updated as chromium based, electron.
There's nothing wrong about chromium based engines like electron. They are just a little bigger for download a little slow to start but that's it. If your code is well developed they are fast and snappy. Discord is one good example also vscode
WebKitGTK has some really bad performance issues. I've written an app using Tauri and it works very well on Mac and Windows, and it does nothing particularly intensive. On Linux the performance is awful. The Tauri devs acknowledge this and seem to have plans to move off it, but moving to another solution (basically packaging chrome like electron does) is obviously a lot of work.
WebkitGTK on Linux is arguably woefully unoptimized. I think people make the mistake of thinking "it's WebKit so it's fast" when it's not that simple.
e.g, it took Igalia getting involved to move more things to the GPU when other platforms more or less had that by default already.
https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...
I used WebKit in both gtk and qt . QT team did good job by building qtwebengine that update regularly outside of toolkit release process.
Yeah, I tried Tauri for a bit, and this was the primary issue I quickly found as well. Generally you use these kinds of tools to be able to easily do cross-platform UI. With Tauri every single OS you target will use a different underlying web browser engine, which means you'll still be running into many platform specific issues.
Especially webkitGTK is just a drama, it's barely able to do layout for basic tables in a performant manner.
In my experience in the current implementation Tauri is not ready for production. I've seen some preliminary work by the Tauri devs to investigate if they could use some standardized webview engine, but that's still very far away.
Only way to compete electron is by building a webtech compatible UI engine that is lighter weight, more secure, higher performance, and renders well.
That is big engineering task and not something a small group of devs can do.
Only thing that could comes close is building electron and chromium compatible api on top of Zed team's UI engine.
Zed team also being the creators of Electron should have been the best people for this. They themselves opted to write a new immediate mode UI library.
Yeah,atom too back in atom, they tried really hard to improve speed of atom by rendering in GPU as texture but before that properly implemented MS took over.
> Discord is one good example also vscode
Discord constantly downloads huge updates and vscode uses too much memory (not counting LSP) for text editor.
Well as a user I appreciate a software that make improvements all the time. Discord add good features, why should I complain about a lot of updates?
VSCode use as much memory as you add extensions. I agree it uses up memory but Jetbrain and Fleet performance is also as bad if not worse then vscode and they use alot more mem.
If u want vscode as just text editor Just disable all the included default extensions.
I like this, as the author of LRCGET (which is made with Tauri), I hate debugging something that works on Windows (Microsoft Edge WebView2) but doesn't work well or doesn't work at all on Linux (Webkit2gtk) or macOS.
One of the example is audio playback. Chromium and in turn Edge WebView2 have great support, but make it work in Webkit2gtk is a big pain in the *s. I then decided to switch the audio playback feature to Rust side (using Kira and Symphonia) instead.
Having Chromium bundled eliminates all the pain about inconsistency between webview engines, and using Rust means we don't have to pay for the NodeJS size in our app bundle (plus better performance).
For Tauri, I think something like Servo will fit well as bundled browser engine. Hopefully some day it will happen.
> cross platform for linux, macos, linux, ios and android
I like how Linux is so important it gets two mentions, but Windows is left out. Presumably that's a typo though?
Should be, yes. Tauri supports windows, and this wraps it.
This should be merged into tauri, like how bun also supports nodejs api
I’m honestly just waiting for someone to add Rust bindings for Electron (instead of gluing Node to C++ in the main process, and using WASM for the renderer process instead).
Someone may ask why - simply to have options. Tauri is great but there are many users complaining (with justification) that relying on the platform webview sucks, especially on Linux.
In general, there’s no reason Electron can only have a Node API.
I’ve been using Electrobun lately which is (Bun + System Webview) and it’s been great.
Only supports ARM Mac at the moment but windows and linux support coming soon.
https://www.electrobun.dev
Is it compatible with Deno? Nice project.
Missed a great opportunity to call it Electron Neutrino (Neutrino for short)
It might have been confusing since there's another project operating in this space called Neutralinojs.
It's never too late to pivot.
Or in this case, it's never too late to spin.
I still don’t understand why we’re using any of these Electron-style “apps.”
Ship a web application, or write actual native apps. Electron and that flavor of “app” development is the worst of all worlds.
Just like the JavaScript web frameworks have turned what should be small web applications into huge monsters — Electron has made what should be relatively small, high performance applications into these bloated resource hogs.
I get it, JavaScript developers want to be part of the fun and there is definitely a use case for tiny resource-constrained startups still changing product-market fit. But companies like Slack for instance — worth billions of dollars and can’t find a way to write a high performance desktop app in Swift for MacOS instead opting for Electron.
Think of the climate! All that extra power required to run these resource hog Electron apps on tens of millions of computers isn’t trivial, not to mention a neutered user experience that results from not taking advantage of actual native applications.
JavaScript isn’t the panacea people want it to be.
Electron makes it easy for companies but it makes it rougher for the victims.
And Tauri and all the others are simply different flavors of the same shit sandwich.
Go to app store on your iPhone, swipe refresh and see how heavy all those native SwfitUI apps are and we are talking only about app updates. You will barely find app less than 100MB and few that are even 300MB+. Didn't check if they are also as heavy on desktop. So that's at least regarding app size on environment impact native apps at least using SwiftUI not making it better - I would say they make it even worse since javascript apps can just autoupdate non native part without downloading whole bundle (and I think this is what slack and discord doing for some updates). SwiftUI apps are also not as fast as UIKit apps not sure about memory performance.
In practise I will take any JetBrains IDE or VSCode over native XCode IDE anytime - XCode is such a big heavy hog.
It's great that you mention the climate impact of Electron apps, because those bloated monsters truly are a huge problem; though I think you underestimate how much the Tauri team's focus has been on shrinking app size to alleviate the environmental impact made by the download of said huge Electron apps.
One of the things that actually made me interested in Tauri in the first place was their 1.0 Release[0] which included information on just how much CO2 output would be saved by switching from Electron to a similar Tauri app (600Mb vs 3MB)
Of course you're right that if, instead of using Web UI in the first place, companies went straight to native apps then there'd be even more savings to be made -- but there's trade offs to be made with regards to aligning OSs and reusing components and onboarding engineers and writing good cross-platform tests when working in native that just aren't there when working with a WebUI, and something like Tauri which has many of the upsides with fewer of the externalities of Electron should be applauded at least as a step in the right direction.
[0]: https://tauri.app/blog/2022/06/19/tauri-1-0/#environment
I understand where this guy was coming from with the comment about Tauri being the same type of thing, but when you really take a look at Tauri, it seems to really hold up. There are some Tauri apps that have performance that is easily on par with native.
The only thing is that Tauri apps seem to be quite easy for the developer to botch and end up with performance problems. One of the worst performing apps I ever used in my life was a Tauri app.
> The only thing is that Tauri apps seem to be quite easy for the developer to botch and end up with performance problems. One of the worst performing apps I ever used in my life was a Tauri app.
I'd say that's generally true with web-based UIs. It's possible to create web UIs that perform fantastically. But you have to know the platform and be disciplined, and it's easy to mess it up.
For me, writing JS is not great, but using HTML and CSS is what just resonates for me when it comes to building front end applications. If I need some device privileges that a browser cannot grant me, then I will use a HTML/CSS based renderer for that app.
Now, I have grand visions for an embedded servo renderer that can be driven using native compiles rust, not JS. But who knows if we will get that one day
As it happens, we are building pretty much that over at https://github.com/DioxusLabs/blitz
There was also a recent HN discussion https://news.ycombinator.com/item?id=41221252
This does make sense from a "crafting great software" perspective.
But building three separate codebases in comparatively niche GUI frameworks full of platform-specific quirks when you could achieve 95% of the quality with a single JS/TS codebase comes across pretty terribly as a business decision. It's hard to justify what is likely a 10x-ish cost multiplier with "it uses less RAM" or "the scrolling feels more natural". While large companies can afford it, the cost-benefit still doesn't look good to them.
The only thing I like about Electron apps is that they just work on Linux, otherwise not many companies would bother porting their apps to Linux.
I think web apps/Electron apps may be a factor in reaching the year of the Linux desktop.
If Lazarus supported other languages beside Object Pascal, that would be the truly native multiplatform integrated development system the world is looking for.