Bundle chromium renderer #1064
Comments
|
This is the crate that must be pushed forward to make it possible I guess Or hoping for a very far in time linux support for WebView2 |
|
I am circling back on this because it causes us so much pain on Linux that we are always discussing dropping Tauri because of it. I cannot overstate how bad webkitgtk performances are compared to browsers. |
|
We're aware of the situation and completely stopped defending webkitgtk ourselves. Sadly it is still a huge amount of work that we currently don't seem to be able to stem... Nonetheless, we do not see a future with webkitgtk. And i agree that using Tauri, or any similar framework using webkitgtk, is not a good idea for projects where Linux is a serious target, to a degree where i actively warn people about this (before the never ending webkitgtk-nvidia fiasco began i restricted this warning to performance intensive frontends but sadly we're past that now). My idea was to work on the webkitgtk 6.0 port (basically webkitgtk with gtk4) for tauri v3 and then some point after that look into cef again (my qt webview experiments never seem to work out 😩) if servo needs more time, but i've since changed my mind and will try my best to start working on an alternative for webkitgtk after v2 is stable. Hopefully to a degree where we can completely drop it but that may be a bit too optimistic. I also hope that @simonhyll is still interested in working on this too then ❤️ In the meantime, we can only apologize for any inconveniences (or worse) this caused any of you. |
|
Thanks for the answer @FabianLars, you guys are fighting the good fight. Honestly if Microsoft had any vision of would be awesome to have a webview2 standard across OS and it could be even a user setting (like use Firefox to provide webviews in my apps). Sadly we are not there yet. Seems like the latest webkitgtk shipped with gtk 4 support so there might be some improvements going there. But before that ships in the OS it is going to be years. That is kind of my main grip with native webview design, you often encounter really really outdated webviews even on recent machines and most of the time the user can't update it easily. CEF work I think is the way to go. Even better if the user can patch the chromium version without us. I know that for security oriented OS (like Parrot OS) the maintenance of electron apps is annoying because they cant easily patch the browser in case there is a critical CVE. |
Yeah, we hoped that they'd move faster on that part but even the macos port is still not public yet, though at least MS Teams iirc is using it now internally at least. Afaik planning for Linux still haven't begun.
Yeah, we were told that it's better, but the difference seems to be tiny. 🤏 Also it's not a trivial upgrade path on its own already, and additionally requires a complete rewrite of our tray implementation (because libappindicator requires gtk3) among other things.
True, but with our switch to webkitgtk 4.1 we've raised the minimum distro version already to the same versions that ship the gtk4 version too.
Yeah, ideally we could create a webview library out of it because each cef update by itself is technically a breaking change and could always break apps (to our current knowledge, though i hope i'm wrong and we can just share the lib files themselves between apps 🙏 ). Due to the urgentness of the situation imo we should get something working first even if the distribution method is not optimal. Appimages, our current main distribution format, require to bundle all cef libraries in it by design anyway. |
|
Fabian (not pinging cuz I'm quite a bit out of context with wry for a whole lotta time) |
|
There is a open feature request on Firefoxes feature request tracker: https://connect.mozilla.org/t5/ideas/create-an-alternative-to-electron/idi-p/268 |
We can't do it for / before v2. It's simply too much work and we don't want to hold back v2 any longer. |
While a Firefox alternative would be insanely nice, I highly doubt that we'll ever see anything close to it. Firefox' codebase is basically incompatible with this idea (and it's not like they're already overworked with just Firefox as a use case alone) |
Just wanna underscore that CEF definitely won't be in v2, hopefully it'll be in Tauri v3 or v4, depending on how fast Microsoft decides to come through on their promise of shipping WebView2 for Mac and Linux. Firefox definitely not happening since it's a browser not a webview, and Servo is years away from being an improvement over webkitgtk. |
I meant to just get the official cef that electron uses, at least on linux rn (ik there's a lot into it with the fact that most of cef releases is breaking) |
Electron doesn't use CEF, it's literally a custom build of the full Chromium browser. And there is no "just" with it, it's a huge undertaking, it can't be done for v2 both from an amount of work point of view and a security audit point of view. Earliest it can possibly happen is in Tauri version 3 |
|
@simonhyll Seems like I'm quite a bit out of context 😅 about the current state of cef, electron and tauri |
|
Is your feature request related to a problem? Please describe.
The performances of WebkitGTK are really bad and the implementation often breaks. It is also hard to test for app maintainers since nobody really uses it outside of some obscure default browser. It is also not on the MDN compatibility list for API.
For all those reasons, there should be an alternative
Describe the solution you'd like
For better or worst, shipping a chromium renderer like electron does is the way all big companies ship their app today and the reason is simple: it works great. The experience is consistent for the user and it's not a pain to QA.
I think wry should support bundling a renderer.
Describe alternatives you've considered
I know that there is talk to integrate servo into it, but honestly it doesn't solve the compatibility and QA issue outlined above.
It's not a bad idea per say, so if it can be done in a modular way (feature flag
servoandchromiumwith some traits on top) I think that would be great.Would you want to assign yourself to implement this feature?
I am happy to contribute changes since I kinda know the codebase a bit by now, but it's a big change. I don't expect this issue to move the team on a dime, but I wanted to start the discussion.
The text was updated successfully, but these errors were encountered: