Experimental Tauri Verso Integration | Hacker News Reader

Experimental Tauri Verso Integration

v2.tauri.app

143 pointsstareatgoats45 comments

I’m a bit confused. I thought the main selling point of Tauri was that it uses the OS’s native WebView to create lighter apps compared to something like Electron. So why would I want to bundle a Servo or Verso? Doesn't that defeat the purpose of Tauri?

For one thing, not all OSes have a "native WebView".

In practice, it’s only Linux that is distro dependent out of the big ones, but most package managers have some WebKit gtk package to hook into afaik.

In theory yes you could go outside Linux as well, like maybe bsd? Or which ones are you thinking of?

Optionally bundling would help in situations where the OS's native webview has degraded performance https://github.com/tauri-apps/wry/issues/1064

Yeah I opened this issue and still stand by the problems. We actually switched to electron since then because of the horrible performances on Linux.

> I thought the main selling point of Tauri was that it uses the OS’s native WebView to create lighter apps compared to something like Electron

It was a talking point for angry at clouds people.

It was never a selling point, because nobody cares how big apps are today. For a regular user with a 256/512 GB drive, even if they had 50 electron apps 1 GB each, it would not matter in the grand scheme of things.

well,what about memory usage. storage is cheap indeed, but memory is limited still

From the 1 GB a typical Electron app uses, only about 300 MB are binaries which might be shared if they were a WebView.

So yes, using a WebView might decrease your memory usage by 30%, maybe 50% for small apps. Not a huge game changer, maybe it would make a 8 GB RAM laptop more usable.

You talk like that's not a big deal! What percentage of users do you think still spends a lot of time working on 8gb ram laptops? If it was more than 50% I wouldn't be surprised.

The lowest hanging fruit when it comes to societal good that you can do as a programmer is writing software that is also usable for people with less money for hardware. And a lot of us don't even bother

The big gain is from replacing a 1 GB Electron app with a 50 MB native app. Tauri is an improvement, but not a transformative one.

Tauri is an application framework. If you want to use Rust for your application, there's going to be one more option for rendering its UI.

This does make it closer to Electron. We'll see whether Servo can be made leaner or faster (Servo is focused on GPU-based rendering).

Long term, I dream, there could be tighter integration between Tauri and Servo's DOM, so that UI changes won't have to go through JavaScript.

Because its main selling point isn't its only selling point. At $work we use Tauri because of the great Rust<->JavaScript API it offers. We wanted an Electron-like JS Frontend that could seamlessly use our existing IPC to talk to a long-running service, as well as being able to offload heavy work to native code. Tauri fits that beautifully.

For our use case don't care too much about the kind of webview it uses and would be fine with shipping a larger binary. Servo integration could be interesting to have one known webview to target if cross-platform consistency ever becomes a challenge

I think it makes sense if you think of Tauri as a "view layer" for rust apps. If you're building a rust GUI app using something like Dioxus, I could easily see wanting to bundle a cross-platform renderer with consistent "quirks", vs having to adapt your frontend to work with all the platform web views.

It has trade offs in terms of memory usage and binary size, but Electron has already conditioned users to expect every todo and chat app to be 500mb on disk and use a gigabyte of ram at idle. In other words, if Electron would make sense for your project, but you want to use rust, this seems like a good fit.

consistency between platforms

At some theoretical future time bundling servo doesn't necessarily imply a render process of Rust Tauri UI -> JS -> DOM -> render. It's theoretically possible to cut out the JS step, at which point you'd just be focusing on DOM as a well-supported intermediary between Rust and a very well-tested DOM renderer. In theory.

For those who don’t know, Tauri is a lightweight electron alternative which doesn’t bundle browser nor a nodejs-like runtime.

To me piggybacking on the system webview is the main selling point. Tauri-made bundles usually clock in at a few MBs, compared to 100+ with electron.

For me the biggest selling point is being able to write application backend logic in Rust. That's a big win.

It's a great, easily-approachable framework too. I'd just recently picked it up for a pet project, and taking advantage today's powerful system webviews as UI frameworks seems like the obvious choice.

Also check out Wails if you'd like something along these lines with Go substituted for Rust

I am by background a C++ developer, not a web developer, but Tauri has intrigued me as a cross-platform app framework.

The things that have been frustrating are the documentation, the variety of options (pick a front end framework, pick a build tool), and the sense of being on your own once you get Hello, World! working. I wish there were more examples with using 1+ different Rust web service frameworks, how to manage state, and so on. It has the feel of an older-style open source project where the developers are in love with offering options rather than committing to a strong developer experience.

It's because you aren't a web developer. I faced the same problems. Go make a web app with deno or node and you'll get the same feeling.

The allure for me of Tauri is the combination of creating simple portable apps, maybe one day being able to get a frontend JS developer to improve UI/UX, using Rust on the backend (with the ability to bundle in other native libraries), and leaning more heavily on cargo than on the godawfulness of JS-flavor-of-the-minute build tool.

I can vibe-code up some basic UI but it all feels a bit precarious.

It's possible I don't know what I'm talking about, but I believe Dioxus is also targetting cross-platform app development and might be a reasonable fit for you. Here the frontend is written in Rust in their provided UI framework (designed with concepts from the web DOM and learnings from existing web frameworks) and it might be a more familiar approach to a C++ dev who has used Qt or whatever before.

I understand it also has experimental support (possibly still under development?) for a servo/verso render engine, which is why I mention it.

Sounds weird at first glance, as in throwing away the key USP servo brings to the table relative to the "browser bundled" alternatives like Electron. But if it can (one day) serve as plan B to counter platform webview uncertainty, it might actually be a powerful boost to tauri adoption. Even when it is hardly ever used.

Reminds me a little of the topic of range anxiety in BEV adoption: verso integration might be the hypothetical range extender trailer whose existence could help BEV adoption even if it was hardly ever used.

(OT, about hypothetical BEV rx trailers, moved to a self-replay to make it a little less bad): is this already a thing for caravan trailers? An oversized generator for off-grid camping paired with some battery for load smoothing and a downlink to the car so that it does not require the enormous capacity that would be needed to solve that once-per-year worst case outlier as a BEV. Might even be modular, like a pickup truck, a "power trailer" for adding both range and cargo bed to a car tailored for transporting humans.

For me it's https://github.com/tauri-apps/tauri/issues/3988

Even if it has to be bundled, having the equivalent performance accross OSes is big. Tauri is definitely piquing my interest again because of this.

The potential demerit is: how compliant is Verso compared to Chromium and Safari?

Not compliant enough to browse the open web without experiencing glitches, but compliant enough for your own frontend code that you test against Verso/Servo.

I imagine most users will continue using Tauri with native webviews. But if consistency between different webviews ever becomes an issue you now have the option to ship a Verso webview to have more cross-platform consistency

A while ago I saw someone mention that Tauri would soon also just include Chromium, because in practice using a native webview loses a lot of the ostensible portability of a browser-in-a-desktop app (they claimed native webviews can differ a lot between OS's). Maybe that was overly pessimistic

> because in practice using a native webview loses a lot of the ostensible portability of a browser-in-a-desktop app (they claimed native webviews can differ a lot between OS's)

OS Webview fragmentation was my concern from the beginning, but got pretty much shushed away by tauri proponents. Funny how after years they also came to the same conclusion that a webview running on win8 and one on linux do not necessarily render/behave the same, and the amount of bugfixes/normalisation one would have to include is just to vast.

Still it might make sense if you exactly know the OS distribution of your user base.

Is there something specific to the browser-in-a-desktop app domain that's different from normal frontend web development, where you have to support a variety of different browsers? How is it any different for Tauri?

On Linux you get WebKitGTK, which is more of a gamble than browser versions of Chromium or Gecko.

I guess it's "your choice" vs "the user's choice". When it's the user's choice they can't complain to you.

The different bit is that if you decide to include an entire engine with your app, you don't need to support a variety of different browsers.

Most people that go into browser-in-a-desktop app want to also provide a web app, so the difference is moot. But there are certainly a few people for whom it applies.

For a lot of basic applications that do not need a lot of the extended browser APIs, Tauri is an amazing option. Consistency isn't really required in a lot of use cases. You just want things to work, you have a small team and Tauri works perfectly.

Some Linux distributions still dont work smoothly. If you could optionally choose to bundle verso just there I think its a great cross platform option.

Was this someone on the Tauri team, or just third-party speculation?

Probably you saw my rant. We are small team, rust shop and we shipped Tauri for a couple years to more than 20k users. Our application is complex and we had a lot of unpleasant debugging to do due to differences in native webviews. Linux performance was just plain bad. We switched to electron, far from ideal but overall the right decision for us at least until Tauri allows bundling of a stable browser.

I wonder if this will result in a reconsideration of the runtime abstraction boundary itself. Right now the runtime umbrella also includes the way you build native menus and work with the system tray. So if you wanted to swap out runtimes, there's a fair chance it isn't trivial because you have Menu<Wry> in various places. The other option is to make all your code generic on runtime like tauri's but that's confusing and cumbersome in my experience because all your code has to become generic with constraints that are not documented or explained anywhere (essentially library implementation details). Would be nice to see a "web render runtime" and a separate "native UI runtime", or see the menu system abstraction revamped.

Does verso/servo offer a way to get a raw framebuffer? I'm working on a project where I am currently using cef but I would love to go full rust.

Is there a mobile story for Tauri? Can you port the rust backend to android or iOS? Since this uses the system web view does this make mobile possible?

Apparently, yes, there is movement here:

https://github.com/tauri-apps/tauri/discussions?discussions_...

https://webui.me/ is a different approach

This looks far superior or what am I missing?

it's a hidden gem in my opinion, I just started using it to build projects

This is exactly the kind of innovation we love to see in the Tauri ecosystem! At Cycletop, we’re building an AI driven algorithmic trading platform, and our frontend runs on Tauri. The idea of using Verso instead of Wry? Super intriguing.

Trading UIs demand snappy performance, and a rust powered rendering engine like Servo could mean faster DOM updates, better security, and lower resource usage

I'm just curious, has anyone benchmarked Verso’s rendering speed vs. Wry? And how’s the webrtc support looking? Low latency comms are a must for us.

Excited to see where this goes!

[0]: https://cycletop.xyz

Just FYI one of the developers is looking for a job where they can work full time on Tauri. If it's a big part of your world, it might be worth getting in touch.

Reply on news.ycombinator.com