[yjftsjthsd-h]

> What if your command line terminal could display more than just text? That’s crazy right (I can hear the screams of thousands of graybeard sysadmins).

The screams are because they remember the last... 3 or 4 off the top of my head? terminals that said that, and then fell over when you tried to cat a log file because they were using javascript in the hot path for displaying text. So how's your performance and responsiveness? Throughput and latency both matter a lot here.

OTOH, full marks for actually doing FOSS and not requiring a login to use a local terminal; you've already avoided at least some of the obvious landmines that would make me run screaming.

[sawka]

All of the tty processing, networking, and stream processing is done in Go, so it is fast. There is obviously more performance work to do, but in some situations our model can actually be faster than other terminals. If you cat a 1GB file in Wave, it actually runs quickly because the frontend can drop frames, while the Go backend is buffering the stream (so to answer your question, JS is not in the hot path, only Golang is).

[cassianoleal]

> the frontend can drop frames, while the Go backend is buffering the stream

Surely that's not great. Dropped frames are terrible for following what's happening on the screen and even worse for scrolling.

[em-bee]

mosh is also dropping frames if it needs to. only happens when the network speed can't keep up with the data being sent through

[cassianoleal]

Yeah exactly. That's meant to make a laggy remote session feel a little less stuttery, which in many cases improves the experience.

It's not the same as doing that between 2 local layers.

[em-bee]

well, i have had local sessions hang because they had to much output, so i kind of see the benefit locally too.

[cassianoleal]

One terminal emulator with a bad implementation of buffering and outputting text doesn't make a different bad one good.