Cool, is the core sales pitch still a lie on Linux? Yes? Lovely, no thanks then.
</snark>
The big appeal of Tauri is that you don't need to ship a webview with every app. On Linux, Tauri not only ships its own webview, it's also an old and fundamentally broken webview. So you get fast and small apps on every platform, but huge and slow apps on Linux.
I'm not saying it's their fault. It's just not something they're interested in fixing the right way and that's their choice. But the false advertising is entirely their fault.
The big appeal for me was that Tauri didn't ship an entire Chrome browser to make it work. It never even occurred to me to gauge the webview used in such detail.
> On Linux, Tauri not only ships its own webview, it's also an old and fundamentally broken webview
I'd love to hear some details on this. What is Tauri shipping now and what should it ship instead?
I agree, that's the biggest appeal. But on Linux, there isn't really a "system webview", so they use webkit2gtk. Most systems happen to have this installed as a dependency for something else, so it's a reasonable choice.
The thing is, that library is based on an ancient version of webkit, which is slow and lacks some modern web features. There are some open issues about it and the response is "yea, we know, we're doing the best with what we have", which is fairly reasonable.
A secodary complicating factor is that the main "universal binary" for Linux is AppImage, which by design requires you to ship all the dependencies. So you end up with the eorst of both worlds: you're still shipping an entire webview with every app, just like Electron, while unlike Electron, which is based on recent Chromium, the webview is based on outdated Webkit.
There have been some attempts to bundle CEF (basically Chromium) instead of Webkit and there is also a testing branch that uses Servo, but those only solve the second issue.
Ideally, the Linux ecosystem would standardise on a webview implementation and Tauri could link to that, just like they link to Webkit on macOS and Edgeium on Windows. It could be based on Blink (Chromium) or Gecko (Firefox) or even better, it could be just a standard interface and the use could pick their implementation. But since the Tauri folks would be the first and for a while only people using it, they'd probably have to do most of the work themselves.
Might help to have a companion app that uses the same embedded webview that is nearly indispensable at least for gui distros... something akin to MS Compiled Help (CHM) ... which I always thought was a pretty great idea.
I mean... it'd be a trip down the MS route, but maybe working with the Cosmic devs on this one... getting a baseline webview in place at the core, tooling support for help, email, etc. Getting Cosmic, Gnome and KDE all on board would be a massive boost and cover most users.
I really think most of the criticism towards embedded Browser engines would be moot if there was an engine where anything unrelated to layout and rendering had to be imported piece by piece. Most of the time, we just desire what HTML and CSS give us (layout and styling) and an element node API in the DOM, or something like that. So many other things get wrapped into even the most stripped down browser engines that don't really have to do with layout and styling which increases the bloat. I don't really see why we can't have a GUI toolkit that just renders HTML and CSS and only be in the dozens of megabytes. I don't care that lots of existing Node modules wouldn't work out of the box. Give me HTML rendering without the kitchen sink. It seems we aren't capable of this. From what I can tell, this can't even be done easily enough with Servo.
That's what Sciter does - https://sciter.com/ - it just gives you a lightweight HTML / CSS / Javascript "webview" engine for layout and rendering. Like you pointed out, that should be enough. But corporates want a "webview" that is an OS so that they can do everything with Javascript on it (hence why embedded Chrome with NodeJS is so popular).
I wanted to try tauri out, but i couldn't get the nix dev shell for it working. My suspicion was that they do something too magical with the build process.
Cool, is the core sales pitch still a lie on Linux? Yes? Lovely, no thanks then.
</snark>
The big appeal of Tauri is that you don't need to ship a webview with every app. On Linux, Tauri not only ships its own webview, it's also an old and fundamentally broken webview. So you get fast and small apps on every platform, but huge and slow apps on Linux.
I'm not saying it's their fault. It's just not something they're interested in fixing the right way and that's their choice. But the false advertising is entirely their fault.
You are being too harsh - it is not Tauri's fault that Linux, unlike Windows or macOS doesn't have a webview component built-in. Even Wails (powered by Go instead of Rust) requires libgtk3 and libwebkit ( https://wails.io/docs/gettingstarted/installation ) to build apps with it on Linux ( https://wails.io/docs/gettingstarted/installation ).
I tried to make it clear that I don't think it's their fault. It's an unfortunate situation, but they should really be more upfront about it.
The big appeal for me was that Tauri didn't ship an entire Chrome browser to make it work. It never even occurred to me to gauge the webview used in such detail.
> On Linux, Tauri not only ships its own webview, it's also an old and fundamentally broken webview
I'd love to hear some details on this. What is Tauri shipping now and what should it ship instead?
I agree, that's the biggest appeal. But on Linux, there isn't really a "system webview", so they use webkit2gtk. Most systems happen to have this installed as a dependency for something else, so it's a reasonable choice.
The thing is, that library is based on an ancient version of webkit, which is slow and lacks some modern web features. There are some open issues about it and the response is "yea, we know, we're doing the best with what we have", which is fairly reasonable.
A secodary complicating factor is that the main "universal binary" for Linux is AppImage, which by design requires you to ship all the dependencies. So you end up with the eorst of both worlds: you're still shipping an entire webview with every app, just like Electron, while unlike Electron, which is based on recent Chromium, the webview is based on outdated Webkit.
There have been some attempts to bundle CEF (basically Chromium) instead of Webkit and there is also a testing branch that uses Servo, but those only solve the second issue.
Ideally, the Linux ecosystem would standardise on a webview implementation and Tauri could link to that, just like they link to Webkit on macOS and Edgeium on Windows. It could be based on Blink (Chromium) or Gecko (Firefox) or even better, it could be just a standard interface and the use could pick their implementation. But since the Tauri folks would be the first and for a while only people using it, they'd probably have to do most of the work themselves.
Might help to have a companion app that uses the same embedded webview that is nearly indispensable at least for gui distros... something akin to MS Compiled Help (CHM) ... which I always thought was a pretty great idea.
I mean... it'd be a trip down the MS route, but maybe working with the Cosmic devs on this one... getting a baseline webview in place at the core, tooling support for help, email, etc. Getting Cosmic, Gnome and KDE all on board would be a massive boost and cover most users.
I really think most of the criticism towards embedded Browser engines would be moot if there was an engine where anything unrelated to layout and rendering had to be imported piece by piece. Most of the time, we just desire what HTML and CSS give us (layout and styling) and an element node API in the DOM, or something like that. So many other things get wrapped into even the most stripped down browser engines that don't really have to do with layout and styling which increases the bloat. I don't really see why we can't have a GUI toolkit that just renders HTML and CSS and only be in the dozens of megabytes. I don't care that lots of existing Node modules wouldn't work out of the box. Give me HTML rendering without the kitchen sink. It seems we aren't capable of this. From what I can tell, this can't even be done easily enough with Servo.
That's what Sciter does - https://sciter.com/ - it just gives you a lightweight HTML / CSS / Javascript "webview" engine for layout and rendering. Like you pointed out, that should be enough. But corporates want a "webview" that is an OS so that they can do everything with Javascript on it (hence why embedded Chrome with NodeJS is so popular).
There does appear to be progress on making CEF an option.
https://github.com/tauri-apps/cef-rs
I wanted to try tauri out, but i couldn't get the nix dev shell for it working. My suspicion was that they do something too magical with the build process.
Glad to know that the pre-LLM-boom trend of just posting a rust library for karma is alive and well
Tauri existed well before the LLM boom.
for me the main thing about Tauri is not that it is built with Rust (that's interesting as well though)
but that it uses the webview implementation of windows and macos instead of bundling its own browser