I just don't get the point of ladybird.
They have full time engineers and are soliciting donations, so it's clearly more than a hobby project.
Maybe my assumptions are off, but I just can't imagine they could ever become competitive in terms of features, security and performance with the big engines. Blink is setting the pace, Webkit is barely able to keep up and Gecko is slowly falling behind. All of these teams are orders of magnitudes larger than the Ladybird team.
If you think that Blinks dominance is a thread to the web it's not enough to have an alternative engine you need enough adoption of that engine so web devs make sure their site is compatible with that engine.
Most of this also applies to Servo, but at least their technical project goals (embeddable, modular, parallel, memory safe) sound at least moderately compelling. Maybe Ladybird has similar goals, but at least their website doesn't really state any technical goals.
It is donation funded with no reliance on outside parties. They don't have to inject ads into pages like brave did or sell out to Google compromising their independence on web standards.
They're ahead of Servo already anyway, and better funded.
In the last 24h alone Chromium merged almost 900 CLs (their equivalent to a pull request) into the src/Chromium repo, Ladybird had 7. Yes a project that started fresh a couple of year ago with decades of hindsight can be more efficient than one started 16 year ago as the fork of a fork, but if I had to guess they'll sooner or later reach a point where they have implemented the low hanging fruit and chromium moves faster away than they can catch up.
I'm not even proximal to webdev, can someone explain why people keep making pages using new stuff? I get why google keeps adding things, but why do people use it? Well over half the pages I go to look better without js. HN looks identical.
Many of the newer standards added to the web platform boil down to supporting development of web apps, not only web pages. For example, the current iteration of the File System API in Chrome (https://developer.mozilla.org/en-US/docs/Web/API/File_System...) allows web apps to request permission to read and write to the user's file system. This is great for many tools.
Of course, this can be fairly controversial: More app-like capabilities lead to more complex standards and harder-to-secure browsers. There's also overengineering where people use web app techniques to develop web pages. You don't need (much) JS or even any of the new standards for HN, but for something like Google Docs or Figma, it's a different story.
A lot of the new stuff added to CSS in the last few years has allowed web devs to vastly reduce the amount of JavaScript and HTML cruft in our pages and make them much more semantic and accessible, reduce download size and increase render speed.
> Chromium merged almost 900 CLs ... Ladybird had 7
Imagine being in your annual review and your boss has a chart of your performance compared to your peers and it's just the count of PRs you merged. You begin to protest that merged PRs is not a good metric for contributions, then he switches to the next slide which is just this comment you made on HN...
Not being funded by Google money is a pretty big deal. Some of the developers are former webkit devs so they have a good foundation to start from. It remains to be seen if they can pull it off.
Orion adding Windows support (getting WebKit running on Windows again) would be pretty good too.
WebKit runs on Windows, the Windows port just needs work to bring it up to the level of the Linux port. I got every JIT tier enabled in JavaScriptCore [1] and enabled libpas (the memory allocator). The Windows port is moving to Skia in line with the Linux port.
Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.
In the update videos posted on the Ladybird YouTube channel it's said that they have exhausted most of the low hanging fruit in terms of correctness.
Browsers and the web standard have a very long tail of odd behavior that you need to implement.
I could be wrong, but if I had to guess they'll stall at a point where it's just good enough that some people will make it work, but it's not really useful for general use.
They're prioritizing correctness to the spec over speed and are still 'officially' in pre-alpha. It's still to be determined how well they can bridge the gap there.
For casual web browsing it's plenty fast enough already to do a lot of things, but they're a relatively small team fighting against decades of optimization.
What? No one is expecting Ladybird to be fast at this stage. No one is claiming that it is. Ladybird is competitive because of the speed of which it is improving.
Larger teams do not necessarily mean you get stuff faster. If anything after some point, a large team can be hard to get things moving and have tons of issues with communication.
Well Andreas Kling has worked on Safari and WebKit and (obviously) has talked to a lot of browser people. He knows what he is doing, and he frequently says that no one that has actually worked on a browser thinks it's impossible to create a new one, even with a small team (...of highly motivated and skilled people).
1) Apple and Firefox have enough resources to implement the most recent web standards. When you see a feature which goes un-implemented for too long, it’s almost surely because nobody was even working on it because of internal resourcing fights.
2) Devs aren’t created equal. It’s possible for a team of 8 people to be 10x more productive than another team of 8.
> When you see a feature which goes un-implemented for too long, it’s almost surely because nobody was even working on it because of internal resourcing fights.
Or because they are reluctant to implement it for technical reasons? Not every "standard" that gets thrown on the table and implemented by Google is a brilliant idea.
I think the browser attempts are all wrong trying to "cover all edge cases" they should focus on being able to transform any and all dark patterns down into something simpler.
Hell starting out as extracting text, pictures, video for all nightmare sites. Then slowly add whatever features dont actually lead to dark patterns
If anything, Ladybird is an independent implementation of the web standards, and the devs have identified and helped solving quite a few bugs and and ambiguities in the standards, which benefits everyone, from browser devs including the big guns to web developpers and users.
I have to be honest that I don't really understand the appeal of Ladybird from a purely technical perspective. It is written in C++, just like all the existing engines (yes there is some Swift, but it is negligible), so what benefit does it provide over Gecko or Blink? With Servo, I can see there is a distinct technical design around security and parallelism.
Many many factors to consider. Simplistic take: KHTML was picked up by Apple because of its clean design and codebase; there's an extra 30 years of accumulated improvements in C++; you don't write stuff in Rust 1.0 either.
Also: Andreas has worked on Webkit/Blink. He knew what he was doing when he started the project, even if it was "just for fun". Linux started under similar circumstances.
Linux started under circumstances of Linus wanting to learn 386 assembler. He got two processes writing alternating As and Bs to demonstrate 386 multitasking. Linus had to find SunOS docs etc to copy system call signatures from. It's truly an accidental success story, and while Linus is smart & capable he sure as hell did not "know what he was doing", the whole point was to learn and fiddle with it.
Starting a new browser project without a solid security architecture seems just a bad idea to me. It's such a hostile operating environment. Personal computing in the early 90s was a very different place.
Torvalds had his debate with prof. Tanenbaum (a specialist in OS research), stuck with his own opinions, and achieved an extraordinary success, continuing as a technical project leader and architect for 35+ years and counting. It's circumstantial, but not accidental.
There is more to a project this massive than its choice of language. For me though it's mostly about breaking from the monopoly and putting a check on Google's influence over browser space.
> There is more to a project this massive than its choice of language
For writing a game, or Figma replacement, or some cutesy something that runs on your machine without requiring network access, probably. For one of the most impactful applications that downloads untrusted code from the Internet and executes it without any confirmation whatsoever, the language for sure does matter. "Chrome RCE" is a phrase that strikes fear, and it's not a rare occurrence. I'll point out that Google is not lacking some of the most skilled security researchers and tooling in the world, so I wish the Ladybird folks godspeed doing their own "does this build have vulns?" work
Rust does not produce magic in the assembly code. It does not even produce faster assembly code. Rust toolchain on it's own does not even produce assembly code. It just passes that to LLVM that does THE ENTIRE optimization. Without LLVM (written in C++) doing the heavy lifting, Rust is probably slower than V8 (written in C++) running JavaScript. There's no technical marver in Servo compared to Ladybird. I don't understand the yapping how a language makes projects good/bad, despite it being proven completely false again and again. The appeal is in independence and politics around the project.
The express purpose of building Servo in the first place was to experiment with ways to parallelize the layout algorithm. The advantage of Rust is that it is a language which enables the compiler to better enforce some of the rules that need to be followed to write correct thread-safe code. Note that Mozilla had previously tried--more than once--to do the same thing in C++ for Gecko, and both attempts had failed.
As for the rest of your comment... I believe Rust now has MIR-based optimizations, so it's no longer the case that "THE ENTIRE optimization" is due to LLVM. But it's a non-sequitur to say that Rust would be slower without LLVM. Rust doesn't do many optimizations on its own, because it's quite frankly a lot of boring tedium to implement an entire optimizing compiler stack, and if you've got a library you can use to do that, why not? If no such library were available, Rust would merely be implementing all of those optimizations itself, much as V8 implements those optimizations itself.
I hope it succeeds. Now they allow direct donations, so people who want it to succeed can help. I am sure these donations go directly into the development of the browser unlike with mozilla.
Looks interesting, but they're going to try writing it in Swift?
If you're writing a browser engine in C++, I may not like it, but I can see that you're pragmatic and are focused on the end result rather than the language. If you're writing it in Rust, okay, you maybe have your eyes on that pie in the sky, but you've chosen a language that, at least potentially, has the ability to replace C++ in creating bedrock software.
Any other language and I feel like someone with a lot of political capital at the company just has a personal preference for the language and so, "yeah, we're going to rewrite it all in Swift"[0].
I mean, you're writing a browser. Do you really want to build it in a language that is at the "it's improving" stage of support for the most popular operating systems?
You should look into why they chose it and what their implementation plan is. They evaluated multiple languages, including rust. There were some specific issues with rust that made it unsuitable for them. Swift was a bit of a dark horse candidate that the developers ended liking.
There is no immediate plan to switch to anything so it’s still C++. They may not ever switch. Swift’s cross platform support isn’t there yet and that’s a prerequisite.
I'll see if I can find it. I don't remember the specifics on rust, but it sounded like they gave it a fair shot. It was basically the one to beat until they figured out it wasn't going to work. The decision to adopt Swift wasn't made on a whim and, frankly, I'm skeptical it will happen any time soon, if ever. I think it's one of those situations where they want to make it more accessible to a next generation of developers the same way Linux is adopting rust. Swift is actually a really nice language, despite being associated primarily with Apple. It would be cool to see higher adoption.
Ladybird has an interesting way of documenting web standards in code. They put a link to the reference doc at the top of a function and then each rule in a comment where it is implemented. It's very easy to follow and good quality code. Another project I recall having high quality code was KHTML. Not coincidentally, Andreas Kling worked on that one too.
Anyway, the point is what they are doing is working well and Swift won't be ready for a while. If it ever happens, it won't be a rewrite. It'll more likely be a situation where it's written in both the same way Linux is both C and rust.
Here are some key quotes:
"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."
"So what I’ve done is I’ve asked a bunch of people to “Please implement these things in a couple of different languages. And then we can talk about how that went, what you liked about each language, and which one you would like to work in every day.” And what we ended up with was that people were initially excited to work in Rust, because there’s a lot of hype, and it’s like a popular language… And you would think that it’s the greatest thing since sliced bread… And in many ways it is, if what you want is sliced bread. Or I don’t know where I’m going with that. But it works well for a lot of things."
"But it turns out it’s not ideal for building a browser… Because the browser stack sits on top of this API that was designed in the ’90s, inspired by Java and XML and stuff like that at the time. This ‘90s API, and it set the core of the web stack. And it’s super object-oriented, and it’s just hard to express all that stuff in Rust, because Rust doesn’t lend itself to object-oriented programming. It doesn’t have inheritance, for example, which is a very fundamental building block."
"And so what happened was I asked people to write in Rust, and they were initially excited, and then they came back frustrated. And nobody had a good time working in Rust, as far as I understood, when doing anything but trivial programs that like take an input and transform it into something else. The moment you try to model something, sort of in a browser space, it just became tedious."
"So we looked at some other languages, and the one that everybody has liked so far has been Swift. So it’s a bit of an unlikely candidate, but we decided to look at it, because it is a safe, modern language, that has great object-oriented programming capabilities. I would say it’s even better than C++ in many ways. And it’s a little weird, because it feels like an Apple product almost, but they’ve been making great strides on Linux and Windows. Especially now, the upcoming Swift 6 is looking like it’s going to be a really good release on other platforms as well… So that’s sort of where the ship is pointing right now. We haven’t committed to it, because we’re still figuring out how to do some things, but it’s been really positive, and everybody’s enjoyed working in it, myself included. It’s been fantastic. So that’s sort of what we’re looking at."
> This ‘90s API, and it set the core of the web stack. And it’s super object-oriented, and it’s just hard to express all that stuff in Rust, because Rust doesn’t lend itself to object-oriented programming. It doesn’t have inheritance, for example, which is a very fundamental building block.
That's a rather strange criticism, seeing as the only thing about objects that's slightly involved to express in Rust is implementation inheritance; and even then, it can be phrased in a very reasonable way by using the generic typestate pattern. I.e. expressing a class that can be inherited from as a generic object MyBaseClass<T>, where T holds the "derived" object state (and can itself be generic in turn, thereby extending the type hierarchy) and methods can either be implemented for any MyBaseClass<T> or for some specific MyBaseClass<MyDerivedObject>.
(This aims to do the right thing whenever a method on the base class relies on some method implementation that's defined deeper in the hierarchy, i.e. there is an indirection step, aka open recursion. That's the part that is missing when using simple composition.)
> I.e. expressing a class that can be inherited from as a generic object MyBaseClass<T>, where T holds the "derived" object state (and can itself be generic in turn, thereby extending the type hierarchy)
Interesting approach! Have you used this in larger project (i.e. for a larger type hierarchy)?
I suspect it might at least take some getting used to (readability-wise), plus it might lead to additional boilerplate in case some child "classes" only want to override some methods, but not others. (The parent will have to implement some switching logic.)
Overall I agree, though, I can't think of any OOP use case that could not be covered by this.
Ultimately I'm not dissuaded from my original impression.
I worked at a company doing web scraping, and our code sucked and we knew it, and the lead programmer kind of liked Elixir, and we were always going to rewrite in Elixir one day, and he would mention it in interviews and stuff, and put it on job requirements, but really there was almost no Elixir in the company. We came up with all sorts of reasons Elixir would make sense technically, I even offered some myself because I got positive social feedback when I spoke well of Elixir. But now that I'm out of the company, I can see that Elixir is not uniquely suited to solve the problems we had. It was just one guy liked Elixir and so ultimately we all did.
I still predict the same for LadyBird. You can even see in the Tweet I linked that they choose C++ because of one person, so I'm guessing that one person also likes Swift. Time will tell.
Or rather, the FAQ shows one influential person over language decisions:
"The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain."
