Servo VS webview

> I mentioned momentum for a reason, servo doesn't have any. Ladybird however is extremely actively developed.

Looking at https://github.com/servo/servo it's very actively developed and gaining new contributors. The number of contributors for both projects is very similar. They are both active.

I felt like this link is missing some important context.

History: Initially started by Mozilla in 2012. They laid off the team off in 2020 and transferred the project to the Linux Foundation. Source: https://en.wikipedia.org/wiki/Servo_(software)

2025 Roadmap: https://github.com/servo/servo/wiki/Roadmap

At this point, I believe, it's important to accelerate development of Servo[1], which not only provides better browser security because of memory safety (getting rid of the stupid mistakes like OOB access or UAF), but is also managed[2] by Linux Foundation Europe[3], which gives more hope from the privacy standpoint.

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

[2] https://servo.org/about/

[3] https://linuxfoundation.eu/

I understand that people need alternatives that work now but please consider contributing your developer expertise and/or donating to Ladybird[0] / Servo[1]. We need to get away from our current engine monoculture of Chromium/Gecko (yes I know webkit exists)

[0]: https://ladybird.org

[1]: https://servo.org

Ladybird is lucky in that it has someone who knows how important marketing is, even for opensource projects. There are other opensource browser engine projects languishing because of lack of PR, patronage and / or volunteers. For e.g. NetSurf https://www.netsurf-browser.org/ - website is outdated because of lack of volunteers, but the project has active development - https://source.netsurf-browser.org/netsurf.git/ (already has partial support for CSS3, and Flex layout). Servo (https://servo.org/) is another but it gets some decent PR because of its Rust codebase and the Rust PR team.

It seems that they moved it since to a bigger meta issue and it's actively being worked on https://github.com/servo/servo/issues/30593.

https://github.com/servo/servo

Servo is upcoming, but so far it is fantastic in comparison to any other browser out there.

I tend to focus on any software that does not require 12 teams of people 6 weeks to determine how to build a single binary because of the use of 20 different programming languages and mixing and matching of paradigms and solutions to subconponents.

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

The author shrugs off web tech (maybe because of electron bloat?) but you can avoid the bloat by using each platforms native web browser control. There are even cross-platform libraries that make creating the native control and cross-communication simple. These applications would be architecturally similar to Win32 apps using and communicating with a XAML Island, but the advantage of web tech is it's an open standard and WPF/WinUI is not.