Introduction

Now a days, It's very important to provide a Graphical User Interface (GUI) for the end user. Doing such a thing is not an easy task, especially if you plan to provide a cross-platform solution. Today we will have a look into 6 different solutions I found while searching for this problem, this solutions have the purpose of being cross-language as well.

From Scratch

One of the obvious solutions is to implement a webview from scratch, you can certainly implement a Win32 app with the new Chromiun Edge for windows apps, a Cocoa WkWebview for macos apps and a Gtk or KDE (which is basically QT) for linux. The problem arrives when you have to actually do It, It's a massive code base with a lot of repetition for each platform. fortunately I have already found a solution to that.

Webview

the webview library is a great solution if you just want a webview implementation and don't need all the other api of the system. If your are making a PWA kind app (like a email client), you should take a look into it. Server Side Blazor apps are also welcome, because this library also have a C# binding. This library implements the from scratch part that I have talked before, It has a implementation for windows (with the new Chromium Edge), one for OSX (using Webkit) and one for linux (also using webkit). If we are talking about compatibility, then a problem arrives, dealing with 3 different rendering engines (webkitgtk is not the same as webkit in my opinion) support for specific features that only exist in one Rendering engine may lead you to creating them from scratch from other systems. Not to mention that you don't have a api for open system dialogs and message boxes out of the box.

Chromium

For this solution I'm talking about the Chromium Embed Framework (CEF), which arrives to solve the compatibility problem That I mentioned earlier. It achieves this by providing the same rendering engine across all the supported platforms. The down side of It's that you will have to deal with the chromium engine, which is HUGE and slower than the system webview in some systems. Also, the QtWebEngine is based on the chromium project and super easy to use. example

Ultralight

the ultralight library is similar to chromiun in a way that it also implements the same rendering engine for all platforms, but It uses webcore and a custom render. This also solves the compatibility problem and also is more customizable (in my opion). The only downside is that It isn't a free solution, after you make a Huge amount of money with it, you will have to pay a License to use it.

Tauri Webview Rendering librarY (WRY)

this one is a new solution I found these days. The Taury framework is similar to electron, but It's more light weight. They have made a very easy to use api, and have a awesome performance. But we are going to talk about the WRY Library which is part of tauri, but only the part that handles the webview, It is similar to the first webview we saw, but different in the way that:

• It supports multiple webview
• In my tests, It were faster
• I Really like working with it But It doens't come free of work, you will have to implement a whole c api if you want to use it out of rust, and on top of that it also doesn't support the system dialogs.

QtWebkit

Lastly, the other webkit based project, QtWebkit. It is also very lightweight and fast, It also provides a cross-platform render and It has access to the system dialogs. The down side is that you will have to make a Qt App to use it. If you don't want to implement it, then you cannot use It

Conclusion

All the libraries I showed In this article are awesome, I specially already made apps with all of them, But my chosen one for today is the WRY library, I don't mind implementing system dialogs if I have to, so the chosen library for me is the one that is easy to use, the one with last boiler plate code and the one that provides more functionality. For my project the CEF, the QtWebkit and the Webview libraries would meant that I would have to change the framework I'm making my app own, would have to implement a lot of boiler plate code just to use it or just don't provide the functionality that the WRY library does. That's why my vote is for the WRY library