Could tauri app run inside browsers?

[dumblob]

Describe the problem

As pointed out in #616 programmers want to maintain one code base for all devices - desktop, mobile, and web.

Describe the solution you'd like

Write once run everywhere 😉.

Compilation of the app shall produce a PWA app in a bundle (maybe a compressed archive and a deployment script) which will be easily deployed to a chosen web server or alternatively would produce a docker container (with everything needed as dependencies - incl. web server, DB, etc.) and which will make it accessible to clients.

Alternatives considered

Developing a home-grown shim library and constantly and forever fighting with Tauri making incompatible changes due to not having policies/goals in place to make the API and behavior aligned with web technologies in the wild.

Additional context

Is that possible as of now or at least planned?

Does it need some shim library on the web (mimicking the Tauri API)?

Does anyone writes & maintains such shim library?

[Celestialme]

Can I get URL of my app to open in browser instead of opening webview window? This will be so handy for example when developing linux apps from windows remotely without using X11 forwarding. For now my front end framework (svelte) gives me URL but of course it is not connected to Rust to invoke command. shortly I want to open front end in browser which will be connected to Rust to invoke backend commands on linux machine. After that I can build package and publish.

[red010182]

Perhaps WASM is a possible way?

[amrbashir]

To answer the OP question, If you want to use your codebase for web and tauri at the same time then you need to guard your tauri app apis usage. e.g.

if (window.__TAURI__) {
  // --snip--
}

[JonasKruckenberg]

To answer the OP question, If you want to use your codebase for web and tauri at the same time then you need to guard your tauri app apis usage. e.g.

if (window.__TAURI__) {
  // --snip--
}

Or use the @tauri-apps/api/mocks module which is basically officially maintained "shims"

[dumblob]

To answer the OP question, If you want to use your codebase for web and tauri at the same time then you need to guard your tauri app apis usage. e.g.

if (window.__TAURI__) {
  // --snip--
}

Thanks for the pointer. Let me rephrase the answer:

No, there is no such functionality nor any plans to align Tauri (down to the API level) with web.

Is that correct?

[nothingismagick]

We understand your question, and I can tell you from firsthand experience, with a combination of clever CI and either middleware or checks like those above, you can very easily achieve what you want.

Our priority is to make desktop and mobile apps, because that is our mission.

[FabianLars]

Yea that's correct. This is the responsibility of your frontend not tauri itself. It's kinda like asking node-fetch to implement support for window.fetch. Edit: This may not be the best example, but it was the first one i came up with. Either way you get the idea.

And about the shim lib, this should be a community project instead of something official imo. (But even this library can't ever be a one-fits-all solution)

Edit: That timing again 😠 😂

[amrbashir]

No, there is no such functionality nor any plans to align Tauri (down to the API level) with web.

Is that correct?

Tauri's api was not designed to align with web apis and was just about introducing helper functions for JS devs. There is issue #2233 where I try to reduce the gap between tauri's api and Node.js and I can't say for sure that we won't align with web apis in the future. It is just not a priority right now.

[dumblob]

I understand.

Ok, we could then discuss it from a different angle. How about significantly decreasing the pain to port a an existing full-featured complex pure-tauri desktop/mobile app to web while maintaining the desktop/mobile version fully functional?

[amrbashir]

Isn't that the same thing as web compatible apis? Anyways, we are open to suggestions but not a priority right now. Maybe you can start a discussion with problems you encountered and possible improvements.

[dumblob]

Isn't that the same thing as web compatible apis?

@amrbashir not at all. When porting a complex app to a new platform, you're very far from rewriting it (actually porting means "trying very hard to not rewrite anything").

Anyways, we are open to suggestions but not a priority right now.

Suggestion is to align Tauri's API with web APIs - e.g. by providing a maintained shim (either wrapping Tauri APIs or by providing Tauri API as wrappers over web APIs or a mixture of these two approaches).

Maybe you can start a discussion with problems you encountered and possible improvements.

I doubt anyone would do this - Tauri is new and nobody would choose a new platform for a complex app if there was even a tiny possibility of the future need to use it on the web. In other words, there are no complex apps which anyone would be interested in trying to port them to web (we're talking about production-level quality porting, not just some school-level attempts).

Your request would make sense if you were Qt or other extremely widespread library. So in case of Tauri this is a strawman.

[optevo]

We understand your question, and I can tell you from firsthand experience, with a combination of clever CI and either middleware or checks like those above, you can very easily achieve what you want.

Our priority is to make desktop and mobile apps, because that is our mission.

I'm not trying to sound like a smart-ass (honestly) but you could look at PWAs as just one way to "make desktop and mobile apps"... I get that it's currently a non-goal of Tauri. I just think it's a shame as web/PWA is the only mainstream client type which your roadmap is missing support for so I'm sure would be appreciated and might attract more project contributions.

On a more technical level, using rust/wasm could potentially help shrink the PWA payload size which would be a handy - and possibly a unique benefit; I'm not aware of any other project that delivers this (happy to be told otherwise).

[xzn]

To be more specific about what's being asked, we can already serve the files generated by the front end with a custom backend written in whatever we like. The only thing is that the web version won't have access to tauri apis so we have to communicate with the backend differently with our own HTTP glue code.

That doesn't seem like too much of an inconvenience tbh.

One way to get around this and have one code base for everything is to simply avoid using the tauri javascript api and do everything manually in HTTP instead (for IPC/RPC and so on). It should also be possible to to have a web server (axum/warp/etc.) as part of your tauri backend binary and feed the HTTP requests with Assets/AssetResolver/etc. from tauri so that the same binary can be used to serve the website over the network (if this is something you want). Obviously the website served over the network won't have isolation and other nice things that comes with tauri but that's just the limitation of the web platform.

Also not all tauri javascript apis make sense on the web anyway. Unless your desktop app is literally just the website but with database stored locally, you'd end up with separate code logic anyway. If your intention is to have your desktop app to be just a local version of the web app, and have a binary for easy self-host, then the approach just mentioned above should work hopefully.

[ahqsoftwares]

Also, theres something else to note. You can use tauri apis to make your own api wrapper that executes tauri api if app and web api or nothing if web