Early stages of Google Docs support in the Ladybird browser
twitter.com
twitter.com
Fixing a CSS layout bug found by chessboard.js - https://www.youtube.com/watch?v=bMpLiEgKC_w
Let's make "Cookie Clicker" playable in Ladybird! - https://www.youtube.com/watch?v=W4SxKWwFhA0
He's very good at articulating his thought progress and it's always really interesting to see how he reduces the bug down into a minimal reproducible example.
Github.com on Ladybird, new browser with JavaScript/CSS/SVG engines from scratch - https://news.ycombinator.com/item?id=33273785 - Oct 2022 (1 comment)
Ladybird: A new cross-platform browser project - https://news.ycombinator.com/item?id=32809126 - Sept 2022 (473 comments)
Ladybird: A truly new Web Browser comes to Linux - https://news.ycombinator.com/item?id=32014061 - July 2022 (8 comments)
Ladybird Web Browser - https://news.ycombinator.com/item?id=31987506 - July 2022 (2 comments)
Ladybird Web Browser – SerenityOS LibWeb Engine on Linux - https://news.ycombinator.com/item?id=31976579 - July 2022 (2 comments)
I never managed to build Firefox nor Ungoogled-Chromium.
I'll give this new browser a try.
And while I haven't tried Ungoogled-Chromium, for unrelated reasons I helped an OSS project build their Brave-derivative in a container, so that may interest you: https://github.com/imperviousinc/beacon/blob/main/Dockerfile The only reason it's not already GitHub Actions for them is the chromium_src is 38GB and GHA cache is capped at 10G, but while digging up the link to that Dockerfile, I was reminded that there is a GHA for the macos build: https://github.com/ungoogled-software/ungoogled-chromium-mac...
EDIT: Lots of great answers. Thanks everyone. Glad this inspired such lively discussion.
Edit: the point is that its an independent browser, not that its built by just one person
This is impressive as a group of random interested people have made significant progress to making a functional web browser off the back of passion, not billions of dollars. Andreas has be an incredible force for showing what bringing people together through passion and openness can do.
Maybe the text you read refers to the OS itself and all first party software being written without external dependencies?
[1] See previous discussion at https://news.ycombinator.com/item?id=32809126
Edit: And I would say to others, please don't downvote a question because I think it was genuine and not meant with malice - and provides a good learning opportunity for EVERYONE
> It is impossible to build a NEW browser given the complexity and huge history
Building some browser is certainly possible. What's difficult/impossible is to build a browser from scratch which runs 99% of existing websites correctly.
> browsers need to rely on JIT and other tricks
... to be fast in today's JS-rich websites. I believe that as well.
It took Mozilla more than 25 years to write Firefox's HTML engine and here are a couple of geniuses who write a web browser from scratch in just a few years!! Including Javascript (however, as of yet lacking video and WebGL).
And Google's Chromium is simply a convoluted mess, chockful with vulnerabilities and memory corruption errors.
Chromium's HTML engine derives from an open source KHTML engine, written for the KDE project.
Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.
https://chromereleases.googleblog.com/search/label/Stable%20... and control-f for "High CVE"
This from the company with arguably the best security researchers on Earth, and probably unholy amounts of internal fuzzing and static analysis tooling
Having said that, Gecko wasn't a Netscape start from scratch effort. They acquired and built on a very simple and modular cross platform rendering engine that was used for the preview function in an HTML authoring product called WebSuite by Digital Style out of San Diego. (This is where Netscape got engineers Rick Gessner, Peter Linss, and manager Jim Hammerly.)
So, maybe if you count the WebSuite and the Netscape efforts both, you get something like 5-6 years of effort to get Gecko up to sufficient capability to compete in the market. That's a far cry from "it took Mozilla 25 years" though.
And yes, the Web is much more capable today, which makes building a rendering engine more difficult for sure, but the 25 year comment seemed wrong enough to me that I thought I'd share some of what I know as a Mozilla participant for the last 25 years (and a full-time Netscape/Mozilla employee for the last 22.5 years.)
This is not in any way meant to take away from the efforts of any new engine devs or teams. I'm amazed that anyone is even trying given how large the platform has become and have great respect for those trying and succeeding.
Yes, but web standards were at least an order of magnitude simpler back then.
The DOM, etc through the work that eventually got labeled HTML5 made it possible to follow the spec and, as a super simple and "obvious" example, parse URLs in a way that worked. The existing specs of the era were often incomplete, semi-frequently what they did say did not match how browsers actually worked, and frequently ambiguous which meant that implementing anything required exhaustively testing what everyone else did to try and match it.
TC39 eventually recognized that the same issues existed in the ECMAScript spec, and recognized that ES4 did nothing to resolve those issues, while adding considerable complexity and more of the same issues. That's how we ended up with ES3.1 - it was an attempt to actually correctly and completely specify the language and runtime, ES5 continued/finished that catchup (ES3.1 did not resolve all the issues) while adding a few important features, but was still in the "make it possible for someone to implement the spec and be confident that they could run anything any other engine could run".
So in the modern browser there are many more specs, but those specs are much easier to confidently implement as you can get basic working behaviour by essentially translating the spec language into your environment.
Making the resulting engine fast, memory efficient, etc is of course another thing entirely (although even that is aided by removing ambiguity in the specs as the lack of ambiguity means that you can actually write tests now).
I'm sorry, but Ladybird is written in C++. Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.
Is it though?
If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.
As Ladybird gets more complex, it will most certainly have memory corruption vulnerabilities, just like the other browsers and it will turn out to be no different.
--
Let me make a silly argument. Let's say you write a program in rust, a sort of elaborate turing tape that interprets C++ code and evaluates it as a C++ program according to all standards and rules. To the end user it is indistinguishable from a C++ interpreter, but between the C++ code and the system is a layer of rust.
According to standard rustacean dogma, this program will simultaneously be guaranteed to be memory safe because it is rust, and inevitably have memory corruption bugs because it is C++. This is surely a contradiction. It cannot both be incorrect and correct at the same time.
Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.
It is.
> I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII.
Firefox is still in C++ and is still subject to memory corruption vulnerabilities, proving my point again.
> Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.
"almost flawless" is still in the category of 'possible'. Memory corruption is not possible in Rust by default.
Surely you understand what 'inevitable' means before giving me an example of a project that has at least one memory corruption vulnerability out of the thousands of other projects that are also in C++, especially browser-based software?
Remember: This is all from scratch, not even using the Linux Kernel if I recall correctly. Bonkers!!!
Honestly not sure if it's harder to support canvas or DOM based rendering.
How is the accessibility picture?
At google’s size/cash implementing these things might be achievable, but I recall many people/projects over the years that decided to do in canvas rather than using the available engine (often times a belief that their desire for pixel perfect positions was reasonable, and more than made up for needing to draw everything and manage text entry themselves) always looks easy at first glance, typically because the authors don’t use accessibility tools and most who I interacted with were English-first devs who believe one keypress event == one letter. So you end up with yet another English-only (and I really do mean English specifically here, not Western European) and inaccessible rendering engine for a web page, that typically could have achieved 95-100% of what they wanted, with a bunch of the remainder being stuff that doesn’t work for people with accessibility issues.
Really really inspiring.
More power to them, but modern browsers are one of the most advanced and sophisticated pieces of software in the world, probably right next to an OS. WebKit and Chromium respectively have had billions of dollars and decades of development poured into them. The current duopoly state of the market reflects that fact, unfortunately.
> Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff.
> Sure you can. Don’t listen to armchair defeatists who never worked on a browser.
[1] https://awesomekling.github.io/Ladybird-a-new-cross-platform...