Tauri Mobile – Develop Mobile Apps with JavaScript and Rust | Hacker News Reader

Tauri Mobile – Develop Mobile Apps with JavaScript and Rust

studioterabyte.nl

183 pointsstefanvdw183 comments

Just a Brief note about Tauri VS Electron. I've always been a opponent of Electron Apps. Even now, my Slack regularly pauses for seconds I suppose because the Garbage Collector has to do its thing.

Lately, however, I've worked on a Mastodon Client written in Dioxus (https://terhech.de/ebou/). Dioxus runs native Rust code and sends Dom Updates to a Tauri Webview. The difference in Ram and Performance is staggering. Much more lightweight because it uses the System Webview, and much faster because it's not Javascript. I've come to the conclusion that Electron itself is probably fast enough, but its the Javascript that causes it to crawl. (Obviously, my tiny app doesn't compare to Slack, but I've also done some simple-enough Electron Experiments).

And it makes sense: WebKit has seen tremendous amounts of investments to make it as fast as possible. CSS can do GPU based transforms, everything is heavily optimised. I'd venture that WebView rendering is just as fast as native (in the general case). What makes Electron slow is Javascript.

> but its the Javascript that causes it to crawl

If it's updating a web view then it needs to go through javascript. The fastest rust wasm frameworks are not faster than javascript by any meaningful amount.

This is actually wrong in this context. Rust is running natively here (so no WebAssembly), directly manipulating the DOM of the web view without having to go through JavaScript glue code.

How is Rust manipulating the DOM?

It uses IPC to give the WebView patches of what to do. There is a wee bit of JS there that parses the IPC and applies the patch to the DOM.

Here's the code: https://github.com/DioxusLabs/dioxus/tree/master/packages/in...

This explains how Dioxus also has a LiveView mode - that sounds exactly how LiveView works.

So is my parent wrong and my grandparent correct? Because that is what I thought as well. DOM mutations are still happening via JS, so while the business logic might be in Rust, the mutations are still bounded by the speed of JS.

DOM mutations still happen in JS, they are just send from native-rust code. It is exactly like a liveview with a local server + webview wrapper

I think this would be very situational even in the case of WASM. Without needing a garbage collector and using only a JS buffer for message handling and DOM updates, for a long running application, there might be performance gains that would be hard to directly measure. With simple examples, the JS will generally win handedly. But for more complex apps that use more / increasing memory and perform involved state manipulation, I’m willing to bet you’d see the favor slip.

This manifests as a snappier experience with less / no GC pauses and a clearer dev experience with a better separation between domains. Rust is just a better language to work with, so it has a certain future-proof quality to it that would pay dividends long term compared to JS in any case.

I noticed the Dioxus page about desktop support with Tauri mentioning that this won't allow access to any Web APIs, like WebGL or WebGPU. This made me wonder: Is it possible to embed a native view inside of the webview rendered by Tauri? To be precise, could we make use of the native wgpu crate to embed a 3D rendered scene inside Tauri?

Looks like someone attempted this last year, without any success unfortunately: https://github.com/dceddia/wgpu-tauri-experiment

Yeah that works, because you get access to the native window. I'm adding native macOS elements to the Ebou window, for example. I'm also adding native window effects. You could reasonably easy add a wgpu native view I guess. What's a bit more difficult would be to have it position correctly (because you'd need to know the locations of the html elements, and you can only query them via the `eval` js routine, but that would also work).

Did you benchmark? JavaScript is fat enough, from my experience DOM manipulations nd repaints are the issue.

My suggestion in general not specifically for you is to Profile the slow part of the app and find the problem.

From my experience with asm.js vs wasm vs native code, I bet it's not Javascript being slow, but specifically Slack.

Properly written Javascript running on V8 can be in the same ballpark as WASM and native code as long as you don't torture the GC.

Native code may give you more "optimization headroom" of course, especially with non-standard compiler extensions, but it's not "automatically" drastically faster than JS or WASM (without putting manual effort into optimization, but many of those optimizations would also benefit JS or WASM).

A good example here is looking at some of the framework benchmarks for frontend frameworks (e.g. https://krausest.github.io/js-framework-benchmark/current.ht...)

I find useful comparison points are usually React, Preact, and SolidJS: React is fairly slow, but it can do pretty much everything, Preact is React with a lot of parts ripped out to provide a more efficient, slimline version, and SolidJS completely changes the rendering model and is probably the upper limit on how efficient a front-end framework written in Javascript can be.

It's very interesting to compare those with Rust-based frameworks. The big noticeable difference is that all the Rust-based frameworks require significantly more memory, even than React, and ship a lot more total code. However, in terms of performance, they are ringed by Javascript frameworks: SolidJS is by far the fastest framework (although Dioxus is catching up in most areas), and React is by far the slowest.

Obviously a lot of this is to do with how they interact with the DOM. Javascript gets that for free, but Rust and other WASM-based frameworks have to go through a process boundary in order to read or write DOM values. When direct DOM access eventually comes, I suspect we'll see some pretty big changes in these results. But for now, it's pretty clear that the most important thing for optimisation purposes is your application's architecture, rather than the choice of language.

I think these results point to something frontend developers have known for years: JS is rarely the bottleneck. It's DOM/layout/paint that tends to be slow when something is slow. And that layer isn't changed by using Rust.

Slack cache mechanism is pretty weird. They keep a few GB of data as cache. I wonder if they've been using this persistently for years instead of creating a better caching mechanism.

Javascript is plenty fast if you are running a reasonable amount of it, as in: just enough to do what the user wanted. It's slow when you use the popular "DevEx" frameworks that recreate the entire world at the slightest change so that the developers don't need to think too hard.

Consider VS Code, software generally considered to be fast enough: every single interaction is handled by a dedicated, hand written, event handler which wherever possible directly modifies existing DOM nodes with the smallest amount of change possible.

This is miles from React. It's what SolidJS aims to do, but the state of the art here seems to be about equivalent to ASM vs Compiled C in 1980: an expert can get miles better performance by dropping down as far as possible in the stack themselves. Not to mention SolidJS forces you into their "lens" of JS, where variables are functions and functions are auto-invoked at the compilers will. And don't even think about refactoring an expression inside JSX to be outside of it or else you'll break all of reactivity. Unless you wrap it in another function, of course.

Even React, despite being much slower than SolidJS, etc is rarely the bottleneck. Slow JS apps tend to be doing stupid things like blocking UI updates on network requests or updating state in such a way that triggers repeated re-renders when only one is required.

> updating state in such a way that triggers repeated re-renders when only one is required

OTOH I read that and say it's precisely a React issue/bottleneck :)

I mean, I think that's kind of fair. It is an issue with React that this can happen. On the other hand, it's pretty much always possible to work around it within React without switching to another framework. So IMO if a team is shipping a React app with performance issues then that's on them.

I feel like lower level languages like Rust make it more obvious when you're doing something that isn't great for performance and often have a standard library that helps abstract away the details of doing things in a performant way.

Here is the trick for Electron junk, when they have the option to do so, use the Web app.

The backend is Rust, all the frontend and all whatever UI put on top of that WebView is JavaScript alright.

I do endorse moving from Electron to Tauri tho. I did it for one of my pet projects and I couldn't be happier.

Feels brilliant.

Not with Dioxus. Everything is Rust there. It uses IPC to communicate with the webview and tell it what to draw. It is actually a very smart design. In addition (because WebView is just a Renderer), you can replace WebView with Terminal UI or Native UI

While JS won’t match Rust for speed, you are likely experiencing WebKits general large performance advantage over Blink as well.

A JS dev who knows generally how to write performant apps can produce some very close to native feeling experiences in WebKit, it simply feels that fast.

Rust meanwhile is a terrible language for UI work. Just like you wouldn’t use assembly for game programming today, or even why you wouldn’t use JS for sensitive systems programming, you don’t use a static compiled, verbose, picky, slow compiling language for a domain that simply demands you have a totally different set of trade offs.

The nature of UI is this: you’re going to iterate a ton, change a ton, you need to be creative and willing to try and throw away experiments as fast as possible, you need the fastest possible feedback cycle between save and hot reload. Your problem space will never be as clear as systems programming. Because the output is visual that time diff between “hmm does this work” and “ok yes/no” needs to be as quick as possible, and you absolutely need to be able to go from idea to output in as quick a time as possible.

This is hugely a function of verbosity, elegance of the libraries and hot reload - JS absolutely crushes Rust along these axis. Meanwhile memory safety isn’t a big concern. But not just that, dynamic languages give you dev tools where you can inspect, edit and test changes and code at runtime and that’s the single biggest productivity boost you’ll find as a frontend dev. These are lessons learned over 20 years of developing for every UI platform under the sun.

The modern web stack is simply going to get you to production with a far higher quality of UI in way, way less time.

I could go on for a lot longer about this topic but suffice it to say: JS is an absolutely incredible language for fronted. It’s set of trade offs match the domain beautifully. I wish it was faster, but WebKit at this point is so much faster and less energy intensive than Blink that I’m extremely happy with app performance in it.

I think the jury is still out on whether rust is good or bad for UI. Once rust UI libraries are more mature we'll get a sense of it. There are some advantages of static typing, even for UI (see SwiftUI for example). I'll grant the pickiness of rust can be a challenge. Anyway give us some time to work on stuff.

Here's my effort: https://github.com/audulus/rui

SwiftUI looks nice and definitely is the right direction for a compiled UI language. But in practice is terribly hard to work with compared to most web frameworks. Terribly slow recompile, no HMR, miles worse dev tooling, no way to dynamically inspect and change things on the fly.

On the web I have my app fully running on one side, and my code on the other. I make a change, it shows. Even if it’s inside a deeply nested pane, with some stateful stuff going on. And if things go wrong, I open the console and I inspect everything, change things, run some code, and fix it.

I actually tried SwiftUI on my last app I was making for months before I gave up. It felt like going back to the stone ages.

And that’s Apple putting their full effort behind something with decades of UI stuff already in place!

Not to mention my files kept getting too big for the Swift syntax checker all the time, but I’m sure they can fix that.

>What makes Electron slow is Javascript.

This has been said as far back as when Slack engineers explained why they migrated away from system webviews to Electron here on HN.

I decided to use Tauri for the first time for a university project and it was absolutely painless to design a small and useful GUI application to programatically generate schematics for photolithography masks.

- Single lightweight binary install and executable (~6 MB), clean uninstall

- Automatic updates (digitally signed, uploaded to a small VM)

- Integrates nicely with SvelteKit and TailwindCSS

- The Rust backend was able to integrate with GTSDK over FFI. The cmake crate made C++ compilation and linking automatic as part of cargo build, provided that a C++ toolchain is available (no problems even on Windows).

- No scary toolchain setup with a load of licenses to review and accept (looking at you, Flutter. I'm a student, not a lawyer. Although perhaps this will also be a thing with Tauri + Android?)

For a small project, I can't recommend it enough. I wouldn't know where to start with a C# or Qt GUI application, especially if I wanted to make it cross-platform.

It'll be interesting to see if it gains any traction in the mobile space. Flutter is great and may be better optimised for certain rendering techniques, such as infinite lists, but sticking with web technologies is a very compelling advantage.

.NET MAUI is cross-platform and very easy to get started with, but would sacrifice a lot of performance to gain the convenience and simplicity of the development experience.

It's also no-go for Linux. Otherwise I would be all over it.

There is work being done to address desktop linux, but I agree that is one of the deficiencies.

https://github.com/jsuarezruiz/maui-linux/pull/37

The lack of a WASM target is another, although UNO project in the past provided such a target for MAUI's very closely-related predecessor (Xamarin.Forms).

https://platform.uno/xamarin-forms/

If you’re going to convince mobile developers to use Tauri, at least invest some time in showcasing a good enough example. How do the apps do navigation? How do they store data for offline usage? How about networking? How can I access camera or hardware features?

Tauri might be the bees knees and cross platform toolkits are cool but I’m not seeing anything worthwhile in this blogpost.

I think they'd consider that out of scope, which for me is a feature rather than a bug.

The project is really about providing the runtime, rather than batteries-included application framework as many mobile platforms provide. Perhaps they are targeting web/rust developers more than native mobile developers?

All the things you would like to see in an example have well-established ways of doing in a web application. Camera access is a good example, where the javascript way of doing is through navigator.getUserMedia(). I imagine it would be supported by Tauri where the underlying browser engine supports it. Tauri provides filesystem access as well, as you don't have that in a web page.

Been using Dart & Flutter. Kinda leaning towards using plain old HTML & CSS inside a webview instead of learning how to work with mobile-specific widgets. Neither won't beat pure-native but at least I'd be able to make a half-decent app fast with HTML & CSS. Tauri looks enticing from that perspective but idk how polished it is vs Flutter.

Oh I'm already using Rust in backend so that wouldn't be a big deal. Wonder how well you're able to do GPU / graphics stuff inside webview though? Is WebGPU supported?

You might want to consider React Native. That way you get native widgets but CSS-style layout so there's not too much to learn.

Tamagui also really makes targeting web or native really enjoyable.

Disclaimer: He built Tamagui.

I enjoyed your episode on React Native Radio!

I’d take a look at Capacitor. I’m biased because I created it but I think it’s fair to say it’s the leading platform for web tech on mobile at the moment.

I haven't checked it thoroughly but would be grateful if you can share. Can you create a single app for mobile, desktop and web in capacitor?

Here's the site: https://capacitorjs.com/

And yes, Capacitor apps can target all of those platforms from a single codebase. If you ever need help or have questions feel free to reach out to me on twitter (link in bio)!

Thanks for your kind offer :)

I'd look up some Capacitor apps and see if the UI performance with webview is good enough for you. From my experience it's not great on Android, but good on iOS. Meanwhile Flutter is the other way around, and given that iOS is a more important target...this might not be a terrible route to go.

I can't imagine it'll be quicker than Flutter development if you 1) don't have strict design requirements, 2) you're pretty much only targeting mobile, 3) you want something that looks good out of the box.

If you already have a webapp and mobile performance is acceptable, I'd consider just doing Capacitor and migrating to Tauri when the mobile ecosystem is in a good place.

Edit: Oh the ionic CEO already recommended it lol

> From my experience it's not great on Android, but good on iOS.

Huh, that always used to be case (back when the iPhone 4 was the latest model). I'm amazed Android devices haven't solved this yet given that even slow android devices must have faster CPUs than an iPhone 4. Perhaps it's a software issue rather than a hardware one...

https://github.com/ionic-team/capacitor/discussions/3899#dis...

Apparently it's an issue with Android's webview interaction with accessibility settings.

https://engineering.fb.com/2022/09/30/android/launching-a-ne...

Facebook ships their own webview implementation to solve a couple other webview issues, but that's not really a viable solution for everyone else

Sounds like a webview loading a Next.js application wrapped in a Rust binary targeting iOS?

For me, it always felt much more difficult to match the native ui behaviours in a web application that it defeats the time won. Especially, when you want to support both Android and iOS.

the main advantage vs other webview-wrappers is that technically your native code is crossplatform to Android/Windows/MacOS This is important for a few specific types of applications, for example, my app uses a custom network protocol and it would be nice if I coded it for only one platform while avoiding C++ linker hell in 4 different platforms

Might sound wild but network-order bytes are pretty platform agnostic.

Not sure, what you mean, but in a non-webview wrapper application everything but the UI code was already shared between platforms? At least in the apps that I worked on. State machines, fetching logic, app flows etc

I agree in so far that on mobile, tauri is hardly more than yet another webview based cross platform framework. Perhaps better than others, perhaps worse, who knows.

But on desktop, Tauri is a true gamechanger. Enabling apps to build on the system webview instead of shipping a full grown browser with each installation, that's huge. And now Tauri gets "also does mobile, when you need it", this will make it far more attractive. Not only for apps that might have a mobile use case, but also for developers whose skill investment in Tauri becomes a lot more useful if it can also get applied to mobile.

Is there a library/framework/toolkit/whatever to make native GUI Android apps in rust? That's what I'm missing. I'm not interested in creating a web app as an Android app. Tauri looks interesting but it's not for me. And that's fine, because there's a whole lot of people who would use it, I'm sure.

The problem is usually that all the Android APIs are designed for Java/Kotlin and extremely opinionated on top. Using those APIs from other languages is a royal PITA.

That's why webview apps are so popular in the first place, because you don't need to deal with the actual Android APIs.

I used an Android app called Automate (from llama labs) to add Android notifications and UI around a Rust binary compiled for Android https://github.com/barakplasma/israel-weather-rs#running-on-...

This is what we are looking for as well. We started using Kotlin Multi-platform (KMM) a little while ago thinking it would be nice to separate build native UI and shared components which drive our logic.

Unfortunately, it hasn't worked out that well for us. Devs aren't liking it, and finding that the shareability of code, particularly because of bluetooth, is making things more difficult than it needs to be.

> Note: This is based on the 2.0 Alpha version and the early version of the documentation. An updated version of the create-tauri-app utility is in development to make a number of the following steps easier.

CTA v3 was released a few hours ago: https://tauri.app/blog/2023/03/01/create-tauri-app-version-3...

I've said this a number of times but I'll repeat here. I'm new to web development and was completely overwhelmed by the choice of which framework I should learn. I wanted to develop a simple app that needed to run on mobile and desktop, maybe later as a webapp. I learned html/CSS and vanilla JavaScript in the end, but for my app dart/flutter. I gave up on the various frameworks, I still cant decide if one or the other is the one I should be learning, the risk of wasting my time on a soon to be dead framework isn't one I'm willing to take.

All that said, for the novice, why would I use this over dart/flutter, or even one of the huge amount of other JavaScript frameworks?

Tauri shines when you want to have your business logic written in rust, and/or your app bundled as a desktop application that renders using the platforms built-in browser (meaning, you can use a rust logic core with a web-based UI). For many (including me), this is a winning combination. Granted, you can embed rust in Flutter/Dart as well: https://cjycode.com/flutter_rust_bridge/index.html.

Effectively, Tauri is like Electron, but bundles the ability to call into Rust land (if you want/need that) and uses the operating system's browser instead of bundling one. The idea is that the apps in Tauri are a lot smaller in mb and use a lot less memory than Electron apps. The con is, of course, you now have to deal with rendering/runtime discrepancies between the different platform browsers. If you're fine with this, and especially if you want to embed rust in your app, go with Tauri. If you want an easier dev experience, don't need to bundle rust (you can but you'll be compiling/loading shared libs), and the bundle size and memory usage isn't a huge concern, go with Electron.

As far as Flutter vs Web tech, that's a whole different question. I've used Flutter here and there and liked it (although I hate Dart) but I really question its long-term staying power. I wonder about accessibility too...can anyone who is more familiar with Flutter way in? Google also has a fascination with killing projects, even ones where "they wouldn't possible kill that" so if you have the time/resources, I'd hedge my bets and learn web tech as well...even knowing vanilla JS/HTML/CSS can get you going pretty far.

So if you've made a bet on Flutter and put a lot into it, I'd say keep going...I wouldn't change everything just yet. But keep the options open and keep exploring too.

As far as web frameworks, I don't think you can go wrong picking one of React, Vue, or Svelte and really investing some time into learning it.

What is Tauri's advantages over Cordova?

Cordova failed the competition against React Native and Flutter.

Cordova assumes you'll write most of the app in JS.

Tauri is more like a framework/GUI toolkit for Rust apps.

I was looking at this list of apps that use Tauri and according to GitHub most of them are JS/TS-heavy code bases:

https://github.com/tauri-apps/awesome-tauri#apps

If it's a "better electron" (which I think it is, amongst other things) then it will certainly be used for a lot of "web technology only" apps. There are just so many of them, the other end of the spectrum "rust app with some ui built on html" is extremely rare compared to that.

My first contact with a tauri app is cinny desktop (matrix client) and it's an absolute joy to use. The project source is hardly more than a reference to the source of the web version and some configuration files that make a PWA manifest seem elaborate by comparison.

Cordova has been superseded by Capacitor for several years now. And web tech on mobile is still wildly popular and isn’t going anywhere. Capacitor and Tauri Mobile are still the only platforms that can offer the value prop of bringing new and existing standard web apps to native mobile, which web developers still very much want to do just like they do on desktop with Electron/Tauri.

Is the native SDK story with this that you'd be on the hunt for Rust libraries that invoke native mobile functionality? Not sure if there are any well-maintained bindings to those SDKs around, but could be wrong. There are plenty for desktop, but I haven't seen any high quality mobile OS bindings.

Otherwise I imagine you could use capacitor from JS? But I see no pitch for how this should be done so far.

Eh, it's still a web view at the end of the day, I'd rather use native, RN or Flutter, and with Flutter I can also use Rust via flutter_rust_bridge. That is in fact what I'm already doing currently with one of my apps.

the page doesn't provide a really good understanding of what the framework is : is it using native ui components ? which part is for the server, which is for the client, and what does the framework provides in terms of bindings between the two ? etc..

https://tauri.app/

it is a wrapper around underlying os webview, basically you load your apps js/page in that webview, if you want to do more native things then you can communicate with that app with ipc (probably tauri_sdk_thing that wraps that ipc )

kinda like electron but donot have to ship chromium browser so less ram usage/ binary size

also since it is a warapper around webview not a lib_chrome_libary like in electron so it has less control in some case otherwise pretty great idea

It's safe to assume this page assumes some prior knowledge of Tauri[0] and Vue[1], which would answer your question :)

[0] https://tauri.app [1] https://vuejs.org

It is something like Cordova?

In the sense that it's a thin wrapper around a basic web app, yeah. Although Cordova is/was aimed more at mobile developers specifically and things like Electron and Tauri generally sell themselves as desktop first.

The support for all is technically there for all three (and others, like Capacitor) but there's always a few caveats for each and they're rarely the same.

The fact that many independent cross-platform app frameworks build something around webview suggests there is a baby crying to be born here, but what exactly it will look like is not clear.

I'd be interested to know how the non-GUI part of the app would work. Things that are native to Android, like sending notifications, toast, or setting off alarm etc.?

What is the platform api story (kotlin/Swift ffi) for tauri mobile?

You could use Dioxus which is native Rust on Tauri (well, on Wry, but it shares a lot of the platform facilities)

https://dioxuslabs.com

I am not sure I understand. How do I call android/ios camera, gallery, permission etc APIs?

In that case, you'd see if there're native Rust libraries for this and do that. The Rust in Tauri is native, not compiled to WASM. You can access the whole platform.

That said, most of the things you mentioned (iOS camera, permissions) don't have any Rust library to work with. So then it is more work because you need to use the native api via FFI. So yeah, I kinda misunderstood your original question. Possible, yes, but by far not as easy as with other solutions that just allow you to write the required functionality with Swift or Kotlin

Flutter has way better support

Unless you care about accessibility, seems Flutter don't care too much about that, yet at least.

What do you mean about accessibility?

Reply on news.ycombinator.com