justhtml

This is a great blog and an incredible piece of research. Re-reading again today, makes me think of Emil Stenström's recently effort to use an LLM to write an HTML5 parser in pure Python [1] using the official HTML5 spec and their test cases. [2] Later, Simon Willison used an LLM to convert the pure Python source to JavaScript. [3] It seems reasonable to ask an LLM to write a "perfect" JSON parser given the RFC spec and massive test pack from seriot.ch. Regarding the "minefield" of JSON parsing, I used to lean on Google's Gson (Java) a lot in my early days. I thought Jackson FasterXML was "too complex". Later, I realised the mind-boggling number of configuration options was weirdly more sustainable (but more complex!), because I could carefully control each JSON parser/generator edge case. [1] https://github.com/EmilStenstrom/justht

I think it's fair enough to consider porting a subset of rewriting, in which case there are several successful experiments out there: - JustHTML [1], which in practice [2] is a port of html5ever [3] to Python. - justjshtml, which is a port of JustHTML to JavaScript :D [4]. - MiniJinja [5] was recently ported to Go [6]. All three projects have one thing in common: comprehensive test suites which were used to guardrail and guide AI. References: 1. https://github.com/EmilStenstrom/justhtml 2. https://friendlybit.com/python/writing-justhtml-with-coding-... 3. https://github.com/servo/html5ever 4. https://simonwillison.net/2025/Dec/15/porting-justhtml/ 5. https://github.com/mitsuhiko/minijinja 6. https://lucumr.pocoo.org/2026/1/14/minijinja-go-port/

Hi! The expected errors are not standardized enough for it to make sense to enable --check-errors by default. If you look at the readme, you'll see that the only thing they're checking is that the _numbers of errors_ are correct. That said, the example you are pulling our out does not match that either. I'll make sure to fix this bug and other like it! https://github.com/EmilStenstrom/justhtml/issues/20

I mean the design of the user-facing API: https://github.com/EmilStenstrom/justhtml/blob/main/docs/api... See also the demo app I vibe-coded against their library here: https://tools.simonwillison.net/justhtml - that's what initially convinced me that the API design was good. I particularly liked the design of JustHTML's core DOM node: https://github.com/EmilStenstrom/justhtml/blob/main/docs/api... - and the design of the streaming API: https://github.com/EmilStenstrom/justhtml/blob/main/docs/api...

This seems really impressive. I am too lazy to replicate this, but I do wonder how important the test suite is for a a port that likely uses straight forward, dependency free python code https://github.com/EmilStenstrom/justhtml/tree/main/src/just... 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 just had Codex CLI figure out where that first version ended and the new one began. It looks to me like this is the last commit before the rewrite: https://github.com/EmilStenstrom/justhtml/tree/989b70818874d... The commit after that is https://github.com/EmilStenstrom/justhtml/commit/7bab3d2 "radical: replace legacy TurboHTML tree/handler stack with new tokenizer + treebuilder scaffold" It also adds this document called html5ever_port_plan.md: https://github.com/EmilStenstrom/justhtml/blob/7bab3d22c0da0... Here's the Codex CLI transcript I used to figure this out: https://gistpreview.github.io/?53202706d137c82dce87d729263df...

JustHTML https://github.com/EmilStenstrom/justhtml is a neat new Python library - it implements a compliant HTML5 parser in ~3,000 lines of code that passes the full existing 9,200 test HTML5 conformance suite. Emil Stenström wrote it with a variety of coding agent tools over the course of a couple of months. It's a really interesting case study in using coding agents to take on a very challenging project, taking advantage of their ability to iterate against existing tests. I wrote a bit more about it here: https://simonwillison.net/2025/Dec/14/justhtml/

I just shipped a new one of these a few minutes ago (from my phone). I found out about a new Python HTML parsing library - https://github.com/EmilStenstrom/justhtml - and wanted to try it out but I'm out without my laptop. So I had Claude Code for web build me a playground interface for trying it out: https://tools.simonwillison.net/justhtml It loads the Python library using Pyodide and lets you try it out with a simple HTML UI. The prompts I used are in this PR: https://github.com/simonw/tools/pull/156

I got frustrated with HTML parsing in Python. I wanted a Python HTML parser that was both correct and easy to install. The C-based ones (lxml, selectolax) are fast but not HTML5 compliant. The pure Python ones (html.parser, BeautifulSoup's default) are easy to install but choke on real-world HTML. html5lib is 80% correct but painfully slow. So I wrote JustHTML. It's: • 100% HTML5 compliant – passes all 8,500+ html5lib tests. If a browser can parse it, JustHTML can. • Pure Python, zero dependencies – pip install and go. Works on PyPy, Pyodide, anywhere. • Fast enough – ~0.1s to parse Wikipedia's homepage. Not C-fast, but 50% faster than html5lib. • Simple API – doc.query("div.foo > p") with CSS selectors. One method to learn. Example: from justhtml import JustHTML doc = JustHTML("<div><p class='intro'>Hello!</p></div>") print(doc.que