Microlighter highlights code in 2 KiB by leaving the DOM alone

Microlighter, a syntax highlighter from Dave Rupert that uses the CSS Custom Highlight API, has reached 763 stars on GitHub. The repository was created on 13 August and last received a push on 2 September. It is MIT licensed.

The design choice is the news. Almost every syntax highlighter on the web works by rewriting your code block into a tree of span elements, one per token, each carrying a class. Microlighter does not touch the markup. The README describes it as highlighting code "without adding a <span> around every token, so your markup stays clean and editable." The colour comes from browser highlight ranges applied over text that stays as text.

What that changes

The practical effect shows up in anything that reads the code block after it renders. A copy button copies the code rather than a nest of markup. Text selection follows the lines a reader sees. An in-page editor can bind to a plain text node instead of fighting a generated DOM tree it did not create. Teams that have written workarounds for token soup can delete them.

Size is the second claim. The README puts it at about 2 KiB compressed, with 35 language grammars loaded on demand: bash, c, cpp, csharp, css, dart, dockerfile, elixir, go, graphql, html, java, javascript, json, kotlin, lua, markdown, php, powershell, python, ruby, rust, scss, sql, svelte, swift, toml, tsx, typescript, vue, yaml and several more. Common shorthand like js, ts, sh, yml and md maps to the right grammar automatically.

The trade the author states himself

The README is direct about the cost, which is worth quoting because most projects are not. It says the trade-off is "less language coverage and grammar accuracy than larger tools such as Shiki." Microlighter avoids Oniguruma and WebAssembly and uses the browser's own regular expression engine instead. That is where both the small size and the reduced grammar accuracy come from. The two are the same decision.

So this is a size and simplicity choice rather than a correctness one. A documentation site with a handful of languages and a strict performance budget is the case it fits. A site that renders unusual languages, or that needs exact tokenisation on complicated syntax, is better served by the larger tool the author names.

Worth checking before you adopt

The CSS Custom Highlight API is the whole mechanism, so browser support for that API decides whether the highlighter works. The README does not state a support baseline or describe what happens on a browser without it, so a team considering this should test the fallback themselves rather than assume one exists. Unhighlighted but readable code is a mild failure; a team should still confirm that is what they get.

For a project shipping a docs site, a changelog, or a blog with code blocks, the question is narrow and answerable in an afternoon: do the languages you actually publish appear in the list of 35, and does your browser floor support the API.

Source

davatron5000/microlighter on GitHub