4 ms·

Few know that Firefox's HTML5 parser was originally written in Java, and only afterward semi-mechanically translated (pre-LLMs) to the dialect of C++ used in th

by cxr 10mo ago

Few know that Firefox's HTML5 parser was originally written in Java, and only afterward semi-mechanically translated (pre-LLMs) to the dialect of C++ used in the Gecko codebase. This blog post isn't really about HTML parsers, however. The JustHTML port described in this blog post was a worthwhile exercise as a demonstration on its own. Even so, I suspect that for this particular application, it would have been more productive/valuable to port the Java codebase to TypeScript rather than using the already vibe coded JustHTML as a starting point. Most of the value of what is demonstrated by JustHTML's existence in either form comes from Stenström's initial work.

simonw 10mo ago
There are certainly dozens of better ways to do what I did here. I picked JustHTML as a base because I really liked the API Emil had designed, and I also thought it would be darkly amusing to take his painstakingly (1,000+ commits, 2 months+ of work) constructed library and see if I could port it directly to Python in an evening, taking advantage of everything he had already figured out.
simonw 10mo ago
Whoa... it looks like the Firefox HTML5 parser is still maintained as Java to this day! Here's the relevant folder: https://github.com/mozilla-firefox/firefox/tree/main/parser/html/java https://github.com/mozilla-firefox/firefox/tree/main/parser/... make translate # perform the Java-to-C++ translation from the remote # sources And active commits to that javasrc folder - the last was in November: https://github.com/mozilla-firefox/firefox/commits/main/parser/html/javasrc https://github.com/mozilla-firefox/firefox/commits/main/pars...
- cxr 10mo ago
  I have secretly held the belief for a while that the Java implementation should be mechanically translated to TypeScript and then fixed up, annotated, and maintained not just primarily but entirely in that form; the requisite R&D/tooling should be created to: (a) permit a fully mechanical, on-the-fly rederivation of the canonical TypeScript sources into Java, for Java consumers that need it (a lot like the ts->js step that happens for execution on JS engines), and (b) compiler support that can go straight from the TypeScript subset used in the parser to a binary that's as performant as the current native implementation, without requiring any intermediate C++ form to be emitted or reviewed/vetted/maintained by hand (Sidenote: Hejlsberg is being weird/not entirely forthcoming about the overall goals wrt the announcement last year about porting the TypeScript compiler to Go. We're due for an announcement that they've done something like lifted the Go compilers' backends out of the golang.org toolchain, strapped the legacy tsc frontend on top, allowing the TypeScript compiler to continue to be developed and maintained in TypeScript while executing with the performance previously seen mostly with tools written in Go vs those making do with running on V8.) I agree with the overall conclusion of the post that what is demonstrated there is a good use case for LLMs. It might even be the best use for them, albeit something to be undertaken/maintained as part of the original project. It wouldn't be hugely surprising if that turned out to be the dominant use of LLM-powered coding assistants when everything shakes out (all the other promises that have been made for and about them notwithstanding). No real reason that they couldn't play a significant role in the project I outlined above.
- simonw 10mo ago
  I just blogged about this https://simonwillison.net/2025/Dec/17/firefox-parser/ https://simonwillison.net/2025/Dec/17/firefox-parser/ ... and then when I checked the henri-sivonen tag https://simonwillison.net/tags/henri-sivonen/ https://simonwillison.net/tags/henri-sivonen/ found out I'd previously written about the exact same thing 16 years earlier!
  - deleted 10mo ago
    [deleted]
  - po 10mo ago
    It's very nice to have written for so long... I often think I should write more for myself than for others.
  - johanyc 10mo ago
    The power of blogging
QuantumNomad_ 10mo ago
IANAL. In my opinion, porting code to a different language is still derivative work of the code you are porting it from. Whether done by hand or with an LLM. And in my opinion, the license of the original code still applies. Which means that not only should one link to the repo for the code that was ported, but also make sure to adhere to the terms to the license. The MIT family of licenses state that the copyright notice and terms shall be included in all copies of the software. Porting code to a different language is in my opinion not much different from forking a project and making changes to it, small or big. I therefore think the right thing to do is to keep the original copyright notice and license file, and adding your additional copyright line to it. So for example if the original project had an MIT license file that said Copyright 2019 Suchandsuch Permission is hereby granted and so on You should keep all of that and add your copyright year and author name on the next line after the original line or lines of the authors of the repo you took the code from.
- simonw 10mo ago
  I added Emil to my license file: https://github.com/simonw/justjshtml/blob/main/LICENSE https://github.com/simonw/justjshtml/blob/main/LICENSE I'm not certain I should add the html5ever copyright holders, since I don't have a strong understanding of how much of their IP ended up in Emil's work - see https://news.ycombinator.com/item?id=46264195#46267059 https://news.ycombinator.com/item?id=46264195#46267059
  - EmilStenstrom 10mo ago
    My feeling is that my code depends more on the html5lib-tests work than on html5ever. While inspired by, I think the macro-based Rust code is different enough from the source so that its new work. I’m guessing we’ll never know.
fergie 10mo ago
Surely for debugging and auditing it's always better to write libs in JavaScript? Also, given that much of TypeScripts utilty is for improving the developer experience- is it still as relevant for machine-generated code?

by cxr 10mo ago

simonw 10mo ago

There are certainly dozens of better ways to do what I did here. I picked JustHTML as a base because I really liked the API Emil had designed, and I also thought it would be darkly amusing to take his painstakingly (1,000+ commits, 2 months+ of work) constructed library and see if I could port it directly to Python in an evening, taking advantage of everything he had already figured out.

simonw 10mo ago

Whoa... it looks like the Firefox HTML5 parser is still maintained as Java to this day! Here's the relevant folder: https://github.com/mozilla-firefox/firefox/tree/main/parser/html/java https://github.com/mozilla-firefox/firefox/tree/main/parser/... make translate # perform the Java-to-C++ translation from the remote # sources And active commits to that javasrc folder - the last was in November: https://github.com/mozilla-firefox/firefox/commits/main/parser/html/javasrc https://github.com/mozilla-firefox/firefox/commits/main/pars...

cxr 10mo ago
I have secretly held the belief for a while that the Java implementation should be mechanically translated to TypeScript and then fixed up, annotated, and maintained not just primarily but entirely in that form; the requisite R&D/tooling should be created to: (a) permit a fully mechanical, on-the-fly rederivation of the canonical TypeScript sources into Java, for Java consumers that need it (a lot like the ts->js step that happens for execution on JS engines), and (b) compiler support that can go straight from the TypeScript subset used in the parser to a binary that's as performant as the current native implementation, without requiring any intermediate C++ form to be emitted or reviewed/vetted/maintained by hand (Sidenote: Hejlsberg is being weird/not entirely forthcoming about the overall goals wrt the announcement last year about porting the TypeScript compiler to Go. We're due for an announcement that they've done something like lifted the Go compilers' backends out of the golang.org toolchain, strapped the legacy tsc frontend on top, allowing the TypeScript compiler to continue to be developed and maintained in TypeScript while executing with the performance previously seen mostly with tools written in Go vs those making do with running on V8.) I agree with the overall conclusion of the post that what is demonstrated there is a good use case for LLMs. It might even be the best use for them, albeit something to be undertaken/maintained as part of the original project. It wouldn't be hugely surprising if that turned out to be the dominant use of LLM-powered coding assistants when everything shakes out (all the other promises that have been made for and about them notwithstanding). No real reason that they couldn't play a significant role in the project I outlined above.
simonw 10mo ago
I just blogged about this https://simonwillison.net/2025/Dec/17/firefox-parser/ https://simonwillison.net/2025/Dec/17/firefox-parser/ ... and then when I checked the henri-sivonen tag https://simonwillison.net/tags/henri-sivonen/ https://simonwillison.net/tags/henri-sivonen/ found out I'd previously written about the exact same thing 16 years earlier!
- deleted 10mo ago
  [deleted]
- po 10mo ago
  It's very nice to have written for so long... I often think I should write more for myself than for others.
- johanyc 10mo ago
  The power of blogging

QuantumNomad_ 10mo ago

IANAL. In my opinion, porting code to a different language is still derivative work of the code you are porting it from. Whether done by hand or with an LLM. And in my opinion, the license of the original code still applies. Which means that not only should one link to the repo for the code that was ported, but also make sure to adhere to the terms to the license. The MIT family of licenses state that the copyright notice and terms shall be included in all copies of the software. Porting code to a different language is in my opinion not much different from forking a project and making changes to it, small or big. I therefore think the right thing to do is to keep the original copyright notice and license file, and adding your additional copyright line to it. So for example if the original project had an MIT license file that said Copyright 2019 Suchandsuch Permission is hereby granted and so on You should keep all of that and add your copyright year and author name on the next line after the original line or lines of the authors of the repo you took the code from.

simonw 10mo ago
I added Emil to my license file: https://github.com/simonw/justjshtml/blob/main/LICENSE https://github.com/simonw/justjshtml/blob/main/LICENSE I'm not certain I should add the html5ever copyright holders, since I don't have a strong understanding of how much of their IP ended up in Emil's work - see https://news.ycombinator.com/item?id=46264195#46267059 https://news.ycombinator.com/item?id=46264195#46267059
- EmilStenstrom 10mo ago
  My feeling is that my code depends more on the html5lib-tests work than on html5ever. While inspired by, I think the macro-based Rust code is different enough from the source so that its new work. I’m guessing we’ll never know.

fergie 10mo ago

Surely for debugging and auditing it's always better to write libs in JavaScript? Also, given that much of TypeScripts utilty is for improving the developer experience- is it still as relevant for machine-generated code?