[pavlov]

The IBM PC text mode buffer was mapped into memory, so you could quickly update any part of the screen and easily do things like double-buffering (for rock-solid screen updates), composing the screen out of floating windows held in separate memory buffers, etc.

The Unix terminal is derived from line printers (teletype), a fundamentally different kind of TUI.

I don’t know how much this realistically affects today’s terminals since we have extremely fast connections. But it’s the original reason why those DOS text UIs had such a distinct snappy feel.

[zozbot234]

There are some *nix programs with complex TUI's, where a "snappy feel" is sought after (e.g. the `aptitude` TUI for package management in Debian and its derivatives) and they're just as snappy as any old DOS app. The overhead from using a terminal-based API is just too low to matter.

[pavlov]

As it ought to be since the lowliest Raspberry Pi is tens of thousands of times faster than the IBM PC. Filling a screen shouldn’t be an issue regardless of the protocol in the middle.

But design decisions made in the 1980s still linger in a lot of Unix software.

[pjmlp]

Still, back on the Slackware 2.0 days there were plenty of TUI applications.

Here for the younger generations, https://en.wikipedia.org/wiki/Ncurses

[BirAdam]

This is exactly correct.

As far as affecting the state of TUI/CLI programs today, it becomes part of the culture as well as part of the overall look and feel of the system.

Yet, there are programs that break from convention: JOE, Dit, irssi, etc.