Show HN: Electrico – Electron Without Node and Chrome
1–10 of 78 posts
Re: Show HN: Electrico – Electron Without Node and Chrome
#2Looks 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.
Re: Show HN: Electrico – Electron Without Node and Chrome
#3[deleted]
Re: Show HN: Electrico – Electron Without Node and Chrome
#4Looks 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 Taur…
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.
Re: Show HN: Electrico – Electron Without Node and Chrome
#5Looks 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 Taur…
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 y…
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
Re: Show HN: Electrico – Electron Without Node and Chrome
#6Missed a great opportunity to call it Electron Neutrino (Neutrino for short)
Re: Show HN: Electrico – Electron Without Node and Chrome
#7Looks 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 Taur…
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 y…
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...
Re: Show HN: Electrico – Electron Without Node and Chrome
#8Missed a great opportunity to call it Electron Neutrino (Neutrino for short)
It's never too late to pivot.
Re: Show HN: Electrico – Electron Without Node and Chrome
#9> 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?
Re: Show HN: Electrico – Electron Without Node and Chrome
#10Those 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