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

21–30 of 78 posts

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

#21

Post by v3ss0n »

jemmyw wrote: post #11
v3ss0n wrote: post #10

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…

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.

I used WebKit in both gtk and qt . QT team did good job by building qtwebengine that update regularly outside of toolkit release process.

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

#22

Post by cyanydeez »

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…

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.

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

#23

Post by cyanydeez »

killcoder wrote: post #19
__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…

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.

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

#24

Post by cyanydeez »

baumschubser wrote: post #7
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 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.

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

#25

Post by v3ss0n »

Deukhoofd wrote: post #14
v3ss0n wrote: post #10

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…

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…

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.

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

#26

Post by notpushkin »

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…

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

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

#27

Post by pipe01 »

cyanydeez wrote: post #22
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…

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

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

#28

Post by adhamsalama »

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.

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

#29

Post by 5kyn3t »

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?

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

#30

Post by DanielHB »

cyanydeez wrote: post #24
baumschubser wrote: post #7

Earlier quoted context omitted.

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
Post reply on HN