Tauri Mobile Alpha Release
tauri.app
tauri.app
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.
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?
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.
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.
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.
There is. It's called hosting it on the web.
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.
// POST localhost:3344
{
action: 'create-window',
settings: { title: "Hello World" },
content: [{ tag: "Text", value: "Hello World" }]
}
// returns 200 { id: "xxx", "auth": "xxx" }
// POST localhost:3344
{
action: 'update-window',
id: "xxx", auth: "xxx",
exec: { content: {
$findOneAndUpdate: { query: { tag: "Text" }, set: { value: "updated"}}}
}
}
(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.
I'd love to add other languages, but currently so busy with a top-notch Python support!
If they manage to pull this off then bravo to them.
I’v been using Flutter for a couple of months now and It’s incredible if you want to build to all platforms with a single codebase.
You can do all this in a single code base:
- SPAs (Single Page App)
- SSR (Server-side Rendered App) (+ optional PWA client takeover)
- PWAs (Progressive Web App)
- BEX (Browser Extension)
- Mobile Apps (Android, iOS, …) through Cordova or Capacitor
- Multi-platform Desktop Apps (using Electron)
*war flashbacks*
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.
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.
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.
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.
Ironically, having a team specialize on mobile is a great way to catch this kind of problem.
https://github.com/tauri-apps/tauri/issues/4415
TBF I wouldn't bother with the Mac AppStore if there was a simple way of distributing paid versions of the desktop app without much coding involved.
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.
(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.
1: https://sergixdev.notion.site/Tauri-Documentation-b695823f0b...
https://en.wikipedia.org/wiki/Scuderia_AlphaTauri
was scratching my head for a second, finally got it :)
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.
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.
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?
> Build an optimized, secure, and frontend-independent application for multi-platform deployment.
Sounds great. Still no idea what this Tauri is.
Definitely keeping an eye on this.
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.
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.
[1]: https://tauri.app
If we are talking about language then it is more like: "Neutralino, but rust".