[HN Gopher] Experimental Tauri Verso Integration
___________________________________________________________________
Experimental Tauri Verso Integration
Author : stareatgoats
Score : 121 points
Date : 2025-03-29 20:30 UTC (3 days ago)
(HTM) web link (v2.tauri.app)
(TXT) w3m dump (v2.tauri.app)
| m00dy wrote:
| 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
| robertlagrant wrote:
| 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.
| usrusr wrote:
| 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.
| usrusr wrote:
| (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.
| dqv wrote:
| 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.
| jonstewart wrote:
| The potential demerit is: how compliant is Verso compared to
| Chromium and Safari?
| wongarsu wrote:
| 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
| klabb3 wrote:
| 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.
| echelon wrote:
| For me the biggest selling point is being able to write
| application backend logic in Rust. That's a big win.
| shubhamjain wrote:
| 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?
| detaro wrote:
| For one thing, not all OSes _have_ a "native WebView".
| klabb3 wrote:
| 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?
| dqv wrote:
| Optionally bundling would help in situations where the OS's
| native webview has degraded performance
| https://github.com/tauri-apps/wry/issues/1064
| dist-epoch wrote:
| > 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.
| synergy20 wrote:
| well,what about memory usage. storage is cheap indeed, but
| memory is limited still
| dist-epoch wrote:
| 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.
| Fraterkes wrote:
| 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
| kbelder wrote:
| 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.
| pornel wrote:
| 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.
| wongarsu wrote:
| 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
| yusefnapora wrote:
| 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.
| laerus wrote:
| consistency between platforms
| _bin_ wrote:
| 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.
| Fraterkes wrote:
| 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
| mentalgear wrote:
| > 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.
| madeofpalk wrote:
| 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?
| pornel wrote:
| On Linux you get WebKitGTK, which is more of a gamble than
| browser versions of Chromium or Gecko.
| hiccuphippo wrote:
| I guess it's "your choice" vs "the user's choice". When
| it's the user's choice they can't complain to you.
| marcosdumay wrote:
| 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.
| Tsarp wrote:
| 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.
| mrec wrote:
| Was this someone on the Tauri team, or just third-party
| speculation?
| jonstewart wrote:
| 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.
| ic3man5 wrote:
| 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.
| jonstewart wrote:
| 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.
| andyferris wrote:
| 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.
| synergy20 wrote:
| https://webui.me/ is a different approach
| zachrip wrote:
| 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.
| dcow wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-01 23:01 UTC)