Meta tags:
description=JustHTML 3.0.0 is out, and the biggest change is not a new API. It s a new parser core. Up until now, JustHTML looked like most HTML5 parsers. First...;

Headings (most frequently used words):

what, justhtml, new, html5, parser, architecture, changed, in, how, it, works, why, this, is, faster, the, comparison, to, other, parsers, did, not, change,

Text of the page (most frequently used words):
the (62), and (25), that (21), #parser (13), justhtml (12), tree (11), what (9), still (9), engine (9), this (8), token (8), tokenizer (7), builder (7), are (7), parsing (7), safe (7), default (7), not (7), html5 (7), plan (7), for (6), tag (6), path (6), into (6), new (6), now (5), you (5), fragment (5), behavior (5), html (5), parsers (5), browser (5), change (4), dom (4), mode (4), end (4), architecture (4), can (4), objects (4), then (4), only (3), more (3), from (3), think (3), want (3), real (3), makes (3), bit (3), python (3), but (3), structure (3), with (3), start (3), other (3), used (3), allowed (3), attributes (3), state (3), all (3), parse (3), false (3), later (3), decisions (3), tags (3), element (3), tokens (3), one (3), everyone (2), else (2), should (2), same (2), faster (2), old (2), error (2), exact (2), will (2), strict (2), true (2), works (2), source (2), there (2), boring (2), also (2), most (2), stream (2), they (2), correct (2), often (2), around (2), than (2), intermediate (2), does (2), core (2), closer (2), fused (2), required (2), boundary (2), way (2), spec (2), html5ever (2), separate (2), easier (2), reason (2), about (2), optimization (2), until (2), passes (2), time (2), characters (2), immediately (2), fewer (2), lot (2), common (2), transform (2), information (2), already (2), payloads (2), have (2), just (2), keep (2), needed (2), even (2), shape (2), sanitizer (2), them (2), attribute (2), scanning (2), directly (2), current (2), root (2), input (2), compiled (2), like (2), hot (2), actions (2), handling (2), policy (2), formatting (2), cases (2), different (2), another (2), apply (2), content (2), details (2), those (2), feed (2), friendly (2), jump (2), exactly, wanted, mostly, experience, main, breaking, diagnostics, since, internals, gone, report, smaller, intentional, built, set, depended, codes, counts, ordering, need, adjust, collect_errors, gives, streaming, location, tracking, outside, release, pleasantly, did, better, fit, actually, users, consuming, sanitized, product, sense, optimize, job, artifacts, unusual, among, pure, targets, application, use, execution, textbook, plus, pipeline, changes, tradeoff, keeps, style, recovery, model, stops, treating, emission, architectural, don, proves, wrong, structured, classic, because, maps, well, large, codebases, many, contributors, implementing, scratch, layers, debug, specification, friendlier, test, harnesses, inspect, streams, standard, safest, place, comparison, kind, sounds, remember, happening, where, object, churn, extra, cost, when, its, scan, recognize, decide, whether, project, interesting, mutate, less, indirection, temporary, full, removes, machinery, becomes, walk, stage, has, interpret, discovered, normalized, handed, off, allocated, traditional, pays, several, overhead, costs, changelog, reports, very, mysterious, speedup, why, last, part, matters, attrs, some, never, survive, serialization, handled, differently, too, typically, parses, revisits, projected, through, preserve, drop, construction, inside, sets, either, document, shell, walks, single, range, fast, uses, specialized, avoids, building, generic, skips, treebuilder, handoff, completely, parseengine, compile_default_engine_plan, practice, looks, longer, asking, node, knows, contains, scattered, across, steps, url, hooks, void, knowledge, specific, tables, raw, heavy, sanitize, custom, sanitization, policies, before, starts, compiles, requested, plans, engineplan, key, idea, word, how, round, control, flow, scans, string, decides, means, context, mutates, while, implements, concepts, insertion, modes, open, stack, active, elements, foster, parenting, rawtext, rcdata, foreign, rules, painful, make, instead, handing, second, subsystem, applying, pass, work, loop, collapses, split, driven, changed, engines, broadly, follow, differ, html5lib, normal, itself, written, machine, between, text, comments, doctypes, errors, looked, first, tokenize, after, cleanup, untrusted, usable, applications, out, biggest, api, emil, stenström, jun, 2026, contact, navigation,

Text of the page (random words):
justhtml 3 0 0 a new html5 parser architecture friendly bit jump to content or jump to navigation friendly bit contact feed justhtml 3 0 0 a new html5 parser architecture jun 21 2026 emil stenström python justhtml 3 0 0 is out and the biggest change is not a new api it s a new parser core up until now justhtml looked like most html5 parsers first tokenize the input then feed those tokens into a tree builder and only after that apply the default safe cleanup that makes untrusted html usable in applications that s the normal structure the html5 spec itself is written that way the tokenizer is one state machine the tree builder is another and the boundary between them is a stream of tokens start tags end tags text comments doctypes parse errors html5lib browser engines and html5ever all broadly follow that shape even if the details differ a lot what changed in 3 0 0 justhtml 3 0 0 collapses that split into one plan driven parser engine so instead of scanning characters into token objects handing those tokens to a second subsystem and then applying sanitizer decisions as a later pass the new engine does that work in one loop it still implements the same html5 concepts insertion modes the open element stack active formatting elements foster parenting fragment parsing rawtext rcdata handling foreign content rules and all the other painful details that make browser parsing browser parsing but the control flow is different now the parser scans the source string directly decides what the current tag means in context mutates the dom immediately and can apply default safe policy decisions while it is still in the hot path this is a real architecture change not just another round of optimization how it works the key idea is the word plan before parsing starts justhtml compiles the requested behavior into an engineplan there are different plans for the common cases the default safe path custom sanitization policies that can be compiled into parser actions the raw path used by sanitize false and transform heavy cases that plan contains the parser time decisions that used to be scattered across later steps tag actions allowed tags attribute handling url policy hooks void element knowledge formatting element behavior and other mode specific tables so the hot path is no longer asking what should i do with this node later it already knows in practice the engine now looks more like this plan compile_default_engine_plan fragment false engine parseengine html fragment false plan plan root engine parse inside parse the engine sets up either a document shell or fragment root then walks the input with a single range parser on the fast path it uses specialized start tag and end tag parsers for compiled safe mode so it avoids building generic token objects and skips the tokenizer to treebuilder handoff completely attributes are handled differently too in the old shape a tokenizer typically parses all attributes into token payloads and then the tree builder or sanitizer revisits them in the new justhtml engine attribute scanning can be projected directly through the current plan preserve what is needed drop what is not and keep only the state required for correct tree construction that last part matters html parsing is not just keep the allowed attrs some information is needed for parser state even if it will never survive serialization why this is faster the 3 0 0 changelog reports about a 2x speedup and the reason is not very mysterious traditional parser structure pays several overhead costs token objects have to be allocated token payloads have to be normalized and handed off the tree builder has to re interpret information the tokenizer already discovered default safe behavior often becomes a separate tree walk or transform stage the fused engine removes a lot of that machinery from the common path when justhtml is used in its default mode the parser can scan characters recognize a tag decide whether that tag is allowed project the interesting attributes and mutate the dom immediately less indirection fewer temporary objects fewer full tree passes this is the kind of optimization that sounds boring until you remember it s happening in python where object churn and extra passes cost real time the comparison to other parsers i still think the standard architecture is the safest place to start if you are implementing html5 from scratch tokenizer and tree builder as separate layers is easier to reason about easier to debug and closer to the specification it is also friendlier to test harnesses that want to inspect intermediate token streams so i don t think this proves everyone else wrong html5ever and browser parsers are structured the classic way because that structure maps well to the spec and to large codebases with many contributors what justhtml 3 0 0 changes is the tradeoff it keeps the browser style recovery model but stops treating token emission as a required architectural boundary that makes justhtml a bit unusual among html parsers it is still pure python still targets exact html5 behavior and still does safe by default parsing for application use but the parser core is now closer to a fused execution engine than a textbook tokenizer plus tree builder pipeline i also think this is a better fit for what justhtml actually is most users are not consuming a token stream they want a correct dom tree and often they want it sanitized if that is the real product it makes more sense to optimize around that end to end job than around intermediate artifacts what did not change from the outside this release is pleasantly boring justhtml html still gives you a dom fragment parsing still works streaming source location tracking strict mode and safe by default behavior are still there the main breaking change is diagnostics since the old tokenizer tree builder internals are gone collect_errors true and strict true now report a smaller more intentional built in error set if you depended on exact error codes counts or ordering you will need to adjust everyone else should mostly experience 3 0 0 as the same parser only faster that s exactly what i wanted