wry VS webview

I thought so too at first. It is definitely something interfaced on top of Tauri[0] with some sort of 'server-side logic' framework[1]. But looking at Tauri's site, it is really hard to disentangle if PyWry is a binder about WRY[2] or not.

"OS-efficient cross-platform HTML-based UI toolkit" is a great technological thing, but neither PyWry and Tauri's sites make that clear, or meaningfully advertise what they do. Which is a shame, because there is myriad software which might benefit all to use this.

[0] Tauri is akin to Chromium, I think? https://tauri.app

[1] and also a rather large amount of LLM integration; the source for PyWry has a whole section for Claude bindings

[2] the Webview Rendering librarY (WRY) used in Tauri https://github.com/tauri-apps/wry

Yup, came here to say this. After reading the article, it became abundantly clear that the author doesn’t support Linux and most of the article is just a summary of the common Tauri talking points. But it’s out of date. To add data to this - Tauri is looking to allow embedding chromium as an option because the creator of Tauri acknowledged that it doesn’t work well on Linux. To the point where if Linux is a serious target, they don’t recommend Tauri: https://github.com/tauri-apps/wry/issues/1064#issuecomment-2...

The upstream projects aren’t in a place to support this yet so this feature didn’t make it into Tauri v2. I’ve been tracking this for a long time and hope that they will make it possible in v3.

In my experience with Tauri, it's pretty good on Windows, but not so much on other platforms, especially Linux. The decision to target different browser engines on each operating system means you still have to deal with a bunch of different OS-specific bugs.

For Windows you're dealing with Edge (so Chromium), on macOS you have Safari, and on Linux you have WebKitGTK. WebKitGTK has honestly abysmal performance, and you're missing a lot of modern standards.

The Tauri devs are looking at bundling a Chromium browser with it to deal with that, but that's still some time off, and leads to the same issue Electron has, where you have large bloated applications.

https://github.com/tauri-apps/wry/issues/1064

[2] https://github.com/tauri-apps/wry/issues/1064

It is becoming more and more applicapible to the Web... Servers and clients with #wasm, you can actually natively import a rust module into node.js for extra threads or heavy lifting. Start learning!

The biggest benefits we derived from Tauri were Wry and the sidecar mechanism. Wry (the second half of Tauri: tao/wry) is a cross-platform WebView rendering library in Rust that supports all major desktop platforms like Windows, macOS, and Linux. It essentially spins up a native web view from whatever operating system it’s running on and doesn’t require an application to bundle one with it. Wry greatly reduces the overhead of “pushing” a browser to our users, instead leaning on the host OS to handle rendering a web view. This made our applications really lean.

Check out https://tauri.app/ - specifically, https://github.com/tauri-apps/wry, which provides a cross-platform interface to the system's WebView.

Tauri uses WebkitGTK, which has pretty bad performance compared to other browsers on the same hardware.

https://github.com/tauri-apps/wry/issues/890#issuecomment-14...

"a thin wrapper over the system webview"

That is very complicated if you take into account also Linux, Windows, iOS, Android support and related utilities like tray icon, etc. There are other efforts, too, but they are also wrappers. Like this C/C++ implementation https://github.com/webview/webview that targets only desktop operating systems.

What do you mean by that? WebView is just Chrome embedded inside of an Android app. Same thing already exists on Windows (Edge WebView2), macOS (WKWebView) and Linux (WebKitGTK). There's also a library that wraps all of them into a single interface:

https://github.com/webview/webview

The entire point of WebView is that it's a browser embedded inside of a different application, how do you expect it to be a "standalone project"?

You can create the webview using each platforms native GUI toolkit and setup JS communication yourself OR you can use a lightweight library that does it for [1] (search its README for language "bindings").

[1] https://github.com/webview/webview

Each platform has it's own webview control available as a shared library installed with the OS.

MacOS has WKWebKit based on WebKit.

Windows has WebView2 based on Edge/Chromium.

Linux has webkit2gtk based on WebKit.

Tools like Tauri use a simple cross-platform single-header abstraction called webview.h[1].

Electron no longer allows Node.js to be called from renderer processes, all communication with Node.js is done via IPC.

In this case, why do we still need Electron? Why does it have to be tied to V8/Node.js?

The fact that Chromium Embedded Framework exists and is third-party makes me think that Chromium wasn't designed for being embedded, and Electron is filling that gap.

This is elucidated here further here https://trac.webkit.org/wiki/WebKit2:

> it's difficult to reuse their work...if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.

It makes me think that perhaps WebKit was the better choice for embedding. The fact that Node used V8 made Chromium the choice, and that Node being called from the renderer was the original way of working. Maybe because WebKit didn't have a build for Windows was an issue too...

But now that we have Bun, perhaps it's time that WebKit becomes that browser target of choice for desktop apps on macOS.

Unless WebView2 for macOS arrives, which would have a more sane cross-platform story. WebView2 has a very large feature-set though which make take a while to implement for macOS.

[1]: https://github.com/webview/webview/blob/master/webview.h

Nui could base on this in theory. Nui uses https://github.com/webview/webview under the hood, which provides browser windows for linux, windows or mac. Nui adds some cmake to make the "in-browser" and "main-process" part appear seemless, as well adding a DSEL for the "in-browser" view part.

WebView 7k

You mean something like this?

Golang can compile to windows statically, and on Windows those bindings are using the MSWebView2 API (aka Microsoft Edge webview).

I know that you can also compile the webview.cc into a dll specifically, and link against that. But I'd never done with Visual C++ because I am cross-compiling from Linux to Windows.

The README of the webview/webview project refers to the WebView2 SDK on NuGet, however [1]

[1] https://github.com/webview/webview#windows-preparation