[HN Gopher] Tauri 2.0 tries to make mobile apps crossplatform
___________________________________________________________________
Tauri 2.0 tries to make mobile apps crossplatform
Author : nancyp
Score : 93 points
Date : 2024-02-23 19:33 UTC (3 hours ago)
(HTM) web link (beta.tauri.app)
(TXT) w3m dump (beta.tauri.app)
| nancyp wrote:
| They were a great alternative for Electron for desktop apps for
| sure. I'm not very hopeful that they become yet another solution
| to solve too many platform issues. How could they prevent the
| framework become over bloated with semi baked plug-in?
| SomeCallMeTim wrote:
| > How could they prevent the framework become over bloated with
| semi baked plug-in?
|
| ...not sure how they plan to, but how they COULD do it is by
| making it easy enough to directly access native resources
| directly from the script language (like NativeScript) or by
| making it so easy to write native code (Kotlin/Swift are listed
| as first-class options) that you just write any specific API
| access code in the appropriate native language.
|
| It doesn't give you the Electron "write once run everywhere"
| experience, since you need to write some of the code per-
| platform, but many apps are 95% UI and only 5% platform-
| specific functionality. So by abstracting the UI by having it
| be HTML/CSS/JavaScript, you're getting a "write once run
| everywhere UI" and the minority of the code that needs to
| differ is all you have to maintain per-platform.
|
| If writing a plug-in is a high bar, then you get tons of semi-
| baked plug-ins as the (seemingly) only way to access native
| features. If instead you can drop in native code easily and
| quickly, then you can focus on app development and cut out the
| middleware. ;)
| butz wrote:
| If you ditch all "support" libraries, your webview Android
| application can be smaller than 100KB. And it will build much
| faster too.
| yesimahuman wrote:
| Seems like the main differentiator for Tauri is building plugins
| and features in Rust, no? Otherwise the core architecture will be
| the same as Capacitor and other projects as that is dictated by
| the SDK support on each platform (especially iOS).
| usrusr wrote:
| I'd consider Tauri more a tool for web-UI on desktop that also
| happens to be usable on mobile than a tool to unify iOS and
| Android. Certainly a lot of overlap.
| tdhz77 wrote:
| Play around with Tauri the last few months and I've come to the
| realization that I don't want to build my business on it. We have
| seen these before (Electron, Expo, Ionic) and they all suffer
| from the same pitfalls. Now if I have a web application and I'm
| trying to target mobile and I want to give my business time to
| develop a native application than I'm using Tauri over the rest
| of the crowd. A targeted business strategy can make this work,
| but you are doing so because you need speed not durability or
| longevity.
| moffkalast wrote:
| As someone considering exploring this direction, what pitfalls
| specifically? There is a performance hit, sure, and
| considerable memory usage, but that's the trade off for having
| essentially a virtual machine to work on. And with VS Code
| being Electron based it's at least conceivably possible to make
| this approach very performant. On desktop anyway.
| oooyay wrote:
| I'm curious what pitfalls you're referring to. Frameworks like
| Tauri and Wails are a far departure from Electron in that they
| don't bundle a browser.
| edjw wrote:
| The Build and Distribute parts of the docs are the things I
| clicked on first. How can I get Tauri mobile apps in Apple and
| Google app stores? But they're both 'stubs' with no content yet.
|
| https://beta.tauri.app/guides/build
| https://beta.tauri.app/guides/distribute
| yieldcrv wrote:
| Maybe its only EU compliant
|
| .. where Apple has to allow sideloading
| account-5 wrote:
| Why would you use this over dart/flutter for cross platform
| mobile apps?
|
| I chose dart/flutter after searching and failing to work out what
| would be the best web framework to use out of the ever increasing
| amount of them.
| xcdzvyn wrote:
| It's been disheartening to see the degradation of desktop
| computing because of the shift to "mobile first".
|
| That AI UI designer (Aiuzard?) doesn't even know what a "desktop
| program" is. Everything's expected to look like a website or a
| mobile app.
| rayiner wrote:
| We have gone backward. MacOS X gave us a smooth, tear-free
| desktop back in 2001. Electron apps and other web technology
| based apps shit all over that. Even basic apps tear and rubber
| band when doing something as mundane as resizing the window.
| They are grotesquely slow and janky while also having a
| fraction of the features of the apps that we used to use for
| the same things. And then there's all the paradigms that make
| sense on mobile but feel like a straitjacket on the desktop,
| such as model windows for editing items, or single-window
| interfaces.
|
| Frankly, it's depressing. It's like living in Detroit or
| Baltimore or Pittsburgh after deindustrialization, when you
| remember what they were like in their heyday.
| bbkane wrote:
| I agree, but I think this is largely the fault of OS Vendors,
| who design deskop creation frameworks that are usually some
| combination of hard to use, not very stable, not powerful
| enough, ugly, or not cross-platform.
|
| I'm sympathetic to the argument that OS Vendors shouldn't be
| held responsible for their libraries being used outside their
| OS, but that's clearly what (most) developers want, so (in my
| opinion) it's a requirement for a popular library.
| the__alchemist wrote:
| If you are looking for a non-web-based cross-platform GUI in
| rust, check out EGUI. It has an easy-to-use API, good docs, runs
| fast, and can integrate with 3d graphics, maps etc.
|
| > By being built on Rust, Tauri is able to take advantage of the
| memory, thread, and type-safety offered by Rust. Apps built on
| Tauri can automatically get those benefits even without needing
| to be developed by Rust experts.
|
| How much of this is mitigated by being web-API-based?
| fs0c13ty00 wrote:
| At least it is a mile better than the abomination named
| Electron.
|
| Each Electron app has both Chromium _and_ NodeJS bundled. Tauri
| only use platform-specific webviews, and Rust is a compiled
| language with no GC and no runtime.
| the__alchemist wrote:
| That sounds like a significant advantage.
| Klonoar wrote:
| egui works for things where you can get away with non-standard-
| OS behavior and/or are fine with immediate mode. Quite a few
| projects are not under this umbrella.
|
| _> How much of this is mitigated by being web-API-based?_
|
| Tauri makes it much easier to use the web side _only_ for
| presentation and defer _almost everything else_ to the Rust
| side. The web browsers themselves are pretty well sandboxed all
| things considered.
| videlov wrote:
| We have been using Tauri for about a year (a desktop app) and I
| am very happy with our choice. What I initially found attractive
| was the smaller binary sizes. Over time I have come to really
| appreciate their stance on security and implementation of the
| Isolation pattern[0].
|
| When we were deciding whether we want to build our business[1]
| around Tauri, the final argument that helped me decide was the
| video manifesto[2] on their site as I felt that we were aligned
| on values. Having interacted with the community over this one
| year I have had a very positive experience, therefore Tauri
| definitely gets my recommendation.
|
| [0] https://tauri.app/v1/references/architecture/inter-
| process-c... [1] https://github.com/gitbutlerapp/gitbutler [2]
| https://tauri.app/about/intro
| seabass-labrax wrote:
| I'm pretty impressed by what's been put in place to ensure good
| governance of the project. They have already become a project of
| the Commons Conservancy, which is a 'fiscal sponsor'
| organization, and they have a _very_ geographically diverse
| initial board (seven board members from seven different countries
| across four continents).
|
| Whatever the technology, this is a serious committent to
| community-led FOSS, which already sets it apart from the
| Flutters, Xamarins and Ionics of the world, which are primarily
| profit-making ventures with an open source aspect on the side.
| Projects founded with a strong mission and rigorous planning
| usually cause positive changes within the other ecosystems they
| touch, even if they don't end up standing the test of time
| themselves.
| martpie wrote:
| I am currently working on porting Museeks [0] from Electron to
| Tauri 2.0, mainly to reduce the memory and app size footprints,
| which are the main things everybody complains about with
| Electron.
|
| What I really like:
|
| - the dev experience is stellar and comes out of the box. No need
| to setup binary compilation, webpack, vite, hot-reload, TS
| compilation for back-end, etc yourself. You can pick your
| favorite JS framework with Vite, during setup, or use a Rust
| frontend (kind of what electron-forge is doing, but it is buggy,
| and landed yeaaaars after Electron was released).
|
| - the architecture makes sense (commands, security, plugins, all
| very well-designed)
|
| - they provide official plugins for common-usecases (SQL, config,
| etc)
|
| - Rust is fun and interesting to learn for folks like me used to
| high-level languages like JS or Python
|
| What I don't like as much:
|
| - facing webview-specific UI issues (feature X does not work on
| Safari, Y not on gtk-webview etc), with Electron, you know if X
| works on Windows, it will work on Linux or MacOS
|
| - some rough edges with the framework or the ecosystem (not as
| mature or dev-friendly as npm's or Electron), but the crates (and
| Tauri's) maintainers are very friendly and reactive.
|
| - the focus on mobile apps, It seems like a very different space,
| and it feels weird to try to build with big mashup framework. I
| would rather have them work on more integrations, but whatever.
|
| - changes in the Rust backend can take minutes to compile, and
| rust-analyzer is damn slow.
|
| Overall I'm really happy and having a lot of fun. I will keep
| working on this port and release it when I can. Kudos to the
| Tauri team, what you are building is awesome :)
|
| [0] https://museeks.io
| amenhotep wrote:
| > changes in the Rust backend can take minutes to compile, and
| rust-analyzer is damn slow.
|
| Do you find that if you run cargo build, then trigger RA -
| without even making any changes - then run cargo build again,
| it recompiles a bunch of dependencies?
|
| If so, you might find that pinning anyhow to =1.0.77 fixes
| this! There's a bug somewhere in the interaction between RA,
| cargo and some crates including afaict mostly dtolnay's which
| leads to RA runs causing the crate build script to think that
| RUSTC_BOOTSTRAP is set and they should invalidate the
| fingerprint and recompile.
|
| Perhaps totally unrelated :) but I ask because I just spent
| days chasing this down only to find, once in the possession of
| the important keywords, that some helpful fellow had already
| filed a PR with rust-analyzer that purports to fix it and so my
| efforts were probably pointless. But if I can save some random
| guy a few minutes of compile time before the fix is released
| then it's worth it, right?
| amenhotep wrote:
| (also thiserror =1.0.52!)
| Sytten wrote:
| Been using it in production for over 2y, expect a lot of
| complaint from Linux user. Webkitgtk is really behind in terms
| of performance, standard support, etc. And it is not on MDN
| compatibility list so good luck finding what is available. It
| is to the point where we marked it as experimental for our
| users and considered switching to electron (we didnt yet).
|
| Also you can expect hard to reproduce bugs on X version of Y OS
| that are not reproducable anywhere else. It's a PITA to
| maintain even for people used to the pain of cross browser
| problems. Just yesterday I got a user on macos 12 reporting not
| being able to write in some input fields, no error in the
| console. Now I need to figure out how to have a VM of that
| macos version with the specific patch for the webview version
| to match to reproduce, nightmares I tell you.
|
| Otherwise it is decent and we are a rust shop so it makes sense
| for us. But IMO it is impossible they will gain any market
| traction in bigger businesses until we have standard webview
| packaged into the binaries like electron.
| temeritatis wrote:
| > mainly to reduce the memory and app size footprints, which
| are the main things everybody complains about with Electron
|
| Those are annoyances. But the way an app feels and behaves is
| the main culprit IMHO. I'd rather have a heavy app that looks
| and feels native than the other way around.
|
| I don't know about museeks tho. Never tried it. But best of
| luck with the port in any case!
| abound wrote:
| Another (also Rust-based) cross-platform mobile app dev kit is
| crux [1]. I've never used it, but the core idea of "native UIs
| (i.e. in Kotlin + Swift) with a shared business logic core via
| IPC" seems like the sweet spot to my mostly untrained
| sensibilities.
|
| [1] https://redbadger.github.io/crux/
| malermeister wrote:
| Just use Compose and Kotlin Multiplatform.
___________________________________________________________________
(page generated 2024-02-23 23:01 UTC)