Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Theoretically it should be possible to build Ladybird for Windows using Cygwin. For now, you can run an AppImage in WSL: https://github.com/SerenityOS/ladybird/issues/33#issuecommen...
Servo produced a very fast CSS rules matching engine now used in Firefox (see https://nolanlawson.com/2022/06/22/style-scoping-versus-shad...), and WebRender which underpins Gecko's rendering. That's not nothing.
About embedding Servo, I have some experience around that (https://github.com/fabricedesre/servonk/) and it's been easy to embed: you just need to provide a GL surface and hook up your input events into their event loop. Clearly there were not zero integration points, and a some other examples exist (like https://github.com/paulrouget/servoshell).
I believe this relies on quite a few of the libraries in SerenityOS and according to one of the lines [1] in one of the build scripts for that it looks like Clang 13 will be required as a bare minimum. The Serenity project is also using the fairly recent C++20 standard according to their contributing document [2] and they additionally are working on a new programming language of their own called Jakt which I imagine will become a requirement in the future. For the time being, it looks like this will make it harder to support older environments which is a bit unfortunate because their browser project does look really interesting.
[1] https://github.com/SerenityOS/serenity/blob/master/Meta/sere...
[2] https://github.com/SerenityOS/serenity/blob/master/CONTRIBUT...
This is correct, and it's why most open-source software will never have much in the way of users:
> They're written from the perspective of the developers
And I get it. A few years back I had an open-source project [1] get users and it was terrible. What had previously been a fun technical exercise became a pain in the ass that felt a lot like actual work. I was relieved when my hardware broke and I had an excuse to archive the project.
But that does create a huge gap that mostly gets filled by commercial interests.
[1] https://github.com/wpietri/sucks
Components of Servo were integrated just fine into Firefox. WebRender is the big one, and iirc many smaller ones too (the css parser maybe? memory hazy)
There's also non-web-related software that uses WebRender, such as Azul. https://crates.io/crates/azul
Maybe there aren't integration points at the layer of the stack you were hoping for, but that doesn't mean the entire project is "bullshit"
> The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, itβs not yet ready for use in Ladybird.)
Have a look at Jakt, it looks a like a really cool language, that strike a balance between performance and simplicity. And it has proper sum-types!
https://github.com/SerenityOS/jakt
Check Nyxt (https://nyxt.atlas.engineer/). Based on WebKit (actually designed to be engine agnostic but WebKit is the only one supported) instead of Gecko, and scripted (also developed) in Common Lisp rather JavaScript.
Servo produced a very fast CSS rules matching engine now used in Firefox (see https://nolanlawson.com/2022/06/22/style-scoping-versus-shad...), and WebRender which underpins Gecko's rendering. That's not nothing.
About embedding Servo, I have some experience around that (https://github.com/fabricedesre/servonk/) and it's been easy to embed: you just need to provide a GL surface and hook up your input events into their event loop. Clearly there were not zero integration points, and a some other examples exist (like https://github.com/paulrouget/servoshell).
FWIW, I know two (partial, kinda) formal specifications of CSS normal flow and float layout, both of which are finished ie dead projects:
[1]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper....
[2]: https://github.com/uwplse/cassius
(not counting the 1990s constraint CSS effort).
The first was merely part of a parallel compiler project and also covers table layout, whereas the second is a Racket (Scheme) program to formulate the HTML doc and CSS rules as a theory for submitting to z3 SMT to solve all kinds of decision problems (it can also produce a rendering).
Not sure that's very helpful; it would be cool if W3C can invest some time into better specs (not just prose).
> there are zero test suites you can use for reference comparison.
What about W3C's web-platform-tests suite [1]?
[1]: https://github.com/web-platform-tests/wpt/tree/master/css
You can store index of the node in parent m_children collection.
Iteration on array is faster (cache locality) than DL list traversal. And there are issues when you traverse tree while changing it.
In any case I've found that storing child nodes as m_children collection is more convenient in many cases. At least in Sciter (https://sciter.com).
struct node {
Hence the second sentence "[b]ut maybe you don't even need to build another Chromium." and then the second paragraph "cost-reducing" billions to millions day-dreaming of a specification-based pixel generator.
Of course, the n-th time is cheaper, easier, faster, case in point: I implemented 'deon', a notation format for structured data [1], using your amazing "Crafting Interpreters" for which I paid nothing since I was reading the web version as you were writing. Never had the chance to say thank you, somewhere in my drafts there is an email of appreciation: reading your book and applying it chapter by chapter, crafting a final, useful artifact, has been a beautiful experience, thank you very much, for all your writing, since I am a longtime reader of your technical and otherwise texts.
[1] https://github.com/plurid/deon
Maybe you could continue developing Kosmonaut? https://github.com/twilco/kosmonaut