Tauri: An Electron alternative written in Rust • Hacker News Board

Re: Tauri: An Electron alternative written in Rust

#31

Post by brundolf » Fri, Feb 19, 2021, 5:55 PM UTC

vlovich123 wrote: post #23

brundolf wrote: post #12

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…

Well Windows is basically Chrome so your diversity will basically be Chrome & WebKit which is what you have anyway. And having all the fun of web development against multiple browsers with all the headaches of desktop distribution is kind of the worst of all worlds. It'll be interesting to see if this approach finds success (since it may cut down on the size of your binary) but it could easily get abandoned if any si…

> so your diversity will basically be Chrome & WebKit which is what you have anyway

Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome.

If web apps that are complex enough to warrant a desktop app are forced to support Safari, that lifts awareness for the entire web/JS ecosystem. That's a win, if it plays out that way.

> having all the fun of web development against multiple browsers

The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel.

Re: Tauri: An Electron alternative written in Rust

#32

Post by kall » Fri, Feb 19, 2021, 5:55 PM UTC

twarge wrote: post #7

Downloaded the demo app for macOS; feels like an alien UI even though effort was clearly made to use system widgets. On the positive side, the app is only 4 MB and consumes 50 MB at runtime, so at least they've succeeded in that important aspect.

I think most companies that already decided on the electron UX vs dev effort tradeoff will happily trade user resources for a guaranteed, uniform browser version target. It makes a big difference in development and testing.

Re: Tauri: An Electron alternative written in Rust

#33

Post by smasher164 » Fri, Feb 19, 2021, 5:57 PM UTC

Tuna-Fish wrote: post #24

hobofan wrote: post #14

The Electron alternative that possibly isn't one. Electron apps are usually quite heavy because they bundle Chrome. Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.

> Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it. Isn't windows system webview now a chromium fork? This should make incompatibility on the major platforms now much less of an issue.

People act as if they haven’t dealt browser incompatibilities in the past. Just feature-detect/polyfill and move on.

Re: Tauri: An Electron alternative written in Rust

#34

Post by baxrob » Fri, Feb 19, 2021, 5:59 PM UTC

flixic wrote: post #21

hu3 wrote: post #20

Earlier quoted context omitted.

> I kind of wonder why it took this long for someone to try this approach. Perhaps a similar approach to https://github.com/webview/webview ? "Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"

Yes, Tauri's documentation explicitly states that it uses this Webview project.

Tauri has effectively controlled the Webview project for the past year. See https://github.com/webview/webview/issues/305

Re: Tauri: An Electron alternative written in Rust

#35

Post by mikewhy » Fri, Feb 19, 2021, 5:59 PM UTC

brundolf wrote: post #12

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.

As others have mentioned, this is not the first time someone has tried. As for why people might not go for it:

- Electron is Chrome. Webview is: Cocoa/WebKit, gtk-webkit2, and Edge (or is that Edge and Edge/Chrome). Yes standards have progressed a ton but there's still inconsistencies and it's nice not having to worry about them.

- Electron is JS, so your app is 100% in a single language. In Webview. With these alternatives you now have to use 2 languages. Not the end of the world, but again, nice not having to deal with.

Re: Tauri: An Electron alternative written in Rust

#36

Post by lilactown » Fri, Feb 19, 2021, 6:00 PM UTC

dsizzle wrote: post #25

andai wrote: post #18

Earlier quoted context omitted.

I heard about a similar project a few months ago but I can't recall the name. I think the downside is that each OS has its own idiosyncratic webview.

Revery? https://github.com/revery-ui/revery

AFAIK Revery doesn't use webviews, it is based on Skia

Re: Tauri: An Electron alternative written in Rust

#37

Post by mch82 » Fri, Feb 19, 2021, 6:00 PM UTC

> Today, Tauri uses Rust for the backend - but in the not too distant future, other backends like Go, Nim, Python, Csharp etc. will be possible. This is because we are maintaining the official Rust bindings to the webview organisation and plan to let you switch out the backend for your needs. Since our API can be implemented in any language with C interop, full compliance is only a PR away.

Sounds promising. I’d love a web view front end for Python as an alternative to tkinter.

Re: Tauri: An Electron alternative written in Rust

#38

Post by fabiospampinato » Fri, Feb 19, 2021, 6:01 PM UTC

pachico wrote: post #19

hctaw wrote: 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…

I understand your point, however I still think it's unacceptable to have 1-1.5 GB of RAM consumed by simply two Electron applications running idle.

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.

Re: Tauri: An Electron alternative written in Rust

#39

Post by swagonomixxx » Fri, Feb 19, 2021, 6:01 PM UTC

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 simpler - it trades of performance for uniformity of experience across the major platforms.

But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).

Re: Tauri: An Electron alternative written in Rust

#40

Post by hctaw » Fri, Feb 19, 2021, 6:01 PM UTC

gameswithgo wrote: post #17

hctaw wrote: 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.

I didn't say I was shipping GUI software ;)