Live data from Hacker News

Tauri: An Electron alternative written in Rust

tauri.studio

331–340 of 438 posts

Re: Tauri: An Electron alternative written in Rust

#331
post #83

Earlier quoted context omitted.

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 weird to want nice things" is the sort of attitude that means you might have been a web developer for too long :)

Not at all. Being a web developer I'm all for working towards fixing these problems. I could have communicated that better :p

Re: Tauri: An Electron alternative written in Rust

#332
post #255

Earlier quoted context omitted.

> Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps. I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business…

Electron exists because there's a horde of developers whose only tool is a JavaScript hammer, so every problem looks like a nail. That's how you end up rewriting `dd` for Chrome[π]. π: https://www.balena.io/etcher/

My god... a 200+ MB install footprint, 200+ MB of RAM usage, requires a beefy GPU just to render its window. How did we get here?

Re: Tauri: An Electron alternative written in Rust

#333

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…

Webviews don't work because they solve very different problems. System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future. You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like c…

If you cared about performance, would you really be using Electron?

Re: Tauri: An Electron alternative written in Rust

#334

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…

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

Which is why many many people tried this approach long before Electron came along. Electron has been successful largely because it deviated from this: it swallowed the bitter pill of bundling the heavy duplicated webview in order to ensure a consistent development target.

Re: Tauri: An Electron alternative written in Rust

#335
post #96
post #77

Earlier quoted context omitted.

This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers. On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?

Because then you'll get a more efficient app that people don't constantly complain about? Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.

Especially on MacOS where Webkit usually behave differently? Like, why would webkit still require webkit prefix for Web Audio API, which is like 8 years old at this point.

To me, develop for Electron is more fun than normal web because I don't have to check whether the new web feature I am using is available everywhere (especially Safari) yet.

Re: Tauri: An Electron alternative written in Rust

#336

Earlier quoted context omitted.

Webviews don't work because they solve very different problems. System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future. You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like c…

If you cared about performance, would you really be using Electron?

Yes. Why not? HTML/CSS great (from the development POV) for UI, and I can always write the performance critical code in C and linked them to the electron HTML/CSS frontend.

Re: Tauri: An Electron alternative written in Rust

#337

Earlier quoted context omitted.

I think the project is great and I admire your work, but I'm confused about how you position it. Being "almost" web compatible is not a recipe for success, as it's bound to cause confusion and frustration among folks that want it to be an Electron alternative. Either embrace Web APIs entirely (perhaps a smaller compatible subset), or just position it as something else entirely, like Flutter.

"how you position it" Hmm... and how do I do that? What's your impression? Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and that's it. Yes, it is possible to use it without touching native side like ElectronJS, see: https://quark.sciter.com/ , but that's not the primary use case. So far it has around 400 mln installations in embedded form as part of other products, see: https://sciter.com/#customers If you want…

I think your description is technically correct, it is an UI engine that uses the HTML, CSS and JS languages.

But to most folks, that sounds like a "web browser/view engine", which it is not. Does it pass the Acid2 / Acid3 test?

The power of ElectronJS is not its use of HTML, CSS and JS, but the fact that it is a web browser engine and one can share the millions of frameworks, libraries and muscle memory built for the web in their desktop applications.

Re: Tauri: An Electron alternative written in Rust

#338

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…

"is this impossible?" Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk 10 times more compact than Tauri, 20 times less than Electron.JS Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :) And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/

That’s awesome, I’m gonna play with it over the weekend. Thanks!

Re: Tauri: An Electron alternative written in Rust

#339

Earlier quoted context omitted.

> 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 Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem…

> Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome. I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well. https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...…

Safari is huge. Doing Chrome only is suicide. Thankfully, cross browser compatibility is much easier these days, specially if you don’t use flex or grid.

Re: Tauri: An Electron alternative written in Rust

#340

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…

"is this impossible?" Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk 10 times more compact than Tauri, 20 times less than Electron.JS Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :) And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/

sciter is a really wonderful piece of software. it's performance has been really impressive when I was benching it against qt
Post reply on HN