Live data from Hacker News

Tauri: An Electron alternative written in Rust

tauri.studio

131–140 of 438 posts

Re: Tauri: An Electron alternative written in Rust

#132
post #93

Earlier quoted context omitted.

Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend. For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doub…

Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.

[deleted]

Re: Tauri: An Electron alternative written in Rust

#133

Earlier quoted context omitted.

For most apps - wouldn't PWA's be sufficient as implemented today. Presumably, they'll expose more and more hardware APIs over time?

Even basic things like reading and writing files from the filesystem are obnoxiously difficult in a pure browser or PWA environment. Storing state in general is full of enormous pitfalls and eccentricities, like 50mb limits for some browsers or just completely random total deletion of all app state at the browser's whim.

Seems like they are making a lot of progress on that front: https://web.dev/file-system-access/

Re: Tauri: An Electron alternative written in Rust

#134
post #99

Earlier quoted context omitted.

That's not the baseline though, the baseline RAM consumption for an Electron app is about 100MB. If you have garbage code as input it doesn't matter which stack executes it, you'll have garbage performance output.

Even 100MB is crazy. I know RAM is cheap but the absurdity of that amount is beyond me.

It’s not crazy - go run a blank Cocoa app in Xcode and see how much memory it takes.

People have unrealistic expectations on this.

Re: Tauri: An Electron alternative written in Rust

#136

This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible? It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is…

Electrino, but looks abandoned:

https://github.com/pojala/electrino

Re: Tauri: An Electron alternative written in Rust

#137

Hmm, there doesn't seem to be any real applications made with it yet. Though, the roadmap looks good.

Not sure why this is downvoted, this is a good point.

Before people are getting hyped around this, this is alpha software and not production ready.

Re: Tauri: An Electron alternative written in Rust

#138
post #83

Earlier quoted context omitted.

Some people haven't dealt with browser incompatibilities in the past. Not every developer comes from a webapp background, and electron is a platform to develop desktop apps. desktop app developers don't want to deal with polyfills and feature-detection in their platform.

It's weird to want all the benefits of web development without it's unfortunate quirks in my opinion. If desktop developers don't want to deal with them, which I think is reasonable, they have loads of other tools they can use to build desktop apps (and give the users a better experience most likely).

It's not weird - every developer wants to 'just code' their features/business logic without having to deal with the pain points of the tech. They choose web tech for their app because the opportunity cost of learning a desktop-native language is the time that could be spent bootstrapping an electron app and getting the product out the door earlier.

Re: Tauri: An Electron alternative written in Rust

#139
post #16

Earlier quoted context omitted.

As a developer shipping executables to MacOS, Windows, and Linux today this is the only assumption I can make. I cannot assume that dependencies exist or are the correct version, I can't assume the user knows that package managers exist or that the dependencies shipped by the package managers are correct, I can't assume anything exists on PATH or LD_LIBRARY_PATH, and I can't even assume that libc or libc++ on a syste…

It isn't your fault that you have to do this, it is that our industry hasn't created enough quality, easy to use, cross platform gui libraries for popular languages, such that the only viable place to turn is to use a whole web browser.

We've had about 60 years and multiple huge attempts at it, and IMHO HTML & CSS _are_ the easy to use cross-platform GUI platform. Nothing else stuck--flash, java swing, qt, etc. were all super capable and promising but failed to gain mass usage. HTML & CSS is the way. Nothing in existence has as much capability, developer usage and talent pool, accessibility and internationalization features, etc. A good GUI system is much more than just getting boxes and text on the screen.

Re: Tauri: An Electron alternative written in Rust

#140

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…

It didn’t take long, this approach was around years before Electron came in. But the reason Electron picked up is precisely the stable APIs with cross-platform compatibility that comes from bundling chromium. You won’t get that here.
Post reply on HN