| |
| ▲ | jakelazaroff a day ago | parent | next [-] | | This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers? It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-... | | |
| ▲ | dfabulich 20 hours ago | parent | next [-] | | The platform webviews are significantly older/worse than typical web browser versions, especially on macOS and Linux. On macOS, the only way to upgrade your WebView is to upgrade your OS, which requires rebooting. Lots of people just don't bother. You can upgrade to the latest Chrome or Firefox just by downloading it (assuming they support your macOS version), and they auto-upgrade themselves pretty aggressively. On the web, very old versions of Safari (6+ years old) are a tiny fraction of a percent of your traffic; many web developers just ignore them. In a desktop app based on a WebView, ancient WebViews can be as high as 10-15% of your macOS user base. Ignoring them is not an option. On Linux, it's common for the major version of WebKitGTK to not upgrade at all except during major OS upgrades. Anyone on Ubuntu LTS 20 is going to have a 2020-vintage WebKitGTK with security patches. (And Ubuntu LTS 20's WebKitGTK was buggier than macOS WebKit, even in 2020, because Apple has more dedicated full-time developers and testers making sure that macOS WebViews work end-to-end.) If you're shipping an app based on WebKitGTK, you can expect to see double-digit percentages of your Linux users running really old WebKitGTK. Maybe you're such a great developer that your web app works great on ancient browsers, but, if so, it's probably because you didn't need/use much JS in the first place. (Maybe you used HTMX or something.) In that case, is there even any benefit in shipping a "desktop app"? What's your desktop app even for? Offline support? (But your app is all server side…?) If you have a JS-intensive app that works great on ancient, buggy browsers, then platform WebView might work for you. It's not nobody, but it's hardly anybody. | |
| ▲ | c-hendricks 21 hours ago | parent | prev | next [-] | | webkitgtk isn't just quirky, it's also much slower compared to more popular browser engines and is particularly bad with RAM usage. | | |
| ▲ | paddy_m 21 hours ago | parent [-] | | is webkitgtk different than the engine used in safari? | | |
| ▲ | c-hendricks 16 hours ago | parent [-] | | Not necessarily? As far as I know they come from the same WebKit source. But the bridge between WebKit and the OS is of course specific to each system. WebRTC is still experimental in webkitgtk while caniuse says Safari supported it back in 2017. I remember encountering one bug with Final Form that triggered rarely in Safari, 100% in Webkitgtk, and never in Chromium. Here's the developer of Tauri saying it's hard to recommend webkitgtk / Linux support: > So if you need good linux support now/soon i can't 100% recommend tauri (for Linux) as of now. (I used to be more "forgiving" but with webkitgtk getting worse/more unstable each release i changed my mind) https://github.com/orgs/tauri-apps/discussions/8524#discussi... |
|
| |
| ▲ | hdjrudni 19 hours ago | parent | prev | next [-] | | Yes, we're used to platform differences, but that's kind of the benefit of shipping a desktop app, isn't it? So that we don't have to deal with the platform differences. If you bundle the browser, then that ought to all go away. No graceful degradation necessary, no polyfills. | |
| ▲ | echelon 21 hours ago | parent | prev [-] | | > This point of view always confuses me, because web developers already need to deal with platform differences. On Mac, I use Firefox and Chrome. However, if I use a Tauri app on Mac, I have to use dated WebKit. It's out of a Tauri developer's control. | | |
| ▲ | jakelazaroff 20 hours ago | parent [-] | | > On Mac, I use Firefox and Chrome. Sure, but many people use Safari, which runs that exact same WebKit engine under the hood. So if your app is available in the browser in addition to Tauri, you have to support it anyway. And at the very least, you as a web developer should be used to supporting it. | | |
| ▲ | CJefferson 18 hours ago | parent [-] | | Many people run older versions of Mac OS X (because their machine won't upgrade), so their safari is aging -- they use an alternative browser, firefox and chrome support older mac os x. Of course using unsupported OSes isn't the best idea, but Apple give you security updates longer than they give you 'fun' safari updates. | | |
|
|
| |
| ▲ | synchrone a day ago | parent | prev | next [-] | | Regular Tauri app (aptakube) user on linux here: the experience is very adequate and smooth, I have no complaints.
Speed benefits relative to Electron (similar app: K8S Lens) alone are enough to deal with many possible issues. Could be attributed to app developers going the extra mile, but I suspect it's the framework choice. | | |
| ▲ | moogly a day ago | parent [-] | | Targeting and building Tauri apps for Wayland, specifically, is a massive headache due to assorted webkitgtk bundling/incompatibility madness. |
| |
| ▲ | oooyay a day ago | parent | prev | next [-] | | I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor. | | |
| ▲ | echelon a day ago | parent [-] | | Are any of your Mac users using an 10-year old WebView? We frequently ran into that. And there's nothing that can be done about it except engineering around it. I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator. | | |
| ▲ | larrysalibra a day ago | parent [-] | | Can you either at build time or runtime specify a minimum macOS version? No one running macOS 26 (for example) is using a 10 year old WebView. | | |
|
| |
| ▲ | cdud3 8 hours ago | parent | prev | next [-] | | Or use QtWebEngine which uses Chromium under the hood, provides a stable and rich API and enables sharing rather then bundling the browser runtime + is Cross-Platform + security updates are handled too. | |
| ▲ | FooBarWidget a day ago | parent | prev | next [-] | | Web developers already have to deal with different browsers, versions and API coverage. | | |
| ▲ | umpalumpaaa 12 hours ago | parent [-] | | The beauty of shipping a desktop app would be to not have to deal with that though… also those built in web views are usually older than average. |
| |
| ▲ | jauntywundrkind 19 hours ago | parent | prev | next [-] | | Tauri's cef-rs is indeed quite good. I think it's available, ready, works: it's just that there aren't many folks using Tauri and only a fraction of them are aware/interested in exploring further. https://github.com/tauri-apps/cef-rs Huge fan, this should definitely be the default. The user experience is incomparable. One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit. | |
| ▲ | v3ss0n 20 hours ago | parent | prev [-] | | LOL , then back to electron. I raised that since day one of Tauri. |
|
