All right, let's see if that works.
It does.
Awesome.
Hello everyone.
Thank you so very much for coming here.
It's a very full room.
So please make sure everyone has a seat.
I am Jelle Rheimhakis.
I'm from the Netherlands.
I've been working on a ladybird for the last year.
And before that, I've been working on surrender to US.
I'm the CEO of the ladybird browser initiative.
I'm also a developer, maintainer.
And you can find me here. Come back to me there.
So let's talk about ladybird.
Ladybird is something that has an origin going all the way back to,
about 2018, 2019, where my colleague Andreas Kling started
the personal project of his called Serenthio S.
Basically an operating system from scratch with the not invented
here syndrome as mantra.
Basically everything needed to be written from scratch.
No third party source code.
And at some point he thought, well, I need some component
in this operating system for rich text display editing.
What better way to do that by using HTML as CSS?
So this is actually one of the first screenshots that he made
of this new rendering components or rendering library.
At that point called lip HTML.
And as you can see, in the very simple thing,
just interpret some CSS, display some divs, and there we are.
We have our first fully fledged browser.
Of course, it took some more work to get to a point where we could actually
display websites.
So a lot of people joined in on the Serenthio S project.
And at the Serenthio Browser, as it was applicable,
I was able to display some fairly complex websites.
So we were able to, well, through with all this the old version of
this bit simpler, but yeah, it started to work.
Which was pretty awesome.
We could start slowly start logging in on websites and interact
with them, display all the difficult things that we normally wouldn't
be able to.
So this was starting to look like a real browser.
Then in 2022, we got to the point where as at one and as a tree
were pretty much tackled, as you can see.
And for the ones of you that don't know, as it is a sort of a compliance
test, how well do browsers conform to certain standards and
certain expected behaviors.
And getting to this 100, 100 score at the Assetary was a really big
undertaking.
Then the same year Andreas decided to continue the work on a
huge Chrome to basically separate it out of the operating system into
a Linux app.
And that's this.
This is one of the first screenshots that we made of the
huge Chrome when started working.
It came to life and this helped immensely with the iterations
because when we were building the operating system and you would
need to change something in the browser, for example, we would need to
compile everything.
So this was just a browser, iterations were much faster.
And everyone really liked working on a separate application like this.
Then in 2024, Andreas came into contact with Chris Wantrath,
founder of GitHub, to start a new initiative, the
Ladybird browser initiative.
Basically to safeguard some of the principles, everyone around the project
would like to have for Ladybird and to have a place to get funding,
and to make sure that that funding gets to the right people and right
places.
So what are those principles behind Ladybird?
We are building a new web engine based on web standards.
A new web engine as in, we're not a programming for.
We don't wrap programming.
We're not gecko.
We're not Safari.
We're something completely new.
And we are basing it on web standards.
There's been a lot of work in writing web specifications in the last years,
and we have tried to use these as much as possible.
I'm sorry.
Oh, yeah, go ahead.
We've been trying to use these as much as possible to build Ladybird.
We're not going to monetize anything around the browser.
We're not going to sell it.
We're not going to sell user data.
We're not going to accept default search deals.
We're going to rely on donations and sponsorships.
And we try to become as independent as possible by making these donations
and sponsorships no strings attached.
Meaning we will accept your money, but we can't promise anything.
We won't do anything for the money,
except what the initiative thinks is right for Ladybird.
And our goals with Ladybird are to render the actual live web
with acceptability, security, and performance.
Well, of course, you need to be able to use it.
And this is a huge task.
We want to advance the web platform by implementing and improving
graphics.
So we've been using these web specs.
We've been giving back to the communities around these web
specs by reporting bugs, by sending in improvements.
And of course, we want to increase
the web engine diversity.
Because everything has become one big Chromium Gecko Safari world.
There are some new engines out there, but we think we can
speed things up a bit.
And we would like to have a lot of fun while doing so.
And we are.
So what's the timeline here?
We are there.
Next year, we're going to have an alpha release.
It's catered towards the technical people.
And it will be for the Linux and macOS platforms.
Windows will be there at some point, just not yet.
And the next two years will see a better release and a production
list for all platforms.
So, well, we, so let me just give you a quick demo on what
we can do.
For people who don't know, we have this browser that just,
well, I don't have Wi-Fi here.
Okay, let's skip the entire demo there.
I'm not going to set up Wi-Fi in my precious minutes.
But websites like FOS them and Swift and even
shader toy are just working.
Since a couple of months we've had major improvements in web
GL and shader support.
And of course, at some point, we need to support web
GPU.
All the things that we need in an actual browser
are starting to become a life.
Basically.
And even more complex websites like this course start
working in Ladybird.
Of course, this all takes a huge amount of effort.
And one of the things that we've put a lot of effort in is
LipGH, which is our JavaScript engine, which was originally
started in Serenity OS.
Of course, and it found its way all the way up to Ladybird.
And this is the results from test262.fi.
Which is a overview of the ECM-A262 test suite results.
And currently, we're on top, meaning that according to the
ECM-A262 spec test, we are the most
compliant of all JavaScript engines out there.
Which is pretty nice.
Woo!
Then there's another test suite called the web platform test.
And the web platform test is a interoperability test suite.
Basically, taking things like all the specifications that are
out there and building tests that try to see if browsers are
adhering to these specs.
But also some behaviors that browsers accept that
that seem to be pretty common.
There might not be a spec for that, but we might want to have a test
for that to make sure that if you're building a browser, then
how sure are we that you're actually behaving like the other browsers?
Well, for us, that's really important.
So we have built a web platform test runner.
And we run this for, well, basically as fast as we can.
It takes a couple of hours to run the entire test suite.
That's about 2.1 million tests in the suite.
It's about 600K of those tests are encoding tests.
So it's a large part of those are actually pretty easy as long as you do
encoding correctly.
But as you can see, currently there's a sort that we're behind
Safari and we're before Flow and Server.
We actually switch place with Flow last month, I think.
But we're getting there.
And this graph, this bar of us is growing faster than all the
other browsers are in the web platform test suite.
So this is a really nice way for us to not only see what we're doing
if that's all right, if that's correct for what we're doing.
But also to display, to show to other people what we're currently achieving.
Yeah, so a quick overview of Lady Bird.
It's a full-set browser.
It's written in C++.
It's licensed under 2BSD.
And our goal is to write all the web deck from scratch.
And by that I mean, if something is inherently a web technology,
then we want to write that from scratch.
We're not going to use other code.
We're not going to copy anything.
We're not going to steal anything.
We're going to just dive into the specifications that are out there
and write it ourselves.
Of course, some things you could consider to be not web technology.
And for us, that means things like to the restoration,
audio decoding, image decoding.
Those are all things that we consider.
Well, that's something that more applications use.
That's not something that's just for a browser.
For that, we do want to use third-party libraries.
So that's a divergence from SerenteOS where everything was nothing
vented here.
This is something where we make use of accessing libraries.
Which helps us a lot in gaining some speed, gaining some momentum
to getting a browser where it needs to be.
And currently it runs on Linux and Mac OS.
Well, something I'd like to highlight is our multi-process architecture.
It's very simplified, but basically what we're doing already
since the browser was built in SerenteOS is we have multiple processes.
And every dotted outline here is you could consider a process.
And these processes talk to each other using IPC.
So for the Chrome, we have a queue to the Chrome.
We have a packet Chrome.
We have a hadless binary.
Those use live web queue in some form or another to talk to the other processes
to display a website.
And how it does so is by using, for example, the request server, which is
responsible for performing requests.
I make sure that everything is sent back neatly in the right order to the process.
We have web content, which is responsible for interpreting the DOM.
The CSS object model.
Layout, painting, and basically it just provides us with a bit map to display.
We have image decoder.
Also provides us with images of images to display.
When we want to decode the JPEC or PNG, it goes in there.
So that's an interesting one.
So for example, let's consider the fact that we're using third-party libraries.
Let's say that there's a security vulnerability in one of those libraries.
We will have contained this vulnerability, hopefully, in that process.
It will not reach the web content part.
It will not reach the user part.
And for example, service workers also run in a separate process.
Both the web worker.
And of course, a lot of future work still to be done.
We want to write new code in Swift.
We have to make sure that the interoperable C++,
considering our garbage collection, it's working there.
We need to do a lot of things like supporting media extensions.
At some point, we want to be able to use Spotify or Netflix in Ladybird.
We need to support that.
We need to do a lot of work in our security model in prevention of fingerprinting of the browser.
And at this point, I would have loved to give you the demo,
but you would have seen that not everything is as fast as it should be.
We still need to do a lot of work in the performance department.
And in the end, because we're working with specs, these specs will be improved.
There will be new proposals out there.
We'd like to implement new proposals as soon as they're out there,
as long as it's a sensible, implementable proposal.
So we need to stay on top of that.
And this is probably something that we need to do for the next couple of decades.
And that's it.
That's Ladybird in a nutshell.
If you'd like to know more, please contact me. I'll be here around this room somewhere.
Thank you very much.