[HN Gopher] Tauri Mobile - Develop Mobile Apps with JavaScript a...
___________________________________________________________________
Tauri Mobile - Develop Mobile Apps with JavaScript and Rust
Author : stefanvdw1
Score : 168 points
Date : 2023-03-01 08:08 UTC (14 hours ago)
(HTM) web link (studioterabyte.nl)
(TXT) w3m dump (studioterabyte.nl)
| college_physics wrote:
| 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.
| tekkk wrote:
| 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?
| yesimahuman wrote:
| 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.
| eklavya wrote:
| 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?
| yesimahuman wrote:
| 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)!
| eklavya wrote:
| Thanks for your kind offer :)
| not_a_shill wrote:
| 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
| nicoburns wrote:
| > 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...
| not_a_shill wrote:
| 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
| nicoburns wrote:
| 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.
| nwienert wrote:
| Tamagui also really makes targeting web or native really
| enjoyable.
| terhechte wrote:
| 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.
| sebastianconcpt wrote:
| 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.
| terhechte wrote:
| 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
| nwienert wrote:
| 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.
| tayistay wrote:
| 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
| Klonoar wrote:
| _> 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.
| pjmlp wrote:
| Here is the trick for Electron junk, when they have the option
| to do so, use the Web app.
| sljsdljfslkj wrote:
| > 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.
| dindresto wrote:
| 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.
| fastball wrote:
| How is Rust manipulating the DOM?
| terhechte wrote:
| 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/tre
| e/master/packages/in...
| lucasyvas wrote:
| This explains how Dioxus also has a LiveView mode - that
| sounds exactly how LiveView works.
| [deleted]
| survirtual wrote:
| 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.
| dindresto wrote:
| 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?
| terhechte wrote:
| 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).
| dindresto wrote:
| Looks like someone attempted this last year, without any
| success unfortunately: https://github.com/dceddia/wgpu-tauri-
| experiment
| flohofwoe wrote:
| 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).
| explaininjs wrote:
| 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.
| nicoburns wrote:
| 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.
| explaininjs wrote:
| > 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 :)
| MrJohz wrote:
| 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.
| nicoburns wrote:
| 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.
| [deleted]
| TJSomething wrote:
| 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.
| pictur wrote:
| 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.
| simion314 wrote:
| 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.
| maxloh wrote:
| What is Tauri's advantages over Cordova?
|
| Cordova failed the competition against React Native and Flutter.
| pornel wrote:
| Cordova assumes you'll write most of the app in JS.
|
| Tauri is more like a framework/GUI toolkit for Rust apps.
| nequo wrote:
| 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
| usrusr wrote:
| 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.
| yesimahuman wrote:
| 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.
| lucasyvas wrote:
| 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.
| rascul wrote:
| 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.
| barakplasma wrote:
| 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-...
| flohofwoe wrote:
| 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.
| pedalpete wrote:
| 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.
| eklavya wrote:
| What is the platform api story (kotlin/Swift ffi) for tauri
| mobile?
| terhechte wrote:
| 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
| eklavya wrote:
| I am not sure I understand. How do I call android/ios camera,
| gallery, permission etc APIs?
| terhechte wrote:
| 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
| turbobooster wrote:
| Flutter has way better support
| capableweb wrote:
| Unless you care about accessibility, seems Flutter don't care
| too much about that, yet at least.
| account-5 wrote:
| 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?
| orthecreedence wrote:
| 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. Google 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.
| penguin_booze wrote:
| 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.?
| erlend_sh wrote:
| > 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...
| marcus_cemes wrote:
| 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.
| nwah1 wrote:
| .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.
| naavis wrote:
| It's also no-go for Linux. Otherwise I would be all over it.
| nwah1 wrote:
| 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/
| FlyingSnake wrote:
| 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.
| wdb wrote:
| 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.
| DanielHB wrote:
| 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
| intelVISA wrote:
| Might sound wild but network-order bytes are pretty platform
| agnostic.
| usrusr wrote:
| 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.
| zacharachnia wrote:
| [flagged]
| paulryanrogers wrote:
| What about Electron sucks? Is Tauri's sole advantage that it
| crashes less?
| mourner wrote:
| To people missing the joke, this is a quote from ChatGPT that
| was asked to comment on Tauri in "Dev Mode", taken from
| comments here https://news.ycombinator.com/item?id=34972791
| gausswho wrote:
| Wasn't funny the first time and it's not insightful. HN is
| better without.
| zacharachnia wrote:
| Lighten up.
| bsaul wrote:
| 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..
| maxloh wrote:
| It is something like Cordova?
| nkozyra wrote:
| 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.
| born-jre wrote:
| 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
| mellonaut wrote:
| 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
| [deleted]
___________________________________________________________________
(page generated 2023-03-01 23:01 UTC)