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

11–20 of 78 posts

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

#11

Post by jemmyw »

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.

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

#14

Post by Deukhoofd »

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

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

#15

Post by timeon »

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…

> Discord is one good example also vscode

Discord constantly downloads huge updates and vscode uses too much memory (not counting LSP) for text editor.

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

#17

Post by __jonas »

DanielHB wrote: post #4
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…

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

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

#18

Post by briandear »

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.

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

#19

Post by killcoder »

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

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.

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

#20

Post by v3ss0n »

timeon wrote: post #15
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…

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

Post reply on HN