The Dumb Terminal Analogy Doesn’t Work Anymore
For years now people have been commenting on how we’re cycling back to the mainframe/dumb terminal set up of yesteryear. And they were right.
Back in the good ol’ days you’d just have a “dumb terminal” on your desk. It didnt need much in the way of processing power and was really just a keyboard and a screen. Keyboard input was sent to a big powerful mainframe server somewhere (usually on-site) that would process the input and update the screen accordingly.
Then computing power got cheaper, Microsoft Windows and MacOS came on the scene and everything was processed and stored locally on your own machine.
Then along came SaaS and Cloud Computing which was a similar architecture to the mainframe days and hence the analogy.
Swap the dumb terminal screen for the web browser and the mainframe computer for a SaaS website and you have pretty much the same concept.
The web browser just receives parsed HTML from the web server and presents input elements for posting back to the web server.
As an analogy, it worked well. Virtually zero processing power was needed at the client. Larry Ellison’s beloved thin client/network computer (and to a lesser degree, the netbook) seemed to be all you needed in the brave new world.
But as work progresses on our new interface, it struck me that we’re now moving away from this model, and in a big way.
Currently most web servers used for SaaS apps need support for some sort of server-side programming language (PHP, Ruby, Perl, C#, whatever).
Due to the model we’re using (Pure HTML5/JavaScript client, REST API), there’s no need for any of this. With this model the web server just serves static files – JavaScript, HTML, CSS, images – that don’t need any server-side processing at all.
The terminal isn’t dumb any more. All the rendering of content, presenting of information and the process flow is handled by the web browsers JavaScript engine. Or in the case of native mobile apps, by whatever magic makes iOS/Android work.
Sure, there’s still the mainframe/SaaS/remote system element, but it’s role is now purely data processing and storage in the form of a REST API. JSON and XML formatted data flows back and forth in response to stateless requests and this still needs to be processed server-side but everything else that dictates the user experiences handled by CPU cycles at the client end.
The dumb terminal analogy doesn’t work anymore.