The Linux port of Orion (Kagi’s power user oriented web browser) is built with WebKitGTK, some hopefully the Orion team will be patching up some of the more glaring issues. At minimum the port will put it in front of pairs of eyeballs that hadn’t been looking at it before which should help bring attention to bugs.
No. But also, nobody(first order approximation) uses Gnome web. I would wager most javascript web apps don't work on that browser anyways due to webkitgtk. The most popular gnome distros all come with firefox installed so even the "just use the default" folks won't be using gnome web.
WebKitGTK benefits from sharing a codebase with WebKit for iOS, which web developers do care about supporting. There can still be bugs in the Linux-specific platform integration code, but that's not most of the codebase, so any given app is less likely to run across a bug in it. It's not as reliable as more mainstream browser-OS combinations, but saying that most apps don't work is an exaggeration.
Last I checked, WebkitGTK does not have parity with WebKit on iOS, and plenty of devs do test on that platform anyway - so I'm not sure what you're talking about? You're right to correct someone saying _most_ apps don't work, but it's also not cool to just sweep the WebkitGTK issue under the rug and pretend it's not an issue at all. It's bitten plenty of people who build on Tauri.
Additionally, the issues people find with WebkitGTK/Tauri aren't always web related, usually moreso Linux related (weird blank screens, issues with rendering certain stacked items, etc).
Gnome Web sucks, it has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
The thing is, Firefox/Gecko isn't embeddable (probably the one of worst tech blunders ever). I wonder if Tauri could wrap around Blink, instead? Then your app could just ask for Chrome to be installed.
The modern Qt web view component, QtWebEngine, is actually Chromium-based. So you could imagine a Tauri which uses Qt instead of GTK and uses QtWebEngine as its renderer instead of WebKitGTK.
Gnome Web sucks, it's has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
The Linux port of Orion (Kagi’s power user oriented web browser) is built with WebKitGTK, some hopefully the Orion team will be patching up some of the more glaring issues. At minimum the port will put it in front of pairs of eyeballs that hadn’t been looking at it before which should help bring attention to bugs.
It's awful. I'm cautiously optimistic (hopeful? naive?) that progress on servo will make it unnecessary!
Is WebKitGTK as used by Tauri worse than WebKitGTK used by a web app user's web browser?
No. But also, nobody(first order approximation) uses Gnome web. I would wager most javascript web apps don't work on that browser anyways due to webkitgtk. The most popular gnome distros all come with firefox installed so even the "just use the default" folks won't be using gnome web.
WebKitGTK benefits from sharing a codebase with WebKit for iOS, which web developers do care about supporting. There can still be bugs in the Linux-specific platform integration code, but that's not most of the codebase, so any given app is less likely to run across a bug in it. It's not as reliable as more mainstream browser-OS combinations, but saying that most apps don't work is an exaggeration.
Last I checked, WebkitGTK does not have parity with WebKit on iOS, and plenty of devs do test on that platform anyway - so I'm not sure what you're talking about? You're right to correct someone saying _most_ apps don't work, but it's also not cool to just sweep the WebkitGTK issue under the rug and pretend it's not an issue at all. It's bitten plenty of people who build on Tauri.
Additionally, the issues people find with WebkitGTK/Tauri aren't always web related, usually moreso Linux related (weird blank screens, issues with rendering certain stacked items, etc).
Gnome Web sucks, it has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
> Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
I have one such device and Firefox and Chrome also run on it. They're slow but still usable.
But the thing is, if you're using Tauri, you control the web app. So you need to test it on WebkitGTK, I guess that's the extra burden?
Have you actually tried deploying to webkitgtk ever?
Good luck "testing" your video conferencing app on webkitgtk - it doesn't support webrtc! It is still useful to test your error page I suppose.
Note that this is one example among many of missing features, bugs and/or horrible performance.
Here's a preview: no notifications, no :has, no TLA.
(Not blaming the epiphany devs for the situation here to be clear)
The thing is, Firefox/Gecko isn't embeddable (probably the one of worst tech blunders ever). I wonder if Tauri could wrap around Blink, instead? Then your app could just ask for Chrome to be installed.
The modern Qt web view component, QtWebEngine, is actually Chromium-based. So you could imagine a Tauri which uses Qt instead of GTK and uses QtWebEngine as its renderer instead of WebKitGTK.
Ahem https://github.com/tauri-apps/tauri/discussions/8426
That's a significant amount of workaround for something that "just works" elsewhere (and if I'm reading correctly doesn't work under Wayland).
It proves what everyone knows: that there's no reason WebRTC can't work in Tauri/Linux environments.
It also proves the point here: there are legitimate issues with the system-provided webview approach that are not always apparent.
Gnome Web sucks, it's has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.