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

51–60 of 78 posts

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

#51

Post by abhinavk »

v3ss0n wrote: post #25
Deukhoofd wrote: post #14

Earlier quoted context omitted.

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.

Zed team also being the creators of Electron should have been the best people for this. They themselves opted to write a new immediate mode UI library.

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

#52

Post by danenania »

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…

This does make sense from a "crafting great software" perspective.

But building three separate codebases in comparatively niche GUI frameworks full of platform-specific quirks when you could achieve 95% of the quality with a single JS/TS codebase comes across pretty terribly as a business decision. It's hard to justify what is likely a 10x-ish cost multiplier with "it uses less RAM" or "the scrolling feels more natural". While large companies can afford it, the cost-benefit still doesn't look good to them.

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

#53

Post by lucasyvas »

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.

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

#54

Post by wruza »

afavour wrote: post #47
wruza wrote: post #37

Earlier quoted context omitted.

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.

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

Took note, thanks!

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

#55

Post by wavemode »

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…

That's genius! I propose we call this system of apps "the World Wide Web" and call the runtime you install, a "Web browser".

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

#56

Post by WorldMaker »

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

At this point most operating systems are ahead of Electron on average, not behind it. Electron takes longer to bundle a new Chrome version than it should. Then it takes a while for applications to actually upgrade Electron versions because that includes the compatibility headaches of keeping up with all of Chrome changes, Node changes, and Electron API changes at the same time. Some apps are years behind on Electron today simply because they don't want the headache of rebuilding Node native dependencies or fixing Electron API breaks and think being on an old build of Chrome and the subsequent risk of unpatched security problems is an okay risk to take.

There is still a long tail of versions you might encounter when using a (security supported OS), but for most Linux distros, macOS, and Windows the worst case in the long tail is now just 6 months behind. (You lose security support if you don't keep up with semiannual OS releases.) If you have reason such as a corporate overlord to also support LTS OSes the worst case is closer to 2 years depending on Unix distro. (Windows WebView2 remembers IE and still requires regular update cadence even on LTS Windows, so WebView2 on today's LTS Windows should still be closer to the 6 month mark than the 2 year mark if following Microsoft's LTS policies, staying within support, and not paying for more complicated LTS contracts.)

It should be very easy with caniuse/MDN statistics to write web apps for any browser of the last six months. If you plan to support macOS you still need to support two (related like siblings) renderers as macOS wants you to use WebKit/Safari and everything else is Chromium in one way or another today, but testing on two browsers shouldn't be a showstopper for many (most?) apps. There are definitely Chrome-only APIs that might appeal to you in building an app, but at that point many of them you can polyfill with a native dependency (a Rust dependency in the Tauri world).

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

#57

Post by WorldMaker »

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…

It does sound a lot like what Progressive Web Apps (PWAs) are supposed to be. It's very close to how the original Manifest.json worked when given an html/js/css/assets list.

Only a couple of browsers supported that version of Manifest.json. Chrome developers thought it was too much of an 80/20 solution and decided to get deep in the weeds of the 20% instead of delivering the 80% solution while they worked. That's what got us the way too low level and hard to reason with Service Worker APIs for PWAs. It's over-engineered for the 20% of use cases in a way that makes "easy" 80% so much harder than it ever should have been. Chrome developers still randomly promise the web that the "easy high level API" will arrive any day now, but looking at the mess that is Workbox (their team's supposed-to-be high level building block library for Service Worker PWA APIs) it still doesn't look like it will happen any time soon.

It's more the shame because we briefly had a simple JSON manifest format for assets. That JSON format should have been easy to emulate in the Service Worker APIs if those APIs truly were meant to solve the problem, not just solving more interesting problems in a related space that a minority of use cases needed. Google doesn't currently have enough incentive to make PWAs easy to build, and as long as Chrome is the majority browser, Google is the major obstacle.

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

#58

Post by fs0c13ty00 »

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.

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

#59

Post by paxcoder »

Sammi wrote: post #43
Retr0id wrote: post #42

Earlier quoted context omitted.

It might be a minor compatibility pain, but I don't think it'd be any worse than developing for the web in general.

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.

[dead]

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

#60

Post by v3ss0n »

abhinavk wrote: post #51
v3ss0n wrote: post #25

Earlier quoted context omitted.

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.

Zed team also being the creators of Electron should have been the best people for this. They themselves opted to write a new immediate mode UI library.

Yeah,atom too back in atom, they tried really hard to improve speed of atom by rendering in GPU as texture but before that properly implemented MS took over.
Post reply on HN