A language which is not 1.0, and has repeatedly changed its IO implementation in a non-backwards-compatible way is certainly a courageous choice for production code.
Lightpanda migrate DOM implementation to Zig
21–30 of 144 posts
Re: Lightpanda migrate DOM implementation to Zig
#22This table is informative as to exactly what lightpanda is: https://lightpanda.io/blog/posts/what-is-a-true-headless-bro... TL;DR: It does the following: - Fetch HTML over the network - Parse HTML into a DOM tree - Fetch and execute JavaScript that manipulates the DOM But not the following: - Fetch and parse CSS to apply styling rules - Calculate layout - Fetch images and fonts for display - Paint pixels to render th…
> So it's effectively a net+DOM+script-only browser with no style/layout/paint.
> ---
> Definitely fun for me to watch as someone who is making a lightweight browser engine with a different set of trade-offs (net+DOM+style/layout/paint-only with no script)
Both projects (Lightpanda, DioxusLabs/blitz) sound very interesting to me. What do you think about rendering patterns that require both script+layout for rendering, e.g. virtual scrolling of large tables?
What would be a good pattern to make virtual scrolling work with Lightpanda or Blitz?
Re: Lightpanda migrate DOM implementation to Zig
#23Earlier quoted context omitted.
I don't think it's really that bad in Rust. If you're happy with an arena in Zig you can do exactly the same thing in Rust. There are a ton of options listed here: https://donsz.nl/blog/arenas/ Some of them even prevent use after free (the "ABA mitigation" column).
I'm not super experienced with zig, but I always think that in the same way that rust forces you to think about ownership (by having the borrow checker - note: I think of this as a good thing personally) zig makes you think upfront about your allocation (by making everything that can allocate take an allocator argument.). It makes everything very explicit, and you can always _see_ where your allocations are happening…
The problem is deallocation... unless you tie the allocated object to an arena allocator with a lifetime somehow (Rust can model that).
Re: Lightpanda migrate DOM implementation to Zig
#24This reminds me of the Servo project's journey. Always impressed to see another implementation of the WHATWG specs. It's interesting to see Zig being chosen here over Rust for a browser engine component. Rust has kind of become the default answer for "safe browser components" (e.g., Servo, Firefox's oxidation), primarily because the borrow checker maps so well to the ownership model of a DOM tree in theory. But in pr…
> without fighting the compiler
It's unfortunate that "writing safe code" is constantly being phrased in this way.
The borrow checker is a deterministic safety net. Claiming Zig is easier ignores that its lack of safety checks is what makes it feel easier; if Zig had Rust’s guarantees, the complexity would be the same. Comparing them like this is apples vs. oranges.
Re: Lightpanda migrate DOM implementation to Zig
#25This table is informative as to exactly what lightpanda is: https://lightpanda.io/blog/posts/what-is-a-true-headless-bro... TL;DR: It does the following: - Fetch HTML over the network - Parse HTML into a DOM tree - Fetch and execute JavaScript that manipulates the DOM But not the following: - Fetch and parse CSS to apply styling rules - Calculate layout - Fetch images and fonts for display - Paint pixels to render th…
> So it's effectively a net+DOM+script-only browser with no style/layout/paint. > --- > Definitely fun for me to watch as someone who is making a lightweight browser engine with a different set of trade-offs (net+DOM+style/layout/paint-only with no script) Both projects (Lightpanda, DioxusLabs/blitz) sound very interesting to me. What do you think about rendering patterns that require both script+layout for rendering…
So Blitz does technically have scripting, it's just Rust scripting rather than JavaScript scripting. So the plan for virtual scrolling would likely be to implement it in Rust.
If your aim is to render a UI (ala Electron/Flutter) then we have a React-style framework (Dioxus) that runs on top of Blitz, and allows you access to the low-level Rust API of the DOM for advanced use cases (although it's still a WIP and this API is a bit rough atm). I'm also hoping to eventually have a built-in `RecyclerView`-like widget for this (that can bypass the style/layout systems for much more efficient virtual scrolling).
Re: Lightpanda migrate DOM implementation to Zig
#26Earlier quoted context omitted.
Hi, I am Francis, founder of Lightpanda. We wrote a full article explaining why we choose Zig over Rust or C++, if you are interested: https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-... Our goal is to build a headless browser, rather than a general purpose browser like Servo or Chrome. It's already available if you would like to try it: https://lightpanda.io/docs/open-source/installation
Choosing something like Zig over C++ on simplicity grounds is going to be a false economy. C++ features exist for a reason . The complexity is in the domain. You can't make a project simpler by using a simplistic language: the complexity asserts itself somehow, somewhere, and if a language can't express the concept you want, you'll end up with circumlocution "patterns" instead. Build system complexity disappears when…
That’s not fully true though. There’s different types of complexity:
- project requirements
- requirements forced upon you due to how the business is structured
- libraries available for a particular language ecosystem
- paradigms / abstractions that a language is optimised for
- team experiences
Your argument is more akin to saying “all general purpose languages are equal” which I’m sure you’d agree is false. And likewise, complexity can and will manifest itself differently depending on language, problems being solved, and developer preferences for different styles of software development.
So yes, C++ complexity exists for a reason (though I’d personally argue that “reason” was due to “design by committee”). But that doesn’t mean that reason is directly applicable to the problems the LightPanda team are concerned about solving.
Re: Lightpanda migrate DOM implementation to Zig
#27This reminds me of the Servo project's journey. Always impressed to see another implementation of the WHATWG specs. It's interesting to see Zig being chosen here over Rust for a browser engine component. Rust has kind of become the default answer for "safe browser components" (e.g., Servo, Firefox's oxidation), primarily because the borrow checker maps so well to the ownership model of a DOM tree in theory. But in pr…
> without fighting the compiler It's unfortunate that "writing safe code" is constantly being phrased in this way. The borrow checker is a deterministic safety net. Claiming Zig is easier ignores that its lack of safety checks is what makes it feel easier; if Zig had Rust’s guarantees, the complexity would be the same. Comparing them like this is apples vs. oranges.
The fact that Zig doesn't have Rust's guarantees doesn't mean Zig does not have safety checks. The safety checks that Zig does have are different, and are different in a way that's uniquely useful for this particular project.
Zig's check absolutely don't go to the extent that Rust's do, which is kind of the point here. If you do need to go beyond safe code in Rust, Zig is safer than unsafe code in Rust.
Saying Zig lacks safety checks is unfortunate, although I wouldn't presume you meant it literally and just wanted to highlight the difference.
Re: Lightpanda migrate DOM implementation to Zig
#28Earlier quoted context omitted.
I'm not super experienced with zig, but I always think that in the same way that rust forces you to think about ownership (by having the borrow checker - note: I think of this as a good thing personally) zig makes you think upfront about your allocation (by making everything that can allocate take an allocator argument.). It makes everything very explicit, and you can always _see_ where your allocations are happening…
The problem is deallocation... unless you tie the allocated object to an arena allocator with a lifetime somehow (Rust can model that).
Yep, rust forces you to think about lifetimes. Zig only suggests it (because you're forced to think about allocation, which makes you naturally think about the lifetime usually) but does not help you with it/ensure correctness.
It's still nice sometimes to ensure that you have to think about allocation everywhere, and can change the allocation strategy for something that works for your usecase. (hence why I'm looking forward to the allocator api in rust to get the best of both worlds).
Re: Lightpanda migrate DOM implementation to Zig
#29This reminds me of the Servo project's journey. Always impressed to see another implementation of the WHATWG specs. It's interesting to see Zig being chosen here over Rust for a browser engine component. Rust has kind of become the default answer for "safe browser components" (e.g., Servo, Firefox's oxidation), primarily because the borrow checker maps so well to the ownership model of a DOM tree in theory. But in pr…
I don't think that a language that was meant to compete with C++ and in 10+ years hasn't captured 10% of C++'s (already diminished) market share could be said to have become "kind of the default" for anything (and certainly not when that requires generalising from n≅1).
Re: Lightpanda migrate DOM implementation to Zig
#30Earlier quoted context omitted.
Off topic note: I read the website and a few pages of the docs and it's unclear to me for what I can use LightPanda safely. Like say I wanted to swap my it as my engine on playwright, what are the tradeoffs? What things are implemented, what isnt?
Thanks for the feedback, we will try to make this clearer on the website. Lightpanda works with Playwright, and we have some docs[1] and examples[2] available. Web APIs and CDP specifications are huge, so this is still a work in progess. Many websites and scripts already work, while others do not, it really depends on the case. For example, on the CDP side, we are currently working on adding an Accessibility tree imp…
I was actually interested into using lightpanda for E2Es to be honest, because halving the feedback cycle would be very valuable to me.