My goal with this blog

I write about relevant changes in the way that people use the web and how startups are built to provide services and products for this ever changing wonderful thing we still know as "the web." As a former entrepreneur turned early-stage investor, my greatest hope is for this to be useful to other folks that are like me in the hopes that they can avoid some of the mistakes I've made.

Some small observations on: dumb center, smart edge?

Why most people seem intent on taking computing back to the mainframe era with all of the intelligence at the center 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:

(1) ...clientside Javascript has matured to the point where it is a viable interactive application runtime. Some of this is due to the focus on speed of execution that the Google Chrome team put on the rest of the industry, but just as important has been the emergence of rich client-side frameworks that aim to bring all of the MVC goodness of Cocoa or RoR to the browser. Whether it is a kitchen sink framework like Sproutcore or the significantly more slender backbone.js (and its kissing cousin spine.js), the amount of structure that can now be put into a client-side application takes us well beyond the spaghetti code tightly bound to the DOM that was the gold standard for webapps of yesteryear. Furthermore, all of these frameworks are starting to standardize on RESTful resource-oriented protocols for updating stuff on the server which brings us to the second point...

(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 favor. 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 center— it somehow feels like a better substrate for creative people to make far out stuff.