Experimental Tauri Verso Integration

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 those who don’t know, Tauri is a lightweight electron alternative which doesn’t bundle browser nor a nodejs-like runtime.<p>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.

I am by background a C++ developer, not a web developer, but Tauri has intrigued me as a cross-platform app framework.<p>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.

Sounds weird at first glance, as in throwing away the key USP servo brings to the table relative to the &quot;browser bundled&quot; 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.<p>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.

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&#x27;s). Maybe that was overly pessimistic

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&#x27;s a fair chance it isn&#x27;t trivial because you have Menu&lt;Wry&gt; in various places. The other option is to make all your code generic on runtime like tauri&#x27;s but that&#x27;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 &quot;web render runtime&quot; and a separate &quot;native UI runtime&quot;, or see the menu system abstraction revamped.

Does verso&#x2F;servo offer a way to get a raw framebuffer? I&#x27;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?

<a href="https:&#x2F;&#x2F;webui.me&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webui.me&#x2F;</a> is a different approach

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.<p>Trading UIs demand snappy performance, and a rust powered rendering engine like Servo could mean faster DOM updates, better security, and lower resource usage<p>I&#x27;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.<p>Excited to see where this goes!<p>[0]: <a href="https:&#x2F;&#x2F;cycletop.xyz" rel="nofollow">https:&#x2F;&#x2F;cycletop.xyz</a>