7 ms·

Show HN: Electrico – Electron Without Node and Chrome

214 points by thomastsch 2y ago

koito17 2y ago
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.
deleted 2y ago
[deleted]
ijidak 2y ago
Missed a great opportunity to call it Electron Neutrino (Neutrino for short)
- mirzap 2y ago
  It's never too late to pivot.
  - sgc 2y ago
    Or in this case, it's never too late to spin.
- throwitaway1123 2y ago
  It might have been confusing since there's another project operating in this space called Neutralinojs.
mkl 2y ago
> 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?
- fredoliveira 2y ago
  Should be, yes. Tauri supports windows, and this wraps it.
v3ss0n 2y ago
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
- jemmyw 2y ago
  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.
  - v3ss0n 2y ago
    I used WebKit in both gtk and qt . QT team did good job by building qtwebengine that update regularly outside of toolkit release process.
  - Klonoar 2y ago
    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-switching-to-skia-for-2d-graphics-rendering/ https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...
- timeon 2y ago
  > Discord is one good example also vscode Discord constantly downloads huge updates and vscode uses too much memory (not counting LSP) for text editor.
  - 2y ago
AbuAssar 2y ago
This should be merged into tauri, like how bun also supports nodejs api
briandear 2y ago
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.
- adhamsalama 2y ago
  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.
  - squarefoot 2y ago
    If Lazarus supported other languages beside Object Pascal, that would be the truly native multiplatform integrated development system the world is looking for.
    - actionfromafar 2y ago
      Hm... maybe there is a case for Lazarus bindings to other languages like Rust. (Or, dare I say it, C++)
- conradludgate 2y ago
5kyn3t 2y ago
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?
- explodingcamera 2y ago
  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.
- wruza 2y ago
  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.
- danenania 2y ago
  Sounds like Adobe Air. It was pretty nice as a development platform. Something similar for Electron is an interesting idea!
- wavemode 2y ago
  That's genius! I propose we call this system of apps "the World Wide Web" and call the runtime you install, a "Web browser".
lucasyvas 2y ago
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.
fs0c13ty00 2y ago
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.
fithisux 2y ago
Is it compatible with Deno? Nice project.
yoav 2y ago
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 https://www.electrobun.dev

214 points by thomastsch 2y ago

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.

deleted 2y ago

[deleted]

ijidak 2y ago

Missed a great opportunity to call it Electron Neutrino (Neutrino for short)

mirzap 2y ago
It's never too late to pivot.
- sgc 2y ago
  Or in this case, it's never too late to spin.
throwitaway1123 2y ago
It might have been confusing since there's another project operating in this space called Neutralinojs.

mkl 2y ago

> 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?

fredoliveira 2y ago
Should be, yes. Tauri supports windows, and this wraps it.

v3ss0n 2y ago

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

jemmyw 2y ago
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.
- v3ss0n 2y ago
  I used WebKit in both gtk and qt . QT team did good job by building qtwebengine that update regularly outside of toolkit release process.
- Klonoar 2y ago
  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-switching-to-skia-for-2d-graphics-rendering/ https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...
timeon 2y ago
> Discord is one good example also vscode Discord constantly downloads huge updates and vscode uses too much memory (not counting LSP) for text editor.
- 2y ago

AbuAssar 2y ago

This should be merged into tauri, like how bun also supports nodejs api

briandear 2y ago

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.

adhamsalama 2y ago
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.
- squarefoot 2y ago
  If Lazarus supported other languages beside Object Pascal, that would be the truly native multiplatform integrated development system the world is looking for.
  - actionfromafar 2y ago
    Hm... maybe there is a case for Lazarus bindings to other languages like Rust. (Or, dare I say it, C++)
conradludgate 2y ago

5kyn3t 2y ago

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?

explodingcamera 2y ago
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.
wruza 2y ago
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.
danenania 2y ago
Sounds like Adobe Air. It was pretty nice as a development platform. Something similar for Electron is an interesting idea!
wavemode 2y ago
That's genius! I propose we call this system of apps "the World Wide Web" and call the runtime you install, a "Web browser".

lucasyvas 2y ago

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.

fs0c13ty00 2y ago

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.

fithisux 2y ago

Is it compatible with Deno? Nice project.

yoav 2y ago

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 https://www.electrobun.dev