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!
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 :(
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. :)
> 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..)