Letting the computer see each character as it is typed is NOT NECESSARILY NEEDED to make the user interface more dynamic.
Old ASCII terminals came usually as one keyboard+screen package, or
keyboard+printing head (called then often a teletype). So local
echoing was possible. Input was sent as whole lines, and that is what
the enter key was for (it was also called carriage-return). This was
convenient when your terminal was connected through slow telephone
lines to a distant computer. I still have a 300 bauds modem I used
then, which is a bit less than 300 bits/second. And that was not the
slowest I used. You did not want to wait for the echo.
Kyles Jones gave you a few good reasons to have the echo controled by
the computer. Such as history and command line editing. But even these
reasons could be overcome with local echoing. My old ascii screen
terminal (bought in 1980 and which I no longer dare connect to an
outlet as the capacitors must be in a sorry state) had (still has)
about 12 screens (a screen is 24 lines of 80 characters) worth of
history, and local editing facilities: the terminal had its own local
CPU ... I am not sure that is what you had in mind. This is all from
memory, so I hope it is close to truth, but searching for the manual
would take me some time.
So, basically I had a user-interface computer connected to another
computer. Actually, there always will be some hardware to handle the
echoing, so your question is more whether it is appropriate to have
sophisticated hardware to do that with a CPU or with simpler hardware
(not able to do sophisticated work). The builders of my terminal
thought it was appropriate, and made it a sophisticated terminal, with
the dumb communication protocol with the computer that was then
I first thought of saying that a good reason to go through the CPU
would be that applications now use windows with all kinds of features
and differents fonts, and that that requires
the power of the computer to get the appropriate flexibility, that a
simple screen-keyboard cannot offer.
But I recalled in time (memory is hard to recollect) that this is false.
In the early 1980, people were developing bitmap graphics (that was
the name for the kind of screen you are now using, though it was CRT
rathed than LCD). Some of the work followed the traditional terminal
view, making very sophisticated graphic terminals with multiple
windoes and fonts, etc. One of these was the BLIT, that was the
subject of many experiments, such as Cardelli's infamous crabs.
That does not necessarily mean that the CPU running the application did not see the characters. But it did not have to. The terminal was powerful enough to do very complex work on its own.
Computer architecture has been testing many solutions, especially as
faster networks became available. You are concerned with the terminal,
but at some points, it was the disk that was an issue (mostly price,
I think, and also management). So we had for a time diskless
work-station (i.e. personal computers). They would include CPU, screen, keyboard and RAM, but
no disk. Disk space was on the network, and you just requested file
space from the network. Even virtual memory swapping was done through
So the conslusion is: sophisticated interface (for example), using
windows, various fonts, programmable keys, command-line editing,
synchronisation between input and output, and what not, does require
some real processing power. Even with very weak capabilities, some hardware is
needed. Then this computing power may be attached to the computer and
its CPU, or may be independent from it and connected more or less
remotely. The same may be true of other resources.
But everything is very relative.
Last remark. The first alphanumeric screen terminal I ever used was a
Tektronix in 1974, that came with its keyboard. The screen and the
keyboard were so tightly connected, that we had to pay someone to
modify it by changing the circuitry with a soldering iron so that it
would behave as needed. But I should stop my endless stream of stories.