beacon VS ladybird

I readily admit that cooking the mozconfig is some holy hell, but they do have real-world examples in the repo; did you experience problems at that stage, or it literally wouldn't compile?

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...

While not exactly the same audience, one may find the Dockerfile for building Beacon handy as (a) more code, less talking (b) since Beacon is just a patched Chromium, its dependencies should be a superset of vanilla Chromium

Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated: https://github.com/imperviousinc/beacon/blob/main/tools/src/...

and again https://github.com/imperviousinc/beacon/blob/main/tools/src/...

This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem

For clarity, I did see that this was inspired by the brave-browser model, but of the ones to draw inspiration from, that's for sure not it given that their CI is closed source and they're trying to use npm in lieu of a more structured, comprehensible system

I like trying out alternate browsers, so congratulations on the launch, and I'll for sure try to build it, but I wanted to draw these to your attention because my experience with software is that error handling is about 80% of the job

A browser is not a web app, it doesn't have a strict separation of "frontend" and "backend" in the same sense that a web app would have; the lines are drawn quite differently. The rendering engine is never "just" the rendering engine; you can't abstract or swap it without tremendous effort.

If you'd like to learn more about how a web browser project would organize its internal architecture, but are discouraged by the complexity of Chromium, Firefox, etc. I'd recommend source diving Ladybird (https://github.com/SerenityOS/ladybird), NetSurf (https://www.netsurf-browser.org/), or Dillo (https://www.dillo.org/).

I'd love to see a stable version of a brand new web browser, not based on Blink or Gecko, such as Ladybird or Flow Browser. Competition is a good thing.

note, native Windows is not currently supported:

https://github.com/SerenityOS/ladybird/issues/113

Google is dominating, pushing through Android and via Googles-Webservices and Microsoft is using it now. A reason to worry because developing new web-engine requires an big effort. For instance Microsoft only allows usage of Microsoft Teams Web with a webbrowser based upon Blink. So were back in 2002?

WebKit features also WebKit2Gtk (Epiphany) and Qt5-webkit (Otter) with native integration. They use the native toolkits, which is an advantage! Interaction with the open-source community around WebKit seems rather good and the engine is integrated by others. Gecko seem not to be integrated by others, but by forks only? You remember when Chrome was considered slick and fast? Originally Google used the native toolkit on every platform but know they use an own solution on every platform, like Firefox.

Maybe there is a new kid on the block:

https://github.com/SerenityOS/ladybird

Funny you should ask: https://github.com/SerenityOS/ladybird

I've not heard of Ladybird before. True, it's a free and open browser engine and a very interesting project!