[HN Gopher] Tauri Mobile Alpha Release
___________________________________________________________________
Tauri Mobile Alpha Release
Author : sbt567
Score : 166 points
Date : 2022-12-10 10:22 UTC (12 hours ago)
(HTM) web link (tauri.app)
(TXT) w3m dump (tauri.app)
| swyx wrote:
| shipping at a great pace
| Pepe1vo wrote:
| 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.
|
| Definitely keeping an eye on this.
|
| [0] https://capacitorjs.com/
| AbuAssar wrote:
| what kind of mistakes did capacitor make?
| knubie wrote:
| That is because Capacitor is just a fork of Apache Cordova,
| which is quite mature and stable.
| synergy20 wrote:
| capacitor looks pretty good, what are those 'mistakes' you
| refer to
| Pepe1vo wrote:
| 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.
| dceddia wrote:
| 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.
|
| 0: https://getrecut.com
| mccorrinall wrote:
| 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.
| dceddia wrote:
| 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.
| CharlesW wrote:
| > _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?
| dceddia wrote:
| 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.
| MengerSponge wrote:
| I watch F1 and just learned about this lovely project, so it's
| surprisingly hard to parse "Tauri Mobile Alpha"... those words
| are in the wrong order!
| MuffinFlavored wrote:
| > Scuderia AlphaTauri
|
| https://en.wikipedia.org/wiki/Scuderia_AlphaTauri
|
| was scratching my head for a second, finally got it :)
| eps wrote:
| From their front page:
|
| > Build an optimized, secure, and frontend-independent
| application for multi-platform deployment.
|
| Sounds great. Still no idea what this Tauri is.
| aliqot wrote:
| Tauri's been a pleasure to work with.
| pie_flavor wrote:
| > TLS support has been moved behind a Cargo feature until we
| figure out how to cross compile OpenSSL on Windows.
|
| *war flashbacks*
| synergy20 wrote:
| 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.
| heapwolf wrote:
| 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
| synergy20 wrote:
| 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?
| heapwolf wrote:
| 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.
| bobajeff wrote:
| I've yet to see a Web UI toolkit/framework that works on all of
| the desktop (Windows, *Linux* and OSX) and Android and iOS.
|
| If they manage to pull this off then bravo to them.
| password4321 wrote:
| 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.
| hu3 wrote:
| Perhaps take a look at https://quasar.dev/introduction-to-
| quasar#what-is-quasar
|
| 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)
| synergy20 wrote:
| ionic with its capacitor.js is said to be the best option for
| now, not too sure about flutter but who knows when google will
| kill it.
| revskill wrote:
| The issue with capacitor and ionic is in legacy, outdated
| Cordova dependencies !
| johnny22 wrote:
| which ones do they still have now? I know a lot of folks
| still use third party cordova deps, but i didn't think
| capacitor did.
| revskill wrote:
| For example, i used the http client, but its Android
| version is just legacy, outdated :(. Not sure if it works
| with latest Android OS version.
| CharlesW wrote:
| Looking through their site, Capacitor doesn't appear to
| support desktop apps. Their docs recommend using Electron
| instead.
|
| https://capacitorjs.com/docs/main/deployment/desktop-app
| Alifatisk wrote:
| There has been lots of discussion about Flutter here and to
| my understanding, Flutter is far away from being killed.
|
| 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.
| satvikpendem wrote:
| Have you seen Flutter?
| AlexErrant wrote:
| What does "Alpha" mean here? As compared to Beta.
| looperhacks wrote:
| 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
| AlexErrant wrote:
| Ah, a simple search would've learned me. Thanks!
|
| https://en.wikipedia.org/wiki/Software_release_life_cycle
| sergix wrote:
| 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.
| Sytten wrote:
| 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.
| cpuguy83 wrote:
| 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.
| sergix wrote:
| 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]
|
| 1: https://sergixdev.notion.site/Tauri-
| Documentation-b695823f0b...
| rpastuszak wrote:
| +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.
| marcosdumay wrote:
| > it doesn't support AppStore distribution
|
| Ironically, having a team specialize on mobile is a great way
| to catch this kind of problem.
| rpastuszak wrote:
| Yes and no, publishing to the Mac AppStore is a slightly
| different beast.
|
| 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.
| mike_hearn wrote:
| You could check out the combination of Conveyor and
| Stripe:
|
| https://hydraulic.software/
|
| 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.
| gdcbe wrote:
| Do they use the native api of the OS to get the native feel or is
| it yet another website as app approach?
| timeon wrote:
| 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.
| CGamesPlay wrote:
| 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.
| anonymouse008 wrote:
| 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.
| throwayyy479087 wrote:
| Love hand wavy product pages for apps Ive never heard of. Tells
| you who knows what their doing and who you can ignore.
| turbobooster wrote:
| What does hand wavy mean?
| nkozyra wrote:
| Usually "dismissive" but it's come to mean vague or short on
| details.
| nvln wrote:
| "Being light on the details" is one generous explanation. You
| can add more intent, judgement to make it a lot worse though.
| nvln wrote:
| 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".
|
| [1]: https://tauri.app
| Gare wrote:
| And not bundling Chromium, but using OS-native webview
| instead.
| timeon wrote:
| > "Electron, but rust"
|
| If we are talking about language then it is more like:
| "Neutralino, but rust".
| chimen wrote:
| 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
| 1123581321 wrote:
| If you're not a cross-platform app developer you can ignore
| this, yes.
| solarkraft wrote:
| 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.
| capableweb wrote:
| This release is basically the reason I chose Tauri when I
| started writing my app like a year ago. Very exciting to see,
| can't wait to try it out.
| krapp wrote:
| >I don't get why there isn't (or is there) a simple way to
| package a web app for all platforms.
|
| There is. It's called hosting it on the web.
| synergy20 wrote:
| 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.
| krapp wrote:
| If you need native access to a platform, write a native
| application.
| Devagamster wrote:
| This is obtuse. Native applications require multiple
| codebases. Electron doesn't. The value prop is there...
| satvikpendem wrote:
| 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.
| return_to_monke wrote:
| https://flutter.dev has very good DX in my opinion for all
| platforms.
| nstart wrote:
| 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.
| yesimahuman wrote:
| Capacitor is another option with support for web, mobile, and
| desktop, if that's what you're looking for.
| CharlesW wrote:
| Looking through their site, Capacitor doesn't appear to
| support desktop apps. Their docs recommend using Electron
| instead.
|
| https://capacitorjs.com/docs/main/deployment/desktop-app
___________________________________________________________________
(page generated 2022-12-10 23:00 UTC)