Wterm – A terminal emulator for the web | Hacker News Reader

Wterm – A terminal emulator for the web

wterm.dev

66 pointsm3h18 comments

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.

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

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

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/)

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.

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

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.

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.

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.

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.

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

https://github.com/tsl0922/ttyd

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

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.

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.

Wow, finally an alternative to xterm.js?

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

This seems like a useful discussion of the relationship between wterm and xtermjs: https://github.com/agent-of-empires/agent-of-empires/issues/...

It seems like a big problem that xtermjs has is iOS copy/paste, so I fixed that today [1].

[1] https://github.com/xtermjs/xterm.js/issues/3727

Reply on news.ycombinator.com