A followup to my previous post on the programming churn. In my many years of programming, the thing I find amusing is how programming has gone back and forth between centralized and distributed computing. Talk about a churn, re-envisioning architectures with new languages where old is new.
For example, when I first started coding the mainframe was king – central processing with multiple dumb terminals. COBOL, Assembler, CICS where the tools of the day. In the mid 1980’s ‘client server’ computing was hailed as the new world order, taking advantage of the power of these new PCs that were starting to appear in businesses. One problem – the infrastructure in the 1980’s made it complex (and slow) for two machines to talk to each other – networking was in its infancy, and cross company communication was via modems and phone lines. In the early 1990s, client server started to mature with software like Fox-pro, Microsoft Access and Visual Basic, as well as better PC based databases.
Then in the mid 1990’s the Internet came along, and from the late 1990’s til early 2010’s, the pendulum swung back to the server model – where all the processing was done on the server and dumb html pages were served up to the browser. The model was eerily similar to mainframes. New development in client server pretty much died as browser based apps became the new normal.
Did I say client server died? Wait, like a zombie it is back, this time in the form of javascript, javascript libraries, and JavaScript frameworks. JavaScript running in the browser has evolved from simple form validation to a full blown programming platform. First JQuery started the flood of code onto the browser, now frameworks like AngularJS or React have pretty much brought us the return of fat client computing.
In the 80’s the infrastructure was the bane of client server – this time around, its the language. By most accounts JavaScript is a terrible language that was pressed into service because it was the only cross platform language available. So to get around the ugliness of JavaScript, it has been somewhat abstracted by libraries that generate JavaScript. In someways its a convoluted mess (this is a great post discussing the current challenges..). The current tooling is painful also – the whole front end world seems disjointed.
Lets not even get to the current horror story of if you want to build a phone app, you have to build the app twice (with very little code sharing) – one for Android, one for IOS.
So will client server win out? I think in a couple of years the current hot mess will be cleaned up as the language and tooling improves. One complicating factor will be the rise of the internet of things – which will bring forth a zillion tiny devices that can talk to each other. Yes your washer can talk to your dryer, your lights can talk to your doorbell, etc. This is going to drive a whole new architecture of applications. These ‘client’ devices will be pretty dumb – though some maybe servers since all they supply is data (lightbulbs, switches), and some may be considered clients because they have a user interface (thermostats, garage door openers). This is going to blur the lines between what is a client and what is a server.
So maybe the the whole concept or servers and clients will disappear, finally putting an end to the client server debate. One thing for sure though – there will be new languages and software architectures to learn, to keep the programming churn alive and well.