Thanks. How much of the remaining missing support is necessary for pragmatic daily-driver use by computer nerds?
For what I have in mind, initially, a non-requirement is perfectly mimicking whatever someone managed to jam into a standard, unless it's really necessary to use "necessary" sites.
(Anyone who does a lot of blocking of ads/trackers will already be familiar with sites not being pixel-perfect.)
I'm thinking that bending over to mimick someone's big-moat browser behavior standards in every detail can be a secondary priority, for later, after nerds are already using it successfully as a daily driver.
Nothing says nerds can't keep a Chromium installed as an emergency backup, for trying that one demo that uses the latest thing Google-Microsoft is going to railroad into the standard, or for watching Netflix while traveling. (And for Web development testing, of course.) But otherwise, we should be dogfooding, like we had to do with Linux.
Seems like most nerds that are looking for an alternative browser engine are instead moving towards Ladybird.
Last year they passed Servo in WPT and recently passed Servo in stars.
As of January, Ladybird has been able to successfully render Gmail[0], so I imagine this year it will be able to solve most users daily-driver requirements.
Interesting. Has Ladybird solved memory bugs somehow, or is the situation going to be the usual constant security vulnerabilities and frequent security updates?
I have mixed feelings about Rust, but it's one way to improve the current culture of tolerating numerous memory defects in C and C++ desktop application programs and userland libraries. So that would be a point in Servo's favor, unless they've Rusted themselves into a borrowing/lifetimes/async development complexity corner that makes moving forward too slow.
I haven't seen anything on memory vulnerability issues. The project originated within a larger project to implement an operating system from scratch - including all dependencies (e.g. font parsing/shaping, image parsing, libc, you name it). That means that the project itself, and every single one of its dependencies, need to go through that whole cycle.
> I haven't seen anything on memory vulnerability issues.
The issue is that barely nobody uses the Ladybird yet, so there are zero interests for anyone serious party to test that security. So nothing gets published about the issues. I don't even know if Ladybird runs in Google's Clusterfuzz.
Memory safety is their long term plan (according to them), and they are going to use Swift for that. Let's see what happens.
Has/will Swift be sufficiently disentangled from Apple influence?
And is this redirecting open source in an essentially proprietary direction (which has happened many times), on the key piece of software that is the Web browser?
Why I'm asking: For a startup, I've used Swift (and SwiftUI, various Apple APIs, "entitlements", developer-hostile App Store experience, often nonexistent documentation). The core language is OK overall (not great). But most of the rest of the developer experience was awful, due to Apple. And you need a lot of pieces beyond the core language.
Ultimately, the people who fund/do the work get to decide how they do it.
I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
> I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
> Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!
> First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.
> Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
IME, Google Meet isn't the worst videoconf (that might be Microsoft Teams). Each one has problems.
But what's even worse than when company/boss mandates a bad or so-so videoconf product, is when you're doing partner/customer calls, and for whatever reason, you wind up using their preferred service. So you have to keep a few/several different ones working on your devices, poorly configured, and have many first time joining difficulties at the start of possibly important meetings.
Another time you need several videoconf is when job-hunting, and so many companies want you to use something different. And it's often shitty. And the first impressions can be high-stakes, while you're trying to get their shitty proprietary thing to work, even with Chrome or as an app you put on your sacrificial videoconf device.
This is a little tricky to solve entirely with open standards, but there's a reason we started doing open standards.
