SaaSHub helps you find the best software and product alternatives Learn more →
Webview Alternatives
Similar projects and alternatives to webview
-
-
AppSignal
AppSignal knows why the f*#k it crashed. Stop vibe-debugging. Every exception, every backtrace, grouped so you see patterns, not noise.
-
-
-
Servo
Servo aims to empower developers with a lightweight, high-performance alternative for embedding web technologies in applications.
-
-
slint
Slint is an open-source declarative GUI toolkit to build native user interfaces for Rust, C++, JavaScript, or Python apps.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
-
-
-
webui
Use any web browser or WebView as GUI, with your preferred language in the backend and modern web technologies in the frontend, all in a lightweight portable library.
-
-
-
-
qtwebkit
Discontinued Code in this repository is obsolete. Use this fork: https://github.com/movableink/webkit
-
Slint
Discontinued Slint is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript. [Moved to: https://github.com/slint-ui/slint]
-
-
go-astilectron
Discontinued Build cross platform GUI apps with GO and HTML/JS/CSS (powered by Electron)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
webview discussion
webview reviews and mentions
-
Building desktop WebView apps in Go without CGo
Glaze is a desktop WebView binding for Go. It is a pure-Go port of webview/webview built on purego, keeping CGo out of the picture. Each backend talks to the WebView framework the OS already ships -- WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows -- so nothing native is bundled.
- Webview – cross-platform HTML5 UI abstraction layer
-
Ported my C game to WASM, here's everybug that I hit
You can do things like this with a webview wrapper like https://github.com/webview/webview (e.g. native windows which host the operating system's webview widget). Of course a webview has a whole browser engine behind it, so it's not much different than Electron.
-
Tauri binding for Python through Pyo3
"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.
-
Show HN: Vaev – A browser engine built from scratch (It renders google.com)
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"?
- webview: Tiny cross-platform webview library for C/C++
-
Why Bloat Is Still Software's Biggest Vulnerability
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
-
Ask HN: Do we still need Electron?
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 C++ User Interface Library
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.
-
[Golang] Recommandation de bibliothèque d'interface utilisateur légère
WebView 7k
-
A note from our sponsor - SaaSHub
www.saashub.com | 6 Oct 2026
Stats
webview/webview is an open source project licensed under MIT License which is an OSI approved license.
The primary programming language of webview is C++.