Wterm – A terminal emulator for the web
m3h
58 points
18 comments
May 29, 2026
Related Discussions
Found 5 related stories in 81.9ms across 8,861 title embeddings via pgvector HNSW
- Ghostty – Terminal Emulator oli5679 · 690 pts · March 01, 2026 · 66% similar
- Ratty – A terminal emulator with inline 3D graphics orhunp_ · 633 pts · May 11, 2026 · 63% similar
- Show HN: Waffle – Native macOS terminal that auto-tiles sessions into a grid olleeolleeollee · 30 pts · April 11, 2026 · 52% similar
- Show HN: Gridland: make terminal apps that also run in the browser rothific · 76 pts · March 24, 2026 · 52% similar
- Show HN: Tmux-IDE, OSS agent-first terminal IDE thijsverreck · 75 pts · March 18, 2026 · 51% similar
Discussion Highlights (7 comments)
williamstein
Wow, finally an alternative to xterm.js?
ahsillyme
I thought that there was a name clash: https://web.archive.org/web/20071010015641/https://martin.an... but I can't actually remember what that that wterm was. Not the same I would imagine. (edit: what I was thinking about was https://sourceforge.net/projects/wterm/ )
dboreham
Unfortunately the browser still can't make the kind of network connection needed to transport a terminal session to a remote computer natively. afaik all the tunneling solutions are pretty clunky/insecure.
simjnd
All the commits and releases happened in an extremely short timeframe about a month ago and then nothing. With AI it's so easy to work on something for a couple days and make it seem production-ready before losing any interest and moving on to something else. I may be wrong but it seems like that's what is happening at Vercel Labs. Pumping out new radically different things, and seeing what sticks. I wish such kinds of experiments clearly labeled what it was instead of trying to look production-ready. It coming from a big player like Vercel can especially inspire a false sense of trust, when it was just messing around with AI around some idea and then moving on.
jerrythegerbil
It you’re seeking something a bit older and battle tested ttyd is a good comparison: https://github.com/tsl0922/ttyd
toomim
It's compiled to wasm for "performance", but... 1. WASM FFI has a big overhead when interacting with the javascript DOM. 2. Any DOM UI has a big overhead compared to a canvas. I would be curious to see an actual performance evaluation. This looks like it was built for the wrong tradeoff otherwise...
analogpixel
for a second I thought it was going to give me a filesystem view of the DOM of the webpage with unix utilities to ls/grep/find stuff. that would have been fun (although i'm not 100% sure the use.) I was going to have Cluade do this, but I'm not sure if this is worth the tokens.