I’ve enjoyed working with Tauri a lot, and I’m excited to check out the mobile release. I’ve been using it for about a year now, paired with Svelte, to build a video editor [0] and it’s been really nice speed-wise. I haven’t felt like Tauri is the bottleneck in probably 99% of cases (usually it ends up being my own code!).
One area they could improve, and I think they’re working on for 2.0, is the IPC mechanism between JS and Rust. It’s not as fast as a true function call and bogs down if you try to send large amounts of data over it, so I’ve tried to architect around it. It’s been fine but I’m looking forward to when it’s more efficient.
It still lacks some features that Electron has too, and it feels a little bleeding edge sometimes. But I feel a lot better with shipping a lighter app that’s closer to native-size. If the alternative is maintaining 2 codebases in different languages as a solo developer, I’ll gladly take the tradeoff to go with Tauri, whereas Electron felt like a much bigger gap.
> But I feel a lot better with shipping a lighter app that’s closer to native-size.
Out of curiosity: How much time (if any) have you spent addressing differences in OS web renderers? Is not supporting Linux a business or technical decision?
I hit a few bugs on older Safari (like, macOS 10.14) that I had to work around but otherwise it’s been pretty good.
Linux should be technically possible, but it’s a combination of the two that’s made it a lower priority so far. I’m a bit worried about the potential support burden, given how widely systems vary. But it’s on my list of things to look into, at least to try getting it running.
What I’ve been missing in tauri is being able to manipulate the window title bar similar to firefox or vscode (electron actually allows this).
Anyway, regarding your IPC bottleneck: I found it faster to spawn a local websocket server in rust and let my vue app connect to it. It’s really ugly and I hate myself for working like this, but albeit the tcp overhead it is actually faster for transferring bigger amounts of data than IPC.
Ah yeah, I miss the title bar access too. I had a “# days remaining” button there in the first version of the app when it was native to Mac and went with something less slick this time. The nice thing about Tauri is the native access if you need it, and I think this is probably possible because you can get a handle to the native window, and call native Mac APIs to e.g. access the title bar view and add subviews to it. (of course the downside is having to adapt that code to every platform)
My workaround for the IPC stuff was to just avoid sending binary data at all. I originally wanted to send video frames but it was pretty quickly clear that would not work well at all. So I just send commands, and serialize the timeline back and forth, and do the video on a native layer.
This is a huge reason to go with Tauri over Electron. I don't get why there isn't (or is there) a simple way to package a web app for all platforms. Everyone still makes this weird artificial distinction between Desktop and Mobile despite the technical capabilities and user expectations being close to the same.
I wonder about that. Electron is mature. Well supported. Well documented. Predictable on desktop on account of using a known rendering engine. When it comes to having a mobile app as well, I look to obsidian for inspiration on possible approach since they built a non trivial app with a relatively tiny team. Their stack includes electron for the desktop and they re-used most (All?) of the core with capacitor for mobile. This included theming and plugins. Would be hard to bet against a stack that has that kind of real world success story behind it.
which is still very limited when you need low-level/native access on the platforms, mobile phones especially iphones are very much a locked-in device as much as they can get away with it, android is better though.
People won't for precisely the same reason Electron became so popular: managing multiple platforms is tiresome. Write once, run everywhere is still the dream.
I'd love to see a GUI engine that is inspired by web technologies but allows you to write your application in any language/shell scripts and have it construct native UIs.
I've been toying with building a GUI-as-a-DB kind of engine where consumers run a server process that listens for commands that tell it to create/update a window & its elements. You would interact with a DOM-like structure that maps to the various native UIs. (there is also a "guidb-lite" for including with your binary)
The general idea is; you issue nosql-like commands to this service to interact with the non-web DOM you create. e.g.
(I tried SQL but dealing with children nodes doesn't work out well)
This means your application can be written in whatever language you want. "Frameworks" (like React) would be written on top of this as language-specific implementations - allowing the GUI-DB to focus on only mapping the API to the various native GUI UIs.
I can imagine there would be limitations I am naive to and I'm generally not smart enough to see this through, but it is the change I would like to see in the world.
Hey, this is exactly how https://flet.dev works! :) There's a UI server written in Go, you write your program in Python which manipulates a virtual DOM with commands via WebSockets, and there's a Flutter client that renders UI from that DOM: https://flet.dev/blog#current-flet-architecture
I'd love to add other languages, but currently so busy with a top-notch Python support!
Fyne.io supports many use cases on these platforms (+web?) with Go. It would be interesting to build a web UI toolkit on top of it, but I think they've chosen not to.
You don't need it, the documentation isn't very good, but I have found that you don't need the http client lib as there is a http plugin that automatically patches the fetch function.
capacitor had it's own http client plugin for awhile, and now capacitor 4.0 has one built in and can even patch fetch and xmlhttprequest so you can use any regular js lib that relies on either.
Flutter Web exists. While it's not quite a JS framework (technically Dart compiles to JS but that's not what usually people mean), its web support is passable.
The Tuauri team needs to focus on maturing its primary codebase and documentation before branching out to assign teams to separate projects like this. I've written a few hundred lines of code using Tauri, and I've had to do much more API wrangling and searching the official Discord than I would have liked -- a lot of valuable API details are tucked away in very specific places, especially related to using Tauri's state manager, creating mockup tests, and technical information on the IPC model. In addition, some of those APIs are obtuse and confusing to interpret how to use.
Tauri does a few things very well, and its frontend model is much more lightweight and flexible than Electron's. However, the project has a long way to go before it's used in the mainstream and really needs to continue to make testing, debugging, and other DX details much more accessible and clear to gain an edge in the market.
I agree with this. We are shipping our app Caido with Tauri and it is missing quite a lot in feature parity with electron. We always lose time to try to bypass limitations or work around bugs. I honestly can't recommend it for production at this moment, even if it is getting better.
Some of the challenges we faced in the last week: no built-in api for single instances (so basically making sure the app is only run once), no support for the task bar menu (right click on the app icon), a fair amount of APIs are platform specific so you need a lot of conditional compilation trickery to make it work, etc.
On top of that you have platform webview issues that are hard to reproduce sometimes since you need the user specific OS version and packages. If you care about uniformity of your UX and speed of development stick with electron.
> uniformity of your UX and speed of development stick with electron
This is what keeps me from adopting Tauri. I'm following the project with great interest, but I have zero desire to step back in time to wrestle per-platform rendering issues. Big fan of the progression, but it's not quite there yet.
If you care about your user's machines or being able to do anything other than use your app on their machine then please use the platform's tooling and not things like electron.
+10000 I really enjoyed working with Tauri, but had to drop it because after a few days of porting my app to it, I released that it doesn't support AppStore distribution (i.e. creating properly signed .pkg files). This wasn't clear in the docs, and the videos I watched implied the opposite.
The team is doing amazing work and I don't blame them for this, it's perfectly normal for things to slip.
I'm excited about Tauri partially because (in my specific use case) even if I build for Mac only, the UX I can deliver with it will be much better with a hybrid app than SwiftUI [1].
The lesson here is that if you're planning to work with Tauri and Mac, you might want to focus on testing the entire pipeline (design, develop, distribute) first, and then, once you can push to TestFlight, pushing and testing features. Again, YMMV.
[1] Weirdly enough, there's almost no way for me to build a native app that will beat the performance of an optimised web app. Again, my use case is very specific (a niche text editor), but I find it hilarious given how much sh*t web apps get on HN.
Conveyor solves out-of-store distribution and update (albeit, it's not been tested with Tauri specifically yet). You can then have the app check for a license on startup. Stripe integration isn't a lot of coding and the financial overheads are lower than with the app store.
Thanks, but I could probably save time by just using Stripe with the existing Tauri app. Tauri already supports notarised apps, auto-updaters etc... What it doesn't support is generating a properly signed .pkg file.
(this can be done using regular shell script, in my case there is, however, some weird, hard to debug issue with AppStore validation)
The missing bit is making the app paid, which normally should be trivial with the AppStore.
For any specific details that anyone may be curious about, I have a public Notion page with some different documentation issues and the links to their respective sources. [1]
Tauri is pretty cool stuff and great for simple single threaded apps. With all the make X model run on Y, I’d caution folks with multithreaded needs to wait until another release.
Mac’s multithreaded environment went just fine; and on task completion could be killed off. However the Windows version spun up fine, then hung, then wouldn’t shut down all the threads leaving odd state everywhere.
there are webview libraries from windows/linux/macos so electron.js-without-chromium works.
are there similar webview libraries from android and ios that you can link to as the desktop OS does? anyone knows what those libraries are?
I wish there is a c++ electron.js alternative, we now have tauri(rust) and wails(go), I'm using webview on github to use c++, just not as polished but it works well though.
There is a brand new one called Socket, it’s more targeted at web developers - no rust or anything required. Backend is also completely optional. It supports all mobile and desktop — it will ship a stable release next month: https://github.com/socketsupply/socket
New to me, had a quick check, Android is not yet supported, and it focuses on peer-to-peer(via bluetooth?). again using webview to do html-ui on desktops is feasible(tauri,wails,webview-c++), the interesting part is how to do that on mobile phone(without using flutter, or ionic)?
if you don't want to learn yet another new framework (flutter), or write native apps, the only option seems to be ionic, how is socket different, is the selling point here p2p instead of client-server otherwise it works just like ionic?
No, Android is fully supported, we’ve even built a demo for Android TV :D p2p is made possible by exposing UDP and Bluetooth as JS APIs (also supported on iOS and Android) but it’s entirely optional. Ionic uses electron for desktop, so you end up with two major frameworks mashed together. Socket was designed from the ground up for desktop and mobile.
The screenshots make it pretty clear that it's the latter. That's what Tauri is: an electron competitor that differentiates on a) using native WebViews to greatly reduce distribution size and b) using Rust as the backend to do all of the things that Rust does and none of the things that Node does.
It is 'website as app'. But it is possible to use native components (ie.: on Macos using FFI from Rust to call cocoa api.). However few people use it except for some toolbars.
Usually a beta is considered feature complete but not completely finished (expected bugs etc) while an alpha is not yet feature complete. An alpha version comes before a beta version
Congrats on the release! From the looks of it Capacitor[0] has quite a big lead on in terms of support for native APIs (secure storage, SSL pinning, biometrics, etc) but hopefully they'll catch up quickly and avoid some of the mistakes Capacitor has made.
Hi, I really like your app Mochi! The design is wonderful, intuitive and leagues ahead of anki. The app truly deserves more attention.
I noticed that the FAQ does not cover where data is stored on android, where is it?
Asking because I want to sync it's data between devices with Syncthing.
I'd like to support the app eventually I but can't right now. So I want to take the Obsidian approach of syncing the data myself, thank you.
The build process is very fragile for both Android and iOS. Basically, a patch version update of any of the capacitor libs or plugins has a pretty high chance of wrecking your build pipeline.
Also the ecosystem is not in the best shape; the quality of libraries is allover the place, lots of unmaintained ones or ones that only support older SDK versions of Android/iOS. Not sure it's entirely fair to blame CapacitorJS for this, but it's nonetheless the reality when developing Capacitor applications.
All-in-all Capacitor is pretty great though, definitely one of the most productive ways to develop high quality cross-mobile apps.
It's a link to a blog post announcing a release. The product page [1] is a bit more informative. The best 3 word summary probably is "Electron, but rust".
nor meant for you if you never heard of it - stop putting yourself in the centre of the universe - it's a blog post announcing a release branch of Tauri which is something similar to Electron
One area they could improve, and I think they’re working on for 2.0, is the IPC mechanism between JS and Rust. It’s not as fast as a true function call and bogs down if you try to send large amounts of data over it, so I’ve tried to architect around it. It’s been fine but I’m looking forward to when it’s more efficient.
It still lacks some features that Electron has too, and it feels a little bleeding edge sometimes. But I feel a lot better with shipping a lighter app that’s closer to native-size. If the alternative is maintaining 2 codebases in different languages as a solo developer, I’ll gladly take the tradeoff to go with Tauri, whereas Electron felt like a much bigger gap.
0: https://getrecut.com