Live data from Hacker News

Lightpanda migrate DOM implementation to Zig

lightpanda.io

51–60 of 144 posts

Re: Lightpanda migrate DOM implementation to Zig

#51
post #37
post #31

Earlier quoted context omitted.

But arenas have substantial benefits. They may be one of the few remaining reasons to use a low-level (or "systems programming") language in the first place. Most things are tradeoffs, and the question isn't what you're giving up, but whether you're getting the most for what you're paying.

Arenas are also available in languages with automatic memory management, e.g. D, C# and Swift, to use only modern languages as example. Thus I don't consider that a reason good enough for using Zig, while throwing away the safety from modern languages.

First, Zig is more modern than any of the languages you mention. Second, I'm not aware that any of those languages offer arenas similar in their power and utility to Zig's while offering UAF-freedom at the same time. Note that "type-safe" arenas are neither as powerful as general purpose arenas nor fully offer UAF-freedom. I could be wrong (and if I am, I'd really love to see an arena that's both general and safe), but I believe that in all these languages you must compromise on either safety or the power of the arena (or both).

Re: Lightpanda migrate DOM implementation to Zig

#52
post #46
post #21

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.

It's certainly not a choice I would have made, but there's sufficient precedent for it now (TigerBeetle, Ghostty, etc) that I can understand it.

also Bun

Re: Lightpanda migrate DOM implementation to Zig

#53
post #16

Earlier quoted context omitted.

yeah I feel the same, I think even having a screenshot of part of rendered page or full page can be useful even for machines considering how heavy those HTML can be to parse and expensive for LLM context. Sometimes (sub)screenshot is just a better kind of compression

Yes HTML is too heavy and too expensive for LLM. We are working on a text-based format more suitable for AI.

What do you think of the DeepSeek OCR approach where they say that vision tokens might better compress a document than its pure text representation?

https://news.ycombinator.com/item?id=45640594

I've spent some time feeding llm with scrapped web pages and I've found that retaining some style information (text size, visibility, decoration image content) is non trivial.

Re: Lightpanda migrate DOM implementation to Zig

#54
post #43
post #29

Earlier quoted context omitted.

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

It has for Amazon, Adobe, Microsoft, Google and the Linux kernel. It remains to be seen which big name will make Zig unavoidable.

> It has for Amazon, Adobe, Microsoft, Google and the Linux kernel.

I don't think so. I don't know about Adobe, but it's not a meaningful statement for the rest. Those companies default to writing safe code in languages other than Rust, and the Linux kernel defaults to unsafe code in C. BTW, languages favoured by those projects/companies do not reliably represent industry-wide preferences, let alone defaults. You could certainly say that of the two languages accepted so far in the Linux kernel, the only safe one is Rust, but there's hardly any "default" there.

> It remains to be seen which big name will make Zig unavoidable.

I have no idea whether or not Zig will ever be successful, but at this point it's pretty clear that Rust's success has been less than modest at best.

Re: Lightpanda migrate DOM implementation to Zig

#55
post #3

Earlier 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…

A lot of them only still exist for backwards compatabilities sake though. And a decent amount because adding something as a language extension rather than building the language around it has consequences.

Re: Lightpanda migrate DOM implementation to Zig

#56
post #21

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.

In my experience, migrating small-scale projects takes from minutes to single digit hours.

Standard library is changing. The core language semantics - not so much. You can update from std.ArrayListUnmanaged to std.array_list.Aligned with to greps.

Re: Lightpanda migrate DOM implementation to Zig

#57
post #43

Earlier quoted context omitted.

It has for Amazon, Adobe, Microsoft, Google and the Linux kernel. It remains to be seen which big name will make Zig unavoidable.

While certain teams within Google are using rust by default, I'm not sure rust is anywhere close in scale for new lines of code committed per week to c++.

For Android specifically, by Q3 of last year more new lines of Rust were being added per week than new lines of C++: https://security.googleblog.com/2025/11/rust-in-android-move...

Re: Lightpanda migrate DOM implementation to Zig

#58
post #3

This 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…

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

Respectfully, for browser-based work, simplicity is absolutely not a good enough reason to use a memory-unsafe language. Your claim that Zig is in some way safer than Rust for something like this is flat out untrue.

Re: Lightpanda migrate DOM implementation to Zig

#59
post #51
post #37

Earlier quoted context omitted.

Arenas are also available in languages with automatic memory management, e.g. D, C# and Swift, to use only modern languages as example. Thus I don't consider that a reason good enough for using Zig, while throwing away the safety from modern languages.

First, Zig is more modern than any of the languages you mention. Second, I'm not aware that any of those languages offer arenas similar in their power and utility to Zig's while offering UAF-freedom at the same time. Note that "type-safe" arenas are neither as powerful as general purpose arenas nor fully offer UAF-freedom. I could be wrong (and if I am, I'd really love to see an arena that's both general and safe), b…

> First, Zig is more modern than any of the languages you mention

How so? This feels like an empty statement at best.

Post reply on HN