“How is the SerenityOS team making such good progress on building their Ladybird browser, when we've heard for years that it’s impossible”?

I've seen this question a few times on sites like Hacker News and Reddit, and I thought I’d offer my own personal take on it.

From my perspective, it comes down to five main things:

1. Stronger web specifications

2. Focus on vertical slices

3. Deferring on performance work

4. Team culture

5. Having an experienced leader

Stronger web specifications

We’ve come a long way from the wishy-washy days of HTML4 and CSS2.1.

The ECMAScript, HTML, and CSS specifications today are (for the most part) stellar technical documents whose algorithms can be implemented with considerably less effort and guesswork than in the past.

The architecture of Ladybird tries really hard to match the architecture described in the various web specifications. This makes it significantly easier for new developers to get oriented, as they only have to learn one architecture instead of two.

There are still gaps though, and some features are less specified than others. Thankfully there’s an active community of editors at the W3C working on improvements. A fair amount of the work we do on Ladybird involves adapting our codebase to updates made by these spec editors.

We try to do our part in improving the specs as well: the Ladybird developers often report spec bugs, and sometimes make PRs to improve specs directly. Not to mention that implementing a spec in a novel browser engine provides great validation that the spec is actually complete.

Focus on vertical slices

While the specs today are indeed better than ever before, it’s still the case that many features span multiple specs, often with subtle interactions between subsystems that must be understood by an implementer.

If you tried to build a browser one spec at a time, or even one feature at a time, you’d most likely run out of steam and lose interest altogether.

So instead of that, we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives.

Working on a vertical slice helps maintain momentum and it's highly motivating to see tangible improvement on real live websites as they progress.

This approach is in part possible because the web itself is designed around graceful degradation, meaning that browsers can render web content while only supporting some of the features used by the site.

You might think this approach would produce a small collection of “compatible websites” and a vast desert of non-working things, but what really happens is that the rising tide lifts all boats, and as we focus on improving one website, thousands of other sites improve as well!

Deferring on performance work

We're currently not putting much effort into optimizing Ladybird for performance. Instead, our primary focus is on addressing issues related to correctness and compatibility. This approach helps us stay focused on making sure the browser works as intended before diving into optimizations.

It's not that we don't care about performance. We want our browser to be fast and responsive eventually. It's a matter of making a disciplined choice to not spend too much time optimizing a product that doesn't work correctly yet. For example, while we might identify areas where we could potentially optimize JavaScript execution or rendering speed, we consciously choose to prioritize fixing rendering bugs or compatibility issues with popular websites first.

We do make exceptions for things that are unbearably slow. We don't want working on the browser to be unpleasant, after all. In such cases, we'll invest time in addressing the most significant performance bottlenecks to maintain a tolerable development experience.

But we're not tracking benchmark scores and things like that at this stage. That day will come though, once we've achieved a solid foundation in terms of correctness and compatibility!

Team culture

In the time we’ve spent together working on this, a strong team culture has formed. The culture is highly optimistic and everyone has a “can do” attitude.

Although the team is distributed around the world, we all meet on Discord to chat and spur each other on. People frequently collaborate and pitch in on each other’s projects.

Everyone who works on Ladybird is encouraged to explore their own personal interests within the project. Most folks on the team had never looked at browser code before joining us, and they're quickly becoming world-class browser developers.

Also, since Ladybird is an offshoot from the SerenityOS project, it shares the same culture of accountability and self-reliance. We avoid 3rd party dependencies and build everything ourselves. In part because it’s fun, but also because it creates total accountability for what goes into our software.

Having an experienced leader

An experienced leader can make a significant difference in a project like this. I've had the opportunity to work on production browsers for many years (at Apple and Nokia), which has given me a strong understanding of how browsers are put together.

While other people may look at the huge stack of technologies and specifications that need to be combined to make a browser and feel overwhelmed, I’ve got a clear picture of how to put them together and make it work. We save a lot of time here by not worrying about whether it’s possible and just getting straight to the work instead!

In more practical terms, what I really end up working on is often between the seams — parts of the browser that are less rigidly specified (e.g layout & rendering). Those parts can be much harder for less experienced browser developers to engage with.

Conclusion

Although I don’t believe our exact way of working is directly transferable to other software projects (unless they are also browsers), with a small team of smart, focused individuals and a knowledgeable leader to guide them, you can build any software you want.