> Essentially. you do not ship a browser in Tauri.

I mean, essentially you are? It just so happens that this web browser that your application very much runs on top of may link (to a more or less large extent) with the host OS "WebView"/built-in browser (assuming there's one to begin with). My point still stands: if you are lucky, you may save some on the binary size download, once, but the run time is a web app with all the quirks and inefficiencies of the web as a platform.

▲

andrewaylett a day ago | parent [-]

You run on a browser, but that's very different from shipping a browser.

And you save more than merely the download size: there's the equivalent disk size savings but also not having to load n browser engines into RAM at the same time.

There's definitely stuff I don't like about Tauri — the way the UI is quite so separate from the native logic, for example — but there are still definite advantages over Electron.

	▲	ezst 3 hours ago \| parent [-]
		> but also not having to load n browser engines into RAM at the same time. have you noticed the amount of sandboxing required by (the lack of a) modern web's security model? Each app/tab needs its own JS/WASM interpreter in a dedicated process (for memory isolation), common assets (images, JS, CSS, …) must be duplicated in memory as to defuse timing attacks (since spectre/meltdown), rendering/WebGL contexts are a similar story. You may be over-estimating the savings there. More to the point, I never said that the above is pointless (the argument was never about the pros and cons of tauri's using the system WebView), the argument was that it is mostly irrelevant: tauri apps, just like electron apps, are inherently web-based. They have more in common than e.g. a tauri app and a native C++/Qt app. The gripes people have with electron apps (lacking integration, wasting resources, …) apply almost equally to both to the point it barely matter from the end-user's perspective.