I recommend to listen to Andreas Kling (the leader of that project and the author of the post) interview on the Corecursive podcast to learn about his background in working on web browsers code:
https://corecursive.com/serenity-os-with-andreas-kling/
We're building a browser when it's supposed to be impossible
111–120 of 349 posts
Re: We're building a browser when it's supposed to be impossible
#112What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird
I thought unsafe language were a no-go in the context of extremely vulnerable pieces of software like the web?
The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.
Re: We're building a browser when it's supposed to be impossible
#113What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird
Exactly, adding to that: they are NOT repackaging/rebranding chrome/chromium, they are actually building a browser.
The "modern" distinction would be they are building a browser + browser engine, while most fancy new browsers tend to just reuse existing engines, like Edge did with Blink.
Re: We're building a browser when it's supposed to be impossible
#114Web browsers are a moving target, just like operating systems. Anyone can 'build there own'; but I'd also say that it is close to impossible to build a secure and viable competing web browser that correctly implements the specification better than Chrome. The two most important keywords in Drew's blogpost is *serious* and *security*. There is not one mention of either of those words in this blog post; hence Drew's po…
> Web browsers are a moving target It moves slower than people assume; I installed Opera 12 last year for the craic – the last version built on their Presto engine, released almost ten years ago – and it works surprisingly well with many sites. I did have to use mitmproxy to rewrite some trivial stuff like some CSS prefixes and s/(let|const)/var/ in JS. Flexboxes are supported, but grid isn't so that failed for some…
>I mentioned this at the time
And Drew himself answered you at the time on points made to your comment, that is things you said shouldn't be included that should and others you said were incorrectly included but were instead excluded in first place.
Re: We're building a browser when it's supposed to be impossible
#115Earlier quoted context omitted.
Firefox has tons and tons of C++ to this day.
But would they choose C++ if they were _starting_ today?
I do mostly Python on my dayjob, but for low-level side-projects I've gotta say C++ with the C++17 or C++20 standard it's way faster to iterate with than say Rust or even something like Zig.
For me iteration speed's a big selling point that (plus the fact that's easier to find contributors) might also be important for projects like these.
Re: We're building a browser when it's supposed to be impossible
#116[dead]
Re: We're building a browser when it's supposed to be impossible
#117It must be impossible, Mozilla spent more than $5billion for a 3% market share.
Market share and functionality are distinct things. Firefox works as fine as Chrome does.
Re: We're building a browser when it's supposed to be impossible
#118Re: We're building a browser when it's supposed to be impossible
#119I've been working on CSS Layout as a library recently[0] (we have Flexbox and CSS Grid support so far). It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible. Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise…
Question about implementation: while you are not building a browser (so I expect HTML is out of your scope) are you able to use an existing testsuite to compare your implementation?
We have our own test suite (orginally derived from the test suite of Meta's Yoga layout library [0]) which consists of text fixtures that are small HTML snippets [1] and a test harness [2] that turns those into runnable tests, utilising headless chrome both to parse the HTML and to generate the assertions based on the layout that Chrome renders (so we are effectively comparing our implementation against Chrome). We currently have 686 generated tests (covering both Flexbox and CSS Grid).
We would like to run the Web Platform Test suite [3] against Taffy, however these are not in a standard format and many of the tests require JavaScript so we are not currently able to do that.
[0]: https://github.com/facebook/yoga
[1]: https://github.com/DioxusLabs/taffy/tree/main/test_fixtures
[2]: https://github.com/DioxusLabs/taffy/tree/main/scripts/gentes...
[3]: https://github.com/web-platform-tests/wpt/tree/master/css/cs...
Re: We're building a browser when it's supposed to be impossible
#120Earlier quoted context omitted.
I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.
https://meiert.com/en/blog/valid-html-2021/ Most sites still don't have valid HTML. EDIT: my link is old. 98% of the top 100 sites had invalid HTML in 2021, in 2022 we've managed to hit 100%, great job everyone! https://meiert.com/en/blog/valid-html-2022/
Well, the W3C validator also has issues which do not help.
For example, Wikipedia doesn't validate [0] because its CSS has "aspect-ratio: 1" which looks ok to me regarding the spec [1].
[0]: https://jigsaw.w3.org/css-validator/validator?profile=css3sv...
[1]: https://w3c.github.io/csswg-drafts/css-values-4/#ratio-value