The block mode terminals (like the 3270) were/are kinda like HTML forms: The mainframe sends a form to the terminal, and the terminal has enough local smarts to know how forms work, that only some regions of the form are writable, and how to send a response back one form at a time, as opposed to the character-at-a-time terminals which Unix and VMS and ITS were built around. There's a lack of flexibility, but it allows mainframes to service tons of interactive users, for a certain definition of interactive.
The Blit terminal was the next step beyond block mode terminals, in some sense: Blits could be character-cell terminals with fundamentally the same model as the VT100, but they could also accept software in binary form and run interactive graphical programs locally. Think WASM, only with machine code instead of architecture-independent bytecode.
https://en.wikipedia.org/wiki/Blit_(computer_terminal)
> When initially switched on, the Blit looked like an ordinary textual "dumb" terminal, although taller than usual. However, after logging into a Unix host (connected to the terminal through a serial port), the host could (via special escape sequences) load software to be executed by the processor of the terminal. This software could make use of the terminal's full graphics capabilities and attached peripherals such as a computer mouse. Normally, users would load the window systems mpx (or its successor mux), which replaced the terminal's user interface by a mouse-driven windowing interface, with multiple terminal windows all multiplexed over the single available serial-line connection to the host.
> Each window initially ran a simple terminal emulator, which could be replaced by a downloaded interactive graphical application, for example a more advanced terminal emulator, an editor, or a clock application. The resulting properties were similar to those of a modern Unix windowing system; however, to avoid having user interaction slowed by the serial connection, the interactive interface and the host application ran on separate systems—an early implementation of distributed computing.
That was 8th and 9th Edition Research Unix; it was an influence on Plan 9, which took the distributed GUI computer system concept and ran with it.
> So you could log into a remote machine and run EMACS, and while you were editing a remote file with a remote editor all the screen updating would be done by your local computer!
Also, ITS had the neat feature of detaching job trees: You could login, get your own HACTRN (the hacked-up debugger ITS used as a shell), run a few other programs which would then be children of that HACTRN job, and detach the whole tree and logout. When you logged back in, you could re-attach the tree and carry on like nothing happened. It's kinda like screen or tmux.