Character terminal

Character terminals have been a prominent way of using computers since the early years. At first, paper-based ?teleprinters were the most common computer terminals, but CRT-based video terminals started to replace them in the 1970s. In the 2000s, the character terminal is most often a terminal emulator program running on a graphics-capable computer.

Character-based terminals and interfaces from a permacomputing point of view:

Advantages:

A VT100-compatible terminal emulator is quite simple to implement and its basic hardware requirements are quite low (a couple of kilobytes of RAM are enough for representing the screen contents).
- Even simpler terminals can be usable in the Unix world provided that a Terminfo/Termcap entry is available. For "VT100-only" software, Screen or Tmux can be used as a compatibility layer.
The hardware requirements for a server are even lower than for a client. It requires very little from a computing device to send and receive characters over a serial connection; even the smallest microcontrollers can do this.
The simplicity (no long packets etc.) makes all the possible failures relatively easy to notice and diagnose. Even a bad physical connection will show up as random noise characters unless there's an error-correcting layer.
Nearly any device with a keyboard and a display can be used as a terminal emulator as long as it has some kind of a serial or network connection. VT100-compatible terminal emulators are also available on just about any classic or modern personal computer platform.
The basic bandwidth requirements are very low (you mostly send and receive individual characters as individual bytes).
The limited nature of the character-based screen sets a practical upper limit to the fanciness of the interface, and this helps keep the bandwidth and system requirements low. The simplicity and manageability of text terminals make many people prefer terminal-based software even when working on powerful graphical workstations.
Simple interactive programs are more straightforward to program for character terminal I/O than e.g. web browsers.

Problems:

"Dumb" remote terminal connections set quite high requirements for the responsivity of the network and the remote computer. The user feels uncomfortable if there's even a slight delay between the keypress and the visible response. Even WWW is far more tolerant to network lag.
- Local echo used to be a common terminal feature that could be used to reduce this discomfort. Seeing the typed character immediately also made it easier to spot and correct mistakes. Local echo is useful for simple and rudimentary command line interfaces, but more complex features (such as tab completion) reduce its usability.
- Mosh is a protocol that extends SSH with some more tolerance for unreliable and laggy network connections by trying to predict how the typed text will look like on the terminal before the server sends its actual response.
- Block-oriented terminals such as the IBM 2260 and 3270 addressed these problems already in the 1960s. In a sense, web browsers can be thought of as successors of block-oriented terminals.
The potential of the hardware used as a text terminal is nearly always underused. Even "dumb" terminals are usually not so dumb on the inside. The VT100, for example, is basically a 8080-based microcomputer with far more potential than just running the ROM-based terminal program.
- Unlike many later terminals and terminal emulators, the VT100 does not have features such as client-side copying, filling or highlighting, or even arbitrary scroll zones (only full-width zones are supported). Since the VT100 became the "gold standard", even today's terminal-oriented software such as Tmux are forced to implement their fancy windowing features by constant character-by-character refreshes.
- In general, a lot of relatively basic stuff requires far more bytes than it ideally should. When using a text editor over SSH over TCP/IP, every single keypress translates into quite many protocol bytes. Even a website with a text edit box may be much easier for the network.
Textmode rendering comes from a world where pixels are cheap but memory is expensive. It is therefore not very good for small screens that could be used more efficiently with direct pixel addressing and non-monospaced fonts.
Many terminal-based programs make the assumption that the screen is at least 80 characters wide. This makes them impractical on small displays.
Since keypresses are transmitted as individual characters, it is generally not possible to create UIs that depend on the arbitrary pressing and depressing of keys (e.g. cursors that move constantly when an arrow key is down and stop moving exactly when the key is released).
Likewise, it is not possible to support arbitrary combinations of keys (ctrl+A and ctrl+shift+A both transmit the same byte). The limited key combination support has made it difficult to implement some common CUI/TUI standards (such as using shift+arrows to mark blocks of text) on VT100-compatible terminals.
Nearly all ways to display even rudimentary graphics have been somehow crippled in mainstream text terminals:
- Unlike many contemporaries (such as Teletext, Videotex and many early personal computers), the VT100 has no pseudopixel characters, only box-drawing and curve-drawing ones. Some pseudopixel characters have been adopted into Unicode, but their support in fonts has been unreliable.
- VT220 and later VTs support user-definable characters but this feature has been rarely implemented in emulators (no surprise, since the character matrix size varies by terminal model and display mode).
- Some special-purpose VT terminals feature bitmap and vector graphics ("Sixel" and "ReGIS"), and some terminal emulators (xterm) actually support them. However, Sixel graphics was defined so that each individual color needs to be separately transmitted (no proper bitplanes), so it makes sense only for very low-color images.

Some technical vocabulary:

ANSI X3.64 is a ~1976 control sequence standard for character-based video terminals. It was criticized for being too complicated for "dumb" hardware and thus requiring a microprocessor. One of the complications was the use of ASCII decimal numbers as command parameters (earlier terminals had used single bytes instead).
VT100 and VT102 are physical, microprocessor-based text terminals manufactured by Digital Equipment Corporation in around 1978-1983. They became the de-facto reference implementation of the ANSI standard.
ANSI.SYS on the IBM PC is another influential implementation of the standard. Notably, it supports the cell-specific foreground and background colors of the CGA-compatible display controllers. "Ansi art" therefore usually refers to art made for the IBM PC textmode, including the non-standard pseudographic characters featured in the IBM PC character set.
ECMA 48 (the last version is from 1986) is a later standard that extends on the X3.64. It defines ANSI.SYS-style colors but also some potentially useful features that are very rarely supported in today's terminal emulators (such as a support for multiple pages and editable areas).
Text mode is a hardware feature of a display controller, allowing the representation of the screen as character indexes rather than individual pixels. The pixel matrices of each character are fetched from a separate character memory (which can be ROM or RAM or both). Physical text terminals, most 8-bit microcomputers and IBM PC compatibles have a hardware textmode. In the game console world, equivalent display modes are referred to as "tile-based". Sometimes, text mode is simulated in software (e.g. the framebuffer console on Linux)
CLI (command-line interface) is based on typed commands. CLIs have been around since the teleprinter days.
CUI and TUI (character-based UI, text-based UI) are a more graphical type of character-based interface. They may have things like status bars, cursor-navigable menus and even windowing or mouse support. A lot of work and standardization on CUI/TUI took place in the IBM PC world. Unfortunately, many of the common CUI/TUI approaches are somewhat prohibitive on low-bandwidth character terminals.
Telnet is a protocol for non-encrypted terminal connections over a TCP/IP network. SSH is a protocol for encrypted ones (and therefore recommended in nearly all circumstances). The easiness to sniff the network for Telnet passwords was the major reason why SSH was adopted.
Pseudographics refers to characters that have been intended for drawing crude graphical images rather than representing text. Some of these are intended for drawing of box frames (e.g. U+2500..U+257F in Unicode), while others are for simulating low-resolution pixel framebuffers (e.g. U+2580..U+259F). ?UNSCII is a font that attempts to implement Unicode and legacy pseudographics as completely as possible.