alt.hn

5/29/2026 at 8:42:28 AM

Wterm – A terminal emulator for the web

 https://wterm.dev/

by m3h

5/29/2026 at 3:53:55 PM

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.

by simjnd

5/29/2026 at 4:06:04 PM

Probably some tokenmaxxing competition between the employees. The whole company seems under some kind of AI psychosis.

by kmaitreys

5/29/2026 at 5:40:42 PM

To be fair, what company isn’t in an AI psychosis?

by mrbobdundon

5/29/2026 at 3:10:22 PM

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.

by dboreham

5/29/2026 at 4:33:56 PM

Have you looked into VibeTunnel? I got the terminal working in my browser and it runs on my computer. I can access it on my phone since we’re on the same Tailscale network. I use Ghostty-Web and tried to switch to Wterm but it didn’t work. I think it’s because Ghostty-Web renders a canvas and wterm normal div tags.

by theturtletalks

5/29/2026 at 5:35:08 PM

Yeah ChromeOS has the same problem. They have a Javascript-native terminal emulator, and a wasm (formerly PNaCL) implementation of open-ssh. But they have to use ChromeOS specific browser extensions in order to allow native TCP connections to port 22 from wasm, and Google only gives themselves this privilege, not any random dev like us.

I'm curious to see if this weird stack gets ported to the Googlebooks or if they just make a mouse-friendly Android app instead.

by seabrookmx

5/29/2026 at 5:52:37 PM

It doesn't take much to support a WSS to Telnet/SSH bridge or directly hosting a PTTY shell... for that matter, you can leverage path/querystring to include signed credentials (like a JWT) as part of the path statement for the underlying connection.

There's even some decent options to bridge further the other way, from a terminal to wss back to a terminal based, server hosted, application.

by tracker1

5/29/2026 at 3:52:13 PM

What do you mean - WebTransport can do a lot...

by jarym

5/29/2026 at 4:20:55 PM

Lot but not enough still. Most web tech is like that, almost there but not really. Webaudio prob being the worst one. Webgpu being weird thing that nobody really knows who it is for.

by Cloudef

5/29/2026 at 4:53:14 PM

It you’re seeking something a bit older and battle tested ttyd is a good comparison:

https://github.com/tsl0922/ttyd

by jerrythegerbil

5/29/2026 at 5:05:34 PM

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...

by toomim

5/29/2026 at 5:48:59 PM

Depends on how much overhead and disconnect there is on the wasm bridge... For a terminal, I doubt it's going to be a noticeable issue compared to render time in the browser.

I have a similar project I haven't touched in a few months.. that said, mine is geared more towards rendering for ANSI-BBS output matching DOS EGA characteristics and correcting for proportion/scale. Mine's in Rust, targeting Canvas and comes in around 50kb (including EGA pixel font embedding), which is a bit larger than this project, which relies on DOM for rendering.

FWIW, I've been meaning to get started on the next part which is a door host that takes WSS connections then running a BBS door for the connection... I'll be taking some inspiration from GHost3 (majorbbs rebooted door host). For now, test renders of .ans files seem to be working very well allong with mouse driven scrollback support.

I'll probably followup with a similar wasm that will support RIPScrip/RIPTerm 1.54 .. not sure if I'll be able to reasonable support v2+, but that would be nice too.

by tracker1

5/29/2026 at 8:32:34 PM

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.

by analogpixel

5/29/2026 at 2:07:55 PM

Wow, finally an alternative to xterm.js?

by williamstein

5/29/2026 at 2:18:30 PM

Ghostty-web exists and is even API compatible with xterm.js (same engine that powers Ghostty):

https://github.com/coder/ghostty-web/

In fact, it looks like wterm's 12KB plugin doesnt offer full term emulation and uses ghostty to support everything else:

https://wterm.dev/ghostty

by nacs

5/30/2026 at 12:30:13 AM

[flagged]

by codepack

5/29/2026 at 4:42:25 PM

[dead]

by Courfeyrac