Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Electrico – Electron Without Node and Chrome

github.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Show HN: Electrico – Electron Without Node and Chrome

#31

Post by DanielHB »

__jonas wrote: post #17
DanielHB wrote: post #4

Earlier quoted context omitted.

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…

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

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.

Re: Show HN: Electrico – Electron Without Node and Chrome

#32

Post by killcoder »

cyanydeez wrote: post #23
killcoder wrote: post #19

Earlier quoted context omitted.

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

Re: Show HN: Electrico – Electron Without Node and Chrome

#33

Post by squarefoot »

adhamsalama wrote: post #28
briandear wrote: post #18

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 resou…

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.

Re: Show HN: Electrico – Electron Without Node and Chrome

#34

Post by killcoder »

DanielHB wrote: post #31
__jonas wrote: post #17

Earlier quoted context omitted.

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

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…

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

Re: Show HN: Electrico – Electron Without Node and Chrome

#35

Post by killcoder »

koito17 wrote: post #5
DanielHB wrote: post #4

Earlier quoted context omitted.

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…

Renderers can access Node APIs via the ‘node integration’ setting or via a preload script.

Re: Show HN: Electrico – Electron Without Node and Chrome

#36

Post by explodingcamera »

5kyn3t wrote: post #29

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 c…

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.

Re: Show HN: Electrico – Electron Without Node and Chrome

#37

Post by wruza »

koito17 wrote: post #2

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 Taur…

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.

Re: Show HN: Electrico – Electron Without Node and Chrome

#38

Post by conradludgate »

briandear wrote: post #18

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 resou…

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

Re: Show HN: Electrico – Electron Without Node and Chrome

#39

Post by lost_womble »

briandear wrote: post #18

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 resou…

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

Re: Show HN: Electrico – Electron Without Node and Chrome

#40

Post by __jonas »

killcoder wrote: post #34
DanielHB wrote: post #31

Earlier quoted context omitted.

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…

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…

Thanks for adding this context! Guess I was mislead by the Electron documentation talking about multiple processes and IPC, appreciate the clarification!
Post reply on HN