Servo VS wry

It's also the case that every feature in web standards means extra code that needs to be painstakingly maintained, and extra code that anyone trying to create a standards-compliant browser must implement. I want to see projects like https://servo.org/ actually have a chance to catch up over time, not always be chasing an expanding scope.

I want the web platform to have every possible capability that native platforms have (subject to privacy and sandboxing constraints, of course). And I want the developer experience of web developers to be incredible.

But these need to be balanced against the consequences of added complexity. And in this case, does native templating really improve developer experience? I'm not convinced the benefits outweigh the costs.

> 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.

[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...

One small note regarding Native Webview meant above. You can find ultimate information on this topic here. In a nutshell, Tauri applications use as HTML renderer Webkit (safari engine) on MacOS, Microsoft Edge WebView2 on Windows, and WebKitGTK on Linux (port of Webkit for Linux). Pay attention to the fact that a Tauri application could behave differently on different platforms according to the information above.

wry looks like a better choice, but no one has bothered to work on this task, yet.