[kayson]

I've been following tauri for a bit. It seems very cool and interesting but I've always wondered - what are the use cases for putting your app in a webview instead of using the browser? Everything I've thought of would work just as well.

[pdpi]

The goal is to make a standalone desktop app with access to local resources, so the question is "why should you put your app in a webview instead of Electron or a native toolkit?"

The answer is that Electron forces you to carry a whole Chrome installation around, which is unnecessarily heavy, and (AIUI) you have a node.js backend giving you the means to touch the actual OS, whereas Tauri lets you write Rust (YMMV as to whether that's an advantage). Both Tauri and Electron let you use a web-based interface instead of mucking about with native widgets, which are a pain for cross-platform development.

[cute_boi]

Additionally, we don't have to package whole node js thing.

[flessner]

There are many things web browser can technically do nowadays, but aren't great or not supported in all browser.

- File System (Obsidian, Logseq)

- Push Notifications (IM, Social Media, Email)

- USB/Bluetooth (Doesn't work in Safari?)

- Global Hotkeys (Raycast)

- Interfacing with other local Apps (localhost is often blocked)

[Klonoar]

For Slack & co, being able to be on the native application dock (for the average user) instead of buried in a tab is considered a significant visibility boost.

It’s also something that came about from when web apps on desktop/PWA didn’t have nearly as much reach. With e.g modern macOS support for PWAs you might be able to get away with just the web app now, depending on your target customer.

[ktosobcy]

Sadly instead of having native apps we have "web" monstrosities... each sporting custom "fancy" UI instead of following the OS native style…

[traveler1]

Because WinUI and QT are so glamorous and offer a super intuitive development experience. /s

[sirwhinesalot]

Best part is that neither of those follows the "native style" either. There's no dark uxtheme provided by windows, so Qt falls back to their fusion style. Even the "native" light theme doesn't follow the new "fluent" style so that's also a shitshow.

As for WinUI 3, apps are supposed to bundle it, so if you target Windows 11 and run the app on Windows 10, it'll look all rounded and drop-shadowy instead of flat like native Windows 10 apps. Great stuff.

[pjmlp]

As someone that is programming since 1986, has multiple native and Web frameworks experiences behind myself, have been back coding Web since 2019, because a lot of developers are lazy to learn how to write portable code.

Not even portable Web code, they rather ship a copy of Chrome, and then complain Google has taken over the Web.

[ktosobcy]

TBH I'd take QT app over any electron/web app... it still looks more consistent and matches the OS. Heck, even Java Swing (IDEA) looks better and feels more native than any electron crap.

[frou_dh]

IDEA is surely the ultimate gold-plated Swing app. I'm sure JetBrains have had to pour in a huge amount of time and money to get results that good.

[ktosobcy]

Not sure... It's mostly due to used L&F. You have FlatLaf (inspired by IdeaUI). Swing is surprisingly solid platform (though it has it's quirks and sadly it's development virtually stopped years ago)

[pjmlp]

Spot on, even if I do mostly Web nowadays to pay the bills.

[jmnicolas]

For example a reader app where you can't host everything on the server. My ebooks collection is 1TB big, and my videos are something like 20TB.

[codeptualize]

Anything that needs os access, to name some things: menu bar apps, clipboard access, file system, multi window, etc etc.

You can do a lot of things in the browser, but usually it's limited (mainly for security reasons). Having it be an app allows you to better integrate with the OS.

[duped]

I mean there are so many reasons why you would want to do this it's impossible to enumerate them all. Key command overrides are a great example of bad behavior on the web that is essential to UX in a native app. Or mouse pointer control. File system access and other native APIs the browser doesn't expose, or makes a pain.

[EasyMark]

I have too. I think the big deal is easy to do cross platform + reuse your javascript/css skills for gui + lower memory footprint than electron apps. I'm waiting until I see some major apps done in it.

[hobofan]

You build something that needs access to to the filesystem? -> No other choice than a desktop app. (Chrome has some limited APIs around that, but AFAIK only sandboxes ones and not e.g. existing directories)

[vunderba]

It makes more of a difference for the end-user then the developer necessarily.

An end-user can continue to use your electron/tauri app for years after a website has long since vanished into the infinite void.

But vunderba you think to yourself and also how did I know what you were thinking just call me the amazing kreskin, "what about a PWA? - you can use that off-line".

PWAs give the deceptive illusion to the laymen that they're installing an actual application as opposed to just a bunch of ephemeral stuff thrown inside the user data folder of the respective browser.

[lwhsiao]

Is it not lighter weight?

[IshKebab]

Not lighter weight than a website because it is a website. The only advantages are you can ship parts of your app as native code, and you aren't constrained by the browser permission model.

[FFFXXX]

One interesting usecase is that you can run a tauri app without any webview windows just as a system tray icon and only spawn a webview window when necessary.

This kind of makes it way more lightweight but only in some situations (obv. heavily depending on the functionality of the app).

[runevault]

Would this be for a service style app that happens to have a UI when you need to configure it? If so that's an... interesting idea, but considering the UI is less important I'd probably mind it less (as someone who is not a fan of Electron apps).

[theultdev]

I built a syncing tool that needed to run in the background with a simple UI to control it.

I used tauri so I could easily make that cross-platform toolbar app.

Some menu items spawn a webview (things like settings), everything else is in Rust.

[jauntywundrkind]

Can anyone explain what Tauri or webviews offer that makes them a good choice over a local-http-server webapps? Imo, as a user, Webview, no thanks. Local webapps, yes please.

There really isn't a good reason for webviews or electron/tauri that I can tell? Why some people love love love native apps, to the extent they'd rather a dressed up webapps is confusing to me. If it's already a webapps, hell yeah give me the user-agency of extensions, browser history, tabs, back buttons, and hyperlinks or give me death! Anything but the power-stripping captive-audience of native apps!

It would be much better to package your app as a small daemon that hosts a localhost webserver. The daemon can talk to all the system APIs it needs to. Add a desktop icon or shortcut that opens the localhost webpage. The daemon can present just a regular HTML hypertext webapps as usual, so all the usual bits of user-agency can slot into the overall experience.

Theres a lot of usenet-related apps that work like this, that run as daemons, and have web interfaces. Sunshine game streaming too.

It's be great to have some massively multi-platform http-headed app frameworks! That does seem semi missing, especially wrt mobile integration.

[aseipp]

Because you're thinking of it backwards. Users have known for decades that they can click an icon, a window will appear, and that's the "application" they're interacting with. This is culturally ingrained as the basis of graphical operating systems (even mobile!) and it's a standard people want to continue meeting regardless of the underlying technology they use.

It just turns out due to historical reasons, in 2024, "the web" has the most easy-to-get-running cross platform UX system available, where you can produce an icon that people click, and it opens the app. That's basically the long and short of it.

At the end of the day most of the stuff you mentioned doesn't matter because these are, from the beginning, designed as applications that use the web as a way to deliver UI more than anything. Things you mention like back buttons (requiring you to design around stateless hypertext APIs rather than what would be local RPC, and which may be better handled inside the system anyway with e.g. its own undo system) or "browser history" either have large design consequences, or just don't make any sense at all.

To be clear, it's very useful in some cases to have the design you describe (true client/server architecture), and underneath it all Tauri does something like that. But it alone can't fulfill all the use cases something like Tauri or Electron aim to.

> The daemon can talk to all the system APIs it needs to.

That's not the problem, it's the impact on the downstream design, like the fact such a daemon can't cleanly interact with the native windowing context of the (existing) browser or operating system without duplication. You cannot add a proper system menu bar or global shortcuts to the design you described in any way that won't either be sucky and fiddly, or just outright reimplementing what Tauri already does anyway. Or consider alt tabbing and wanting to dial in on a specific app window. There are tons of small things like this that do not work.

[TheCleric]

You are absolutely the exception there, especially if you are talking about an average low tech user.

[jauntywundrkind]

I don't have any understanding why that would be though. Even if it is true, is there a reason or is it happenstance / path-dependence?

It seems so inferior to have the same thing but lose access to the browser's suite of tools/capabilities. What could possibly change other people's opinion or what should I use to reconsider my perspective?

[TheCleric]

When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with.

I’m talking from a position of “I have an app that I want to distribute to a population of end users.” If that population happens to be technical your solution would likely work fine. As well if you’re not distributing apps to end users you can do what’s right for you. But if you are you have to meet your users where they’re at.

As well operating outside of the browser has the advantage of OS integration (tray access, alt tab support, etc).

[jauntywundrkind]

> When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with.

Clearly not true.

Sonarr and Radarr for example installs like a normal app. Then sits in the system tray. If click the system tray, most options inside launch a web browser that brings you to the localhost webapp. https://sonarr.tv/

People seem to assume this would be a hard to handle thing, but you can easily applicationize your local web services. And your local web service daemon can expose things like a system tray, to afford some classic manageability.

[theo0833]

> It seems so inferior to have the same thing but lose access to the browser's suite of tools/capabilities.

Explicitly removing the browser capabilities/tools is a feature imo. i.e to hide the moving parts.

Within a browser, the average low tech users may:

- ...install extensions(ad blockers? dark reader?) that interfere with the app in some way.

- ...mess with the back/forward buttons ,corrupting the router/ui state, or just get very curious why the back button kicks them back to the last page instead of closing a fullscreen modal.

- ...bookmark SPA js-driven pages where the ui state is not fully saved in the address bar(via query params, hashes, etc) and surprisingly find them broken/not working as intended when accessing the bookmark again.

- ...try to copy and send the "localhost" link to their friends and complain.(Hold on to your papers - I've seen this behavior at my workplace!)

All of those will generate complains, useless bug reports and sometimes negative reviews. While some (if not most) of the problems can be solved with great software design and extra care, I think solving these problems comes at a cost that can be very well avoided by simply removing these capabilities.

[brigadier132]

Write once run everywhere is the holy grail of app development and the browser is the only realistic way of achieving this.