POC: DOM-based terminal rendering with wterm and libghostty

[nickytonline]

I built a proof-of-concept (POC) that swaps in vercel-labs/wterm as the terminal rendering engine for asciinema-player. The big change: it renders to real DOM elements instead of canvas.

• Live demo: https://nickytonline.github.io/asciinema-wterm-viewer/ — drag-and-drop any .cast/.asciicast file, use the file picker, or paste a URL
• Source: https://github.com/nickytonline/asciinema-wterm-viewer (develop branch)

The current player renders to <canvas>, which is opaque to browsers and assistive technology. Switching to wterm's DOM renderer gives you:

• Native text selection — select, copy, paste terminal text directly
• Screen reader support — real text nodes, not canvas pixels
• Browser find (Ctrl+F) works on terminal content
• Respects OS font/zoom settings via standard CSS
• Passes axe accessibility scans — this would address the issues raised in #291
• ~12 KB WASM for the default Zig core

Optional: @wterm/ghostty for full VT compliance (demo has ghostty)

wterm has a pluggable backend and they support ghostty @wterm/ghostty which drops in libghostty-vt, the same parser powering the Ghostty terminal app. So you get:

• Full VT compliance (complex escape sequences, true color, Unicode edge cases, reflow)
• ~430 KB WASM, loaded async
• Same API — just pass a core prop

The POC uses @wterm/ghostty currently.

What the POC includes

• Asciicast v1/v2/v3 parser (TypeScript)
• Playback engine (seeking, speed control 0.5x–8x, looping, markers, idle time optimization)
• Decoupled display columns from recording size (default 120, adjustable: 80/120/160/200)
• User-adjustable font size (16px–32px)
• File picker + drag-and-drop
• Keyboard shortcuts

I'd be happy to help integrate this into the player if there's interest. Let me know what you think!

CleanShot.2026-05-02.at.14.29.40.mp4

[ku1ik]

This is really cool work - wterm + libghostty sounds fun :)

One thing I want to gently clarify, since it's kind of the premise for the whole POC: the current player doesn't actually render text to <canvas>. It's a layered setup - the canvas underneath only paints cell backgrounds and the rasterized drawing glyphs (box-drawing, blocks, shades, sextants), with Powerline-style symbols as SVG on top of that. But all the actual text is rendered as real DOM nodes - a <pre class="ap-term-text"> full of <span>s with real text content, sitting on top with a transparent background.

The practical upshot is that a few of the listed benefits already work today:

• text selection / copy
• Ctrl+F / browser find
• screen readers see real text
• OS font/zoom via CSS

In fact our whole Playwright suite asserts terminal output by reading .ap-term-text innerText(), which only works because it's genuine DOM text 🙂

Just wanted to make sure we're comparing against what's actually there.

[nickytonline]

Thanks for the clarifications @ku1ik. I'm still new to asciinema. 😅 We started using it at work.

[nickytonline]

That said would you consider a Ghostty version? Maybe completely out of scope for the project, but it was fun to POC this.

[ku1ik]

would you consider a Ghostty version?

Not really. I enjoy working on my own purpose-built terminal emulator :)

[maxandersen]

@nickytonline cool experiment - unfortunately it doesn't seem to render the .cast files I have as well as the current ascinema player - its as if it is not adapting to the col/line width info in the .cast?

@ku1ik I was actually looking at similar option (hooking in ghostty-vt/web) to get proper grapheme clustering/unicode rendering....if not by support reusing existing emulators any plans of getting avt to catch up with modern terminals?

[maxandersen]

To that extent I opened this draft PR (asciinema/asciinema-player#339) as an example of providing hooks without having ascinema itself change approach/terminal emulation.