Live data from Hacker News

Show HN: Electrico – Electron Without Node and Chrome

github.com

41–50 of 78 posts

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

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

This doesn’t work. Developers move on to a next version for reasons out of their control. Now a user has a version hell, just like c:\python{all, sorts, of, versions}, and probably a versioned file extension. Bundling tens of megabytes is not a problem for the last ten years. Having everything you need right in your backpack is a good thing for everyone.

It could be feasible if software communities didn’t tend to underimplement features and then solve them by intertwining all sorts of dependencies and their maintenance policies. For example, for as controlled thing as typescript, there are at least four popular ways to “just run” projects, all with different quirks and issues (tsc & node, ts-node, swc-node, tsx). Although it was obvious that people would want to run and watch .ts files based on tsconfig.json, without an explicit compilation step.

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

#42
post #37
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.

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

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

#43
post #42
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.

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.

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

#44
post #27

Earlier quoted context omitted.

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

It most certainly is a huge deal to handle all the browser differences with regular websites.

A big reason people choose Electron is so they don't have to deal with all these differences.

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

#45

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

As it happens, we are building pretty much that over at https://github.com/DioxusLabs/blitz

There was also a recent HN discussion https://news.ycombinator.com/item?id=41221252

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

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

Sounds like Adobe Air. It was pretty nice as a development platform. Something similar for Electron is an interesting idea!

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

#47
post #37
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.

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) any app using Electron has to bundle its own version of Chromium, which is massive. It also means each Electron-powered app is totally ignorant of the other, resulting in a lot of duplication and unnecessary memory usage. When you use the system webview you have minimal bulk and resources can be shared, as if they’re multiple tabs in one browser rather than each one being its own browser.

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

#48

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…

Go to app store on your iPhone, swipe refresh and see how heavy all those native SwfitUI apps are and we are talking only about app updates. You will barely find app less than 100MB and few that are even 300MB+. Didn't check if they are also as heavy on desktop. So that's at least regarding app size on environment impact native apps at least using SwiftUI not making it better - I would say they make it even worse since javascript apps can just autoupdate non native part without downloading whole bundle (and I think this is what slack and discord doing for some updates). SwiftUI apps are also not as fast as UIKit apps not sure about memory performance.

In practise I will take any JetBrains IDE or VSCode over native XCode IDE anytime - XCode is such a big heavy hog.

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

#49

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

I understand where this guy was coming from with the comment about Tauri being the same type of thing, but when you really take a look at Tauri, it seems to really hold up. There are some Tauri apps that have performance that is easily on par with native.

The only thing is that Tauri apps seem to be quite easy for the developer to botch and end up with performance problems. One of the worst performing apps I ever used in my life was a Tauri app.

Post reply on HN