The future of wry

[wusyong]

There were a few features and backends available when I was building wry at the beginning, but I didn't choose them for a few reasons. Some reasons are personal, some reasons are because they didn't align with the project well.

When I created wry, I just wanted it to be a helper crate for everyone to create windows and access the web. The idea is simple: create a winit window and embed the webview library. My vision for the crate back then was to make it modular and let other GUI crates utilize it.

But of course, a lot of things happened. At that time I was eager to participate larger open-source project. I moved wry under Tauri organization. After years of maintenance, wry is very complete for me. But I understand people also had various expectations for it. So I would like to take this chance to state the change wry could go in the future, and a little bit of history on why I didn't choose them before.

winit

The first is switching back to winit crate. The reason we had to fork winit to become tao crate is that it lacked a few general features a GUI application should have. For example, on macOS, winit didn't have methods to add menu, but the menu bar on top of the screen is essential to a macOS application. Even native keyboard shortcut is done by triggering menu items.

And winit didn't have a GTK backend either. Many GUI features are missing if you just want to use x11 and Wayland, such as menu, system tray, file picker, dock progress bar, and even more. So the decision back then was forking it.

The good news is winit started to accept more possibilities and they are open to adding features we want. They even considered adding a GTK backend. The bad news is we got sunk by the heavy workload of moving Tauri forward. The progress on switching back is pretty slow.

Nevertheless, @amrbashir managed to move everything related to menu into one single crate muda. Even winit can use it already. I think what we should do next is try to make a GTK backend for winit. We can start with a fork first with version matches with winit version.

But it will still be difficult to completely switch back to winit if we want to keep supporting Tauri. I think the more reasonable steps could be an additional feature flag in wry to let people toggle it. There are still some unresolved questions like how to optimize GTK backend for winit and how to maintain it. Considering the maintenance in winit isn't easy.

WPE

Another possible webview backend on Linux is WPE. It's a non-GTK version of webkitGTK. I didn't choose this before because of the reasons I've mentioned above. But GTK on the other hand is also very difficult to work with. It can only work on main thread (or the thread you init GTK). It's also a callbacks hell which is difficult to pass or share states in native rust. So I think at some point it's still worth exploring this further.

The most difficult part is probably adding wrapper crate and support the winit window. You will need to generate the gir files manually and create the bindings yourself. We have a Github discussion about this. Despite many GUI application features will be missing in this way, it could benefit winit community a lot without GTK shenanigans.

CEF

And there's CEF which is the most wanted backend from the beginning til now. The reason I didn't add it is personal: I just don't want to use Chromium. I use Firefox as my daily driver, and I wish we could keep the web open and free. One of the goals for the project is hoping it could also help push this a bit.

This is probably the main drawback of Tauri. The performance of webkitGTK isn't that great compared to chromium. webkitGTK also lacks some advanced web API like WebRTC and multimedia.

And after years of maintenance, I feel like it's actually reasonable to support CEF on Linux. There are so many distributions and package formats. Developers will end up bundling every dependency binary into their application. We do support deb format, but it also requires a few newer libraries like glib. If you only provide deb, that means you can only guarantee latest Debian based distributions are working. So developers usually will have to choose AppImage, Snap, or Flatpak to bundle their applications which usually include whole dependencies.

Of course, we could try to support as many formats as possible, but we only have a few maintainers to work on it. Right now, only flatpak remains as potential future target. Other than that, I think exploring CEF could actually help the community. I already created an initial bindings crate cef-rs. But I hope it can have a test suite just like ceftests first which doesn't seem like an easy chore. If you are interested in this, feel free to help look into this part.

Servo

servo is actually the initial goal and target of wry. But at the time I figured it out its layout problem, servo team had already been laid off. I have dreamed about using pure rust web engine for years, but there are a lot of missing implementations in Servo, either layout or WebAPI.

The good news is there's a resurrection of servo this year and it's a tremendous work. Though it still lacks of many implementations to be a useful webview, it's still possible to use servo to create amazing web pages (with good old html/css/js). I think maybe we can create a basic framework for servo first. Instead of being a production-ready tool, we can create a foundation that is easy for developers to play with first. There's already a PR to make a minibrowser using winit and egui. I'm really looking forward to see this port moving forward.

Summary

So here are all possible features and backends I could think of for wry in the future. However, I have decided my interests in next few months. Many targets I mentioned above will remain unimplemented. But if you are interested, welcome to keep the discussion or open a formal feature request. I will try my best to give anything I understand.