Rendered at 21:05:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
simjnd 1 days ago [-]
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.
kmaitreys 1 days ago [-]
Probably some tokenmaxxing competition between the employees. The whole company seems under some kind of AI psychosis.
mrbobdundon 1 days ago [-]
To be fair, what company isn’t in an AI psychosis?
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...
tracker1 1 days ago [-]
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.
jerrythegerbil 1 days ago [-]
It you’re seeking something a bit older and battle tested ttyd is a good comparison:
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.
williamstein 1 days ago [-]
Wow, finally an alternative to xterm.js?
nacs 1 days ago [-]
Ghostty-web exists and is even API compatible with xterm.js (same engine that powers Ghostty):
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.
theturtletalks 1 days ago [-]
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.
seabrookmx 1 days ago [-]
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.
tracker1 1 days ago [-]
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.
jarym 1 days ago [-]
What do you mean - WebTransport can do a lot...
Cloudef 1 days ago [-]
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.
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.
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...
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.
https://github.com/tsl0922/ttyd
I was going to have Cluade do this, but I'm not sure if this is worth the tokens.
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
[1] https://github.com/xtermjs/xterm.js/issues/3727
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.
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.