Why most people seem intent on taking computing back to the mainframe era with all of the intelligence at the centre of the network in mega datacenters and the endpoint devices acting like fancy display terminals is beyond me. However, rather than prognosticating about the future at the architecture astronaut altitude, I’m going to just point out three interesting details that occurred to me over the course of the summer as I caught up with some geek stuff. And they all start with:
Writing a webapp is different now than it was five years ago because:
(2) …increasingly in the webapp layer cake, more and more of the complex logic is being handled on the client with the server being relegated to persistence and a few other relatively standard functions. Back in 2004 when Ruby on Rails burst on to the scene, a lot more magic used to get done on the server but now it feels like RoR, Django, and most of the other clones have a whole host of crud in them that has been rendered obsolete by the richer client (1) as per above. For instance, each of the frameworks has some clever way to map URLs to controller-like server methods, but why do we need this in a world where everything is REST-based? Even complex interactions can be mapped as resource transformations which of course gives us a huge advantage when we think about the prospect of dumping the middleware that is the server-side framework and talking straight to whatever post-SQL persistence store people happen to favour. JSON to Mongo or Couchbase? No problem. Of course the world isn’t quite this simple yet, but one of the huge advantages of our getting there quickly would be that…
(3)… it might get us to a place where developers could depend of fairly standardized (and dumb) servers that persist resources and handle basic tasks (authentication, versioning) while letting all of the heavy lifting and value add happen in the client, be it a rich HTML5 one or a native mobile application. That we’d get to a simple set of APIs seems preposterous until of course you see how many PaaS companies have emerged in the mobile space alone over the last 6 months (Stackmob, Kinvey, Parse just to name a few). Why? Because most long-tail mobile applications have relatively meager server-side needs and in an ideal world mobile developers could just stick to worrying about the client and leave the boring server stuff to someone else. But why should it be any different for the folks developing rich web applications? Why couldn’t they combine some relatively robust byte-pushing service like S3 to pump out a bunch of JS+CSS that delivers a full application without the need for a pesky middle tier of server goop?
In a sense this was the promise of Google AppEngine before Google priced it out of existence. Though in this new world, AppEngine would have looked like it was trying to be too much to too many different kinds of folks.
My bet is that this kind of dumb-but-flexible service is going to come from a company like Amazon (which has mastered delivering dumb-but-flexible services as well as charging fairly for them) though it is clear from the early docs that iCloud is meant to be that for the Apple ghetto and in the house of mirrors that is the current Google mobile strategy, something similar but distorted is soon to follow from them. It will be interesting to see how many other big players decide that they need something like this, but mostly to all of the “post PaaS” startups looking to do Heroku-for-X these days as this competitive field will likely set the number of likely exits.
As for me, I’m all for the smart edge and dumb centre— it somehow feels like a better substrate for creative people to make far out stuff.
NOW WATCH: Tech Insider videos
Business Insider Emails & Alerts
Site highlights each day to your inbox.