awesomekling

Very interesting, I was not familiar with your project. Thanks for sharing it here!

Whatever happens, large parts of the codebase + dependencies will be C++ (or C) for the foreseeable future.

We're working on integrating with Swift, but despite the team's earnest efforts, Swift/C++ interop is still young and unstable.

On a personal note, I'm increasingly feeling like "C++ with a garbage collector" might actually be a reasonable tool for the task at hand. Watching the development of Fil-C in this space..

This is awesome! Really great write-up, and solid work by Jessie :^)

The Ladybird codebase is generally very defensive, but like every browser, our JavaScript engine is slightly less so (in the pursuit of performance.)

There are architectural lessons to learn here beyond just fixing the bugs found. We've since replaced these allocations (+ related ones) with callee-specific stack memory instead of trying to be clever with heap allocation reuse.

We're also migrating more and more of our memory management to garbage collection, which sidesteps a lot of the traditional C++ memory issues.

As others have mentioned, sandboxing & site isolation will make renderer exploitation a lot less powerful than what's demonstrated here. Even so, we obviously want to avoid it as much as possible!

Can confirm, am incredibly excited to talk browsers and discuss how they work!

(Hi Pavel, love the book!)

Oliver (the main developer) just announced that they’re going to work full time on Porffor: https://x.com/canadahonk/status/1818347311417938237

Which part, the nonprofit or the permissively licensed codebase? ;)

I’m still the BDFL but my role is evolving a bit as I’m now also running the nonprofit.

We are definitely a stripped down operation, and we will spend as much of our funding as possible on engineer salaries for the foreseeable future.

We’re always open to new developers! Find a website that doesn’t work right, then try to figure out why, and see if you can fix it :)

The best for a beginner is usually to start with some simple page you made yourself, since you know how it’s supposed to work, and can debug more easily.

And come join us on Discord, there are new people getting into the codebase all the time :)

Please don't trust random distro packages of Ladybird, we have no idea what they're packaging, but it's unlikely to be current, and not something we can help you with.

I wish distros would not package pre-alpha software, since the only thing it accomplishes is giving people a bad first impression of something that isn't ready :(

If you want to mess with Ladybird, build it from the source at https://github.com/LadybirdBrowser/ladybird :)

We will absolutely have the ability to block ads. The web is downright unpleasant without this feature!

Yes! I'm already working on it full time, along with 3 employees. In the next month, we are bringing on 3 more.

Given the limitations of our funding model, we won't be building a huge team, but rather a small team that allows us to maintain a runway of at least 1.5 years. :)

Yes, our next language will be a memory safe one.

We've committed to this in our application for tax-exempt status, so it's something the organization will be stuck with. :)

> What do you think is going to be the first milestone where Ladybird is going to be able to be a real alternative (even if limited to certain use cases) and in what timeframe do you think this can be accomplished?

At the moment, we are focusing primarily on our own use cases as developers, since those are the easiest to test and qualify. So websites like GitHub, web specifications, MDN, etc. are likely going to be very high fidelity before other parts of the web catch up ;)

> Also, do you already have any plans or ideas for how to improve the web browsing experience beyond what existing browsers provide or is your focus entirely on the engine catching up for now?

We are definitely focused on the engine catching up right now. There is an incredible amount of work to do, and we're doing the best we can :)

These days, all major browsers are taking interoperability very seriously. There’s even efforts like the annual “Interop 202x” where people vote on which interop bugs browsers should focus on fixing.

We benefit greatly from this of course, and we will do what we can to contribute when we’re mature enough!

That said, there will always be websites relying on bugs, and for that we will need a way to selectively emulate alternate behaviors in some cases. We are looking at a few different solutions for this but it’s not a huge priority right now as there are far lower hanging fruit in front of us.

That was a long time ago indeed! To be honest, I think I was partly saying that because I was scared of the idea of supporting the entire web platform. It seemed so far away at the time. :)

Going forward, we want to support the open web as it exists, so you can actually use Ladybird to interact with all your websites. We may not agree that every web platform API is awesome and perfect, but we will honor the open standards to the best of our ability.

1. We are not focusing on legacy hardware support. Given our release date is far in the future, we are mainly targeting the kind of devices most people will have a few years from now.

2. No concrete plans, but it's not outside the realm of possibilities.

There are a ton of standards at a glance, but when you look closer, you realize that much of it isn't implemented by other browsers either, and you only need a fraction of it to render 90%+ of the web. The last 10% will be a huge challenge, but we've got a long way to go before then.

The JavaScript engine is our own LibJS, currently sitting at 94.3% pass rate on https://test262.fyi/ (although the number might be a little outdated, it's supposed to be higher! Need to investigate this..)

With a simple two-part strategy:

1. We keep the team small enough that there's always at least 1.5 years of runway in the bank.

2. We continue fundraising actively.

We have not been debating this publicly as it has a 100% chance of devolving into a bikeshed discussion :)

Yes, we are aware of how permissive licenses work.

If someone forks our code and does a better job with it than we do, fair game. :)

We will never charge our users, or attempt to monetize them in any way. Our nonprofit will run on unrestricted donations only.

Indeed, Shopify was our first major sponsor, they signed up almost a year ago! I'm super grateful to Tobi for believing in us when we were even less mature than we are today. <3

Thank you for making the website! :)

Yes, but not automatically yet! We are actively working on our WPT infrastructure (which relies on a full Web Driver implementation) and running it manually at the moment. Once we've got it stable and automated, we'll look at pushing results to the common dashboard at https://wpt.fyi/ :)

That's right. The Ladybird Browser Initiative will only accept unrestricted donations. We're missing out on a fair bit of money this way, but we believe it's the right path for us.

To be honest, we are so far behind everyone else today that we're 100% focused on catching up technically, and not thinking much about differentiation. :)

That said, I do think we'll find ways to differentiate given our uncommon situation with no ties to the advertising industry. This gives us the ability to experiment with privacy measures more aggressive than others may be comfortable with for fear of losing funding, for example.

I can't speak for Servo, but my understanding is that they have very different goals than we do.

Servo wants to build an embeddable engine for controlled sets of HTML/CSS/JS content, with a focus on modularity and parallelism.

Ladybird wants to build a usable browser for the open web, warts and all, with a focus on compatibility and correctness.

I'm a big fan of Servo and I hope they become a huge success! Competition and new ideas in browser engines will benefit all of us! :)

It's an unmaintained prototype without anyone actively working on it.

Once we get the desktop version into decent shape, we will direct more attention to mobile platforms. At the moment there's just too much important low-hanging fruit that's easier to develop (and debug!) on desktop :)

Thanks F3nd0! There are currently no plans to switch to a less permissive license.

And we're perfectly happy using proprietary services like GitHub and Discord as long as they make our work easier and more enjoyable. We recently evaluated a number of alternatives, and found that they all introduced more friction than we were comfortable with.

Although the task of building a browser is itself challenging, we're a pragmatic project :)