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.
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.
Here's the relevant folder:
https://github.com/mozilla-firefox/firefox/tree/main/parser/...
make translate # perform the Java-to-C++ translation from the remote
# sources
(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.
... and then when I checked the henri-sivonen tag https://simonwillison.net/tags/henri-sivonen/ found out I'd previously written about the exact same thing 16 years earlier!
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.
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
Verified Compliance: Passes all 9k+ tests in the official html5lib-tests suite (used by browser vendors).
selectolax 68% No Very Fast CSS selectors C-based (Lexbor). Very fast but less compliant.
One of the tests:
INPUT: <svg><foreignObject></foreignObject><title></svg>foo
Expected:
| <html>
| <head>
| <body>
| <svg svg>
| <svg foreignObject>
| <svg title>
| "foo"
Actual:
| <html>
| <head>
| <body>
| <svg>
| <foreignObject>
| <title>
| "foo"
<html><head></head><body><svg><foreignObject></foreignObject><title></title></svg>foo
</body></html>> Does this library represent a legal violation of copyright of either the Rust library or the Python one? Even if this is legal, is it ethical to build a library in this way?
Currently, I am experimenting with two projects in Claude Code: a Rust/Python port of a Python repo which necessitates a full rewrite to get the desired performance/feature improvements, and a Rust/Python port of a JavaScript repo mostly because I refuse to install Node (the speed improvement is nice though).
In both of those cases, the source repos are permissively licensed (MIT), which I interpret as the developer intent as to how their code should used. It is in the spirit of open source to produce better code by iterating on existing code, as that's how the software ecosystem grows. That would be the case whether a human wrote the porting code or not. If Claude 4.5 Opus can produce better/faster code which has the same functionality and passes all the tests, that's a win for the ecosystem.
As courtesy and transparency, I will still link and reference the original project in addition to disclosing the Agent use, although those things aren't likely required and others may not do the same. That said, I'm definitely not using an agent to port any GPL-licensed code.
IANAL but regardless of the license, you have to respect their copyright and it’s hard to argue that an LLM ported library is anything but a derivative work. You would still have to include the original copyright notices and retain the license (again IANAL).
It’s a lot easier to argue that it’s a derivative work when you feed the copyrighted code directly into the context and ask it to port it to another language. If the copyrighted code is literally an input to the inference request, that would not escape any judge’s notice. The law may not have any precedent for this technology but judges aren’t automatons beholden to trivially buggy code that can’t adapt.
i think the fun conclusion would be: ideally no better, and no worse. that is the state you arrive it IFF you have complete tests and specs (including probably for performance). now a human team handcrafting would undoubtedly make important choices not clarified in specs, thereby extending the spec. i would argue that human chain of thought from deep involvement in building and using the thing is basically 100% of the value of human handcrafting, because otherwise yeah go nuts giving it to an agent.
No, because it's a derivative work of the base library.
I think you can claim the prompt itself. But you didn't create the new code. I'd argue copyright belongs to the original author.
This project is the absolute extreme: I handed over exactly 8 prompts, and several of those were just a few words. I count the files on disk as part of the prompts, but those were authored by other people.
The US copyright office say "the resulting work is copyrightable only if it contains sufficient human-authored expressive elements" - https://perkinscoie.com/insights/update/copyright-office-sol... - but what does that actually mean?
Emil's JustHTML project involved several months of work and 1,000+ commits - almost all of the code was written by agents but there was an enormous amount of what I"d consider "human-authored expressive elements" guiding that work.
Many of my smaller AI-assisted projects use prompts like this one:
> Fetch https://observablehq.com/@simonw/openai-clip-in-a-browser and analyze it, then build a tool called is-it-a-bird.html which accepts a photo (selected or drag dropped or pasted) and instantly loads and runs CLIP and reports back on similarity to the word “bird” - pick a threshold and show a green background if the photo is likely a bird
Result: https://tools.simonwillison.net/is-it-a-bird
It was a short prompt, but the Observable notebook it references was authored by me several years ago. The agent also looked at a bunch of other files in my tools repo as part of figuring out what to build.
I think that counts as a great deal of "human-authored expressive elements" by me.
So yeah, this whole thing is really complicated!
Laying claim to anything generated is very likely to fail.
Hmm, it is interesting to think about that situation. Intuitively it would seem to me like there's some nuance between whether work would need to be "thrown out" or whether it just can't be sold as their own creation, marking some kind of divide between code produced and used privately for commercial purposes vs code that is produced and sold/provided publicly as a commercial product. The risk in doing the latter, or entirely throwing out the code, seems like it would be a relatively cheap risk that those companies do anyway all the time.
However, if I as a small business owner made a tool to help other businesses based on LLM code that used some of my own prior work for context, then sold the code itself as a product or sold a product with it as a dependency, it would be a much greater liability for me if it turned out to include copyrighted && unlicensed work that was produced by an LLM that further can't be claimed as my own.
Privately, on servers or in internal tooling not sold commercially, it would perhaps be next to impossible to either identify or enforce those limits. Without explicit attribution to an agent, I have no idea (with certainty anyway) which code anyone on my team has produced with an LLM, and it's not available publicly—aside from pure frontend web stuff—so I wonder in what capacity it would even be possible to throw specific chunks out if it was hypothetically enforceable.
They also frequently offer "liability shields" where their legal teams will go to bat for you if you get sued for copyright infringement based on your usage of their terms.
https://help.openai.com/en/articles/5008634-will-openai-clai...
https://www.anthropic.com/news/expanded-legal-protections-ap...
Most projects don't have a detailed spec at the outset. Decades of experience have shown that trying to build a detailed spec upfront does not work out well for a vast class of projects. And many projects don't even have a comprehensive test suite when they go into production!
I'm ready to take a risk to my own reputation in order to demonstrate that this kind of thing is possible. I think it's useful to help people understand that this kind of thing isn't just feasible now, it's somewhat terrifyingly easy.
> It took two initial prompts and a few tiny follow-ups. GPT-5.2 running in Codex CLI ran uninterrupted for several hours, burned through 1,464,295 input tokens, 97,122,176 cached input tokens and 625,563 output tokens and ended up producing 9,000 lines of fully tested JavaScript across 43 commits.
I am now confident that within 5-10 years (most/all?) junior & mid and many senior dev positions are going to drop out enormously.
Source: https://www.llm-prices.com/#it=1464295&cit=97123000&ot=62556...
However this changes the economics for languages with smaller ecosystems!
yes because this is what we do all day every day (port existing libraries from one language to another)....
like do y'all hear yourselves or what?
The commenter you’re replying to, in their heart of hearts, truly believes in 5 years that an LLM will be writing the majority of the code for a project like say Postgres or Linux.
Worth bearing in mind the boosters said this 5 years ago, and will say this in 5 years time.
It'd be really interesting if Simon gave a crack at the above and wrote about his findings in doing so. Or at least, I'd find it interesting :).
^Claude still thinks it's 2024. This happens to me consistently.
I personally think that even before LLMs, the cost of code wasn't necessarily the cost of typing out the characters in the right order, but having a human actually understand it to the extent that changes can be made. This continues to be true for the most part. You can vibe code your way into a lot of working code, but you'll inevitably hit a hairy bug or a real world context dependency that the LLM just cannot solve, and that is when you need a human to actually understand everything inside out and step in to fix the problem.
As is mentioned in the comments, I think the real story here is two fold - one, we're getting longer uninterrupted productive work out of frontier models - yay - and a formal test suite has just gotten vastly more useful in the last few months. I'd love to see more of these made.
I'm curious if this will implicitly drive a shift in the usage of packages / libraries broadly, and if others think this is a good or bad thing. Maybe it cuts down the surface of upstream supply-chain attacks?
It is enormously useful for the author to know that the code works, but my intuition is if you asked an agent to port files slowly, forming its own plan, making commits every feature, it would still get reasonably close, if not there.
Basically, I am guessing that this impressive output could have been achieved based on how good models are these days with large amounts of input tokens, without running the code against tests.
I'm a bit sad about this; I'd rather have "had fun" doing the coding, and get AI to create the test cases, than vice versa.
simonw•5h ago
The big unlock here is https://github.com/html5lib/html5lib-tests - a collection of 9,000+ HTML5 parser tests that are their own independent file format, e.g. this one: https://github.com/html5lib/html5lib-tests/blob/master/tree-...
The Servo html5ever Rust codebase uses them. Emil's JustHTML Python library used them too. Now my JavaScript version gets to tap into the same collection.
This meant that I could set a coding agent loose to crunch away on porting that Python code to JavaScript and have it keep going until that enormous existing test suite passed.
Sadly conformance test suites like html5lib-tests aren't that common... but they do exist elsewhere. I think it would be interesting to collect as many of those as possible.
cies•4h ago
Also: it may be interesting to port it to other languages too and see how they do.
JS and Py are but runtime-typed and very well "spoken" by LLMs. Other languages may require a lot more "work" (data types, etc.) to get the port done.
gwking•4h ago
cr125rider•1h ago
skissane•1h ago
heavyset_go•4h ago
simonw•4h ago
heavyset_go•2h ago
cortesoft•2h ago
Why are you making your stuff open source in the first place if you don't want other people to build off of it?
bgwalter•1h ago
1) Ensuring that there is no malicious code and enabling you to build it yourself.
2) Making modifications for yourself (Stallman's printer is the famous example).
3) Using other people's code in your own projects.
Item 3) is wildly over-propagandized as the sole reason for open source. Hard forks have traditionally led to massive flame wars.
We are now being told by corporations and their "AI" shills that we should diligently publish everything for free so the IP thieves can profit more easily. There is no reason to oblige them. Hiding test suites in order to make translations more difficult is a great first step.
visarga•14m ago
The rest is enshittified web, focused on attention grabbing, retention dark patterns and misinformation. They all exist to make a profit off our backs.
A pattern I see is that we moved on from passive consumption and now want interactivity, sociality and reuse. We like to create together.
heavyset_go•1h ago
Because I enjoy the craft. I will enjoy it less if I know I'm being ripped off, likely for profit, hence my deliberate choices of licenses, what gets released and what gets siloed.
I'm happy if someone builds off of my work, as long as it's on my own terms.
aadishv•3h ago
simonw•3h ago
Coding agents are fantastic at these kinds of loops.
montroser•1h ago