This reminds me of how this 3270 terminal worked. You sent the terminal a bunch of text to display, and a list of editable regions on the screen. Then only when you edited some things and hit enter were the editable regions sent back. It led to some interesting UIs compared to a typical terminal.

▲

somat an hour ago | parent | next [-]

And it was bad at other use cases, having used both (3270 and vt) you can do 3270 workloads on a vt(granted less efficiently) but vt style asynchronous updates were very hard on a 3270.

If I had to pick one I would pick the vt.

And footnote, while technically I have worked with 3270's, my experience was using rexx on vse/cms. That is to say my use of the 3270 was hampered by about 5 levels of application framework, perhaps if I used them more directly I would be more charitable.

	▲	kragen an hour ago \| parent [-]
		Right, the great advantage of the 3270-style block-mode model was that your 0.5-MIPS mainframe didn't have to handle an interrupt for every keystroke, so it could serve, I don't know, 100 terminals. Same as HTML <form> and half-duplex line-mode terminals with local echo. An in-between version is how csh and vi would set eol2 (I think?) to ^[ so that most user interaction could be done in "cooked mode" until you hit ESC or ^D. This still required an interrupt for every keystroke on your 1-MIPS PDP-11, but at least it didn't require a context switch to the shell or editor process in order to echo normal printing characters. The kernel would handle echoing characters back to the terminal, deleting characters with ^? or ^H, and deleting words with ^W. (As I understand it. I used csh and vi, but never on a PDP-11.)

▲

actionfromafar 2 hours ago | parent | prev [-]

And it had on device buffering, so you could punch in a bunch of commands and be sure they would be received.