8 ms·

Tauri Mobile Alpha Release

209 points by sbt567 4y ago

swyx 4y ago
shipping at a great pace
gdcbe 4y ago
Do they use the native api of the OS to get the native feel or is it yet another website as app approach?
- CGamesPlay 4y ago
  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.
- timeon 4y ago
  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.
throwayyy479087 4y ago
Love hand wavy product pages for apps Ive never heard of. Tells you who knows what their doing and who you can ignore.
- turbobooster 4y ago
  What does hand wavy mean?
  - nkozyra 4y ago
    Usually "dismissive" but it's come to mean vague or short on details.
  - nvln 4y ago
    "Being light on the details" is one generous explanation. You can add more intent, judgement to make it a lot worse though.
- nvln 4y ago
  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 https://tauri.app
  - Gare 4y ago
    And not bundling Chromium, but using OS-native webview instead.
  - timeon 4y ago
    > "Electron, but rust" If we are talking about language then it is more like: "Neutralino, but rust".
- chimen 4y ago
  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 4y ago
  If you’re not a cross-platform app developer you can ignore this, yes.
AlexErrant 4y ago
What does "Alpha" mean here? As compared to Beta.
- looperhacks 4y ago
  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 4y ago
    Ah, a simple search would've learned me. Thanks! https://en.wikipedia.org/wiki/Software_release_life_cycle https://en.wikipedia.org/wiki/Software_release_life_cycle
synergy20 4y ago
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 4y ago
  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 https://github.com/socketsupply/socket
  - synergy20 4y ago
    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 4y ago
      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 4y ago
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.
- synergy20 4y ago
  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.
  - Alifatisk 4y ago
    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.
  - revskill 4y ago
    The issue with capacitor and ionic is in legacy, outdated Cordova dependencies !
    - johnny22 4y ago
      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 4y ago
        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.
        johnny22 4y ago
        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.
sergix 4y ago
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 4y ago
  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.
  - andrew_ 4y ago
    > 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.
  - cpuguy83 4y ago
    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.
anonymouse008 4y ago
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.
solarkraft 4y ago
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 4y ago
  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 4y ago
  >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 4y ago
    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 4y ago
      If you need native access to a platform, write a native application.
      - Devagamster 4y ago
        This is obtuse. Native applications require multiple codebases. Electron doesn't. The value prop is there...
      - satvikpendem 4y ago
        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.
Pepe1vo 4y ago
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/ https://capacitorjs.com/
- synergy20 4y ago
  capacitor looks pretty good, what are those 'mistakes' you refer to
  - Pepe1vo 4y ago
    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.
- AbuAssar 4y ago
  what kind of mistakes did capacitor make?
- knubie 4y ago
  That is because Capacitor is just a fork of Apache Cordova, which is quite mature and stable.
  - tester457 4y ago
    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.
MengerSponge 4y ago
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 4y ago
  > Scuderia AlphaTauri https://en.wikipedia.org/wiki/Scuderia_AlphaTauri https://en.wikipedia.org/wiki/Scuderia_AlphaTauri was scratching my head for a second, finally got it :)
- gannonburgett 4y ago
  I came here to say the same. Thought I was misreading it for a second.
aliqot 4y ago
Tauri's been a pleasure to work with.
dceddia 4y ago
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 https://getrecut.com
- CharlesW 4y ago
  > 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 4y ago
    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.
- mccorrinall 4y ago
  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.
eps 4y ago
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.
- turbobooster 4y ago
  You weren't able to understand that as cross platform all dev?
pie_flavor 4y ago
> TLS support has been moved behind a Cargo feature until we figure out how to cross compile OpenSSL on Windows. *war flashbacks*
- miniBill 4y ago
  Hey, can you tell us more?
apatheticonion 4y ago
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. // 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.
- appveyor 4y ago
  Hey, this is exactly how https://flet.dev 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 https://flet.dev/blog#current-flet-architecture I'd love to add other languages, but currently so busy with a top-notch Python support!
  - apatheticonion 4y ago
    This is great! Looking into it - thanks for sharing
- trinovantes 4y ago
  That sounds like X11

209 points by sbt567 4y ago

swyx 4y ago

shipping at a great pace

gdcbe 4y ago

Do they use the native api of the OS to get the native feel or is it yet another website as app approach?

CGamesPlay 4y ago
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.
timeon 4y ago
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.

throwayyy479087 4y ago

Love hand wavy product pages for apps Ive never heard of. Tells you who knows what their doing and who you can ignore.

turbobooster 4y ago
What does hand wavy mean?
- nkozyra 4y ago
  Usually "dismissive" but it's come to mean vague or short on details.
- nvln 4y ago
  "Being light on the details" is one generous explanation. You can add more intent, judgement to make it a lot worse though.
nvln 4y ago
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 https://tauri.app
- Gare 4y ago
  And not bundling Chromium, but using OS-native webview instead.
- timeon 4y ago
  > "Electron, but rust" If we are talking about language then it is more like: "Neutralino, but rust".
chimen 4y ago
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 4y ago
If you’re not a cross-platform app developer you can ignore this, yes.

AlexErrant 4y ago

What does "Alpha" mean here? As compared to Beta.

looperhacks 4y ago
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 4y ago
  Ah, a simple search would've learned me. Thanks! https://en.wikipedia.org/wiki/Software_release_life_cycle https://en.wikipedia.org/wiki/Software_release_life_cycle

synergy20 4y ago

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 4y ago
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 https://github.com/socketsupply/socket
- synergy20 4y ago
  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 4y ago
    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 4y ago

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.

synergy20 4y ago
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.
- Alifatisk 4y ago
  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.
- revskill 4y ago
  The issue with capacitor and ionic is in legacy, outdated Cordova dependencies !
  - johnny22 4y ago
    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 4y ago
      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.
      - johnny22 4y ago
        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.

sergix 4y ago

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 4y ago
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.
- andrew_ 4y ago
  > 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.
- cpuguy83 4y ago
  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.

anonymouse008 4y ago

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.

solarkraft 4y ago

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 4y ago
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 4y ago
>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 4y ago
  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 4y ago
    If you need native access to a platform, write a native application.
    - Devagamster 4y ago
      This is obtuse. Native applications require multiple codebases. Electron doesn't. The value prop is there...
    - satvikpendem 4y ago
      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.

Pepe1vo 4y ago

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/ https://capacitorjs.com/

synergy20 4y ago
capacitor looks pretty good, what are those 'mistakes' you refer to
- Pepe1vo 4y ago
  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.
AbuAssar 4y ago
what kind of mistakes did capacitor make?
knubie 4y ago
That is because Capacitor is just a fork of Apache Cordova, which is quite mature and stable.
- tester457 4y ago
  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.

MengerSponge 4y ago

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 4y ago
> Scuderia AlphaTauri https://en.wikipedia.org/wiki/Scuderia_AlphaTauri https://en.wikipedia.org/wiki/Scuderia_AlphaTauri was scratching my head for a second, finally got it :)
gannonburgett 4y ago
I came here to say the same. Thought I was misreading it for a second.

aliqot 4y ago

Tauri's been a pleasure to work with.

dceddia 4y ago

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 https://getrecut.com

CharlesW 4y ago
> 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 4y ago
  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.
mccorrinall 4y ago
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.

eps 4y ago

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.

turbobooster 4y ago
You weren't able to understand that as cross platform all dev?

pie_flavor 4y ago

> TLS support has been moved behind a Cargo feature until we figure out how to cross compile OpenSSL on Windows. *war flashbacks*

miniBill 4y ago
Hey, can you tell us more?

apatheticonion 4y ago

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. // 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.

appveyor 4y ago
Hey, this is exactly how https://flet.dev 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 https://flet.dev/blog#current-flet-architecture I'd love to add other languages, but currently so busy with a top-notch Python support!
- apatheticonion 4y ago
  This is great! Looking into it - thanks for sharing
trinovantes 4y ago
That sounds like X11