Web platforms

As a semi-follow-up to my post on the new Gmail interface a few weeks back, I wanted to link to the thoughts of Marc Andreessen on the present and future of web computing and application development. As usual for me, the post itself is somewhat old news, having been written in October, but I like to let ideas settle, then percolate back to the forefront of my mind before writing about them. Like development itself, the first version is usually wrong in some fundamental way, so I prefer to keep that first mental version to myself. The second iteration is usually wrong too, but within the accepted margin of wrongness known as right. Ruminate on that for a moment!

Back to the chase: Andreessen talks about the levels of platforms on the internet. For him, a platform is something that can be programmed against. His first tier platform is a read platform - data is pulled from the platform via a formal API, but the consumer of the data is completely independent of that platform. This isn’t much different from a screen scraper from 1997, except that the platform is aware that the data is being used programmatically. This is pretty much all of Web 1.0. Undoubtedly useful, and the most flexible for the developer of the data-consuming app because there is no platform mandated standard for app behavior.

Tier two is any platform that allows an external application to display within the end user interface. Essentially, a tier two platform provides defined hooks that a developer can latch onto to provide some extra functionality for the platform users. The application lives elsewhere, but that’s somewhat transparent to the end user. Andreessen cites Facebook, their new FBML, and sees this as an upgrade for developers from a tier one platform, but to me, there are a few drawbacks. Any new application is tied to the fate of the platform. The whole investment of time and capital into the application is completely dependent on the success of the platform company. Unlike operating systems and other local system software, which can live on after the company that created it, if a web platform hits a rough spot financially, the application’s user base and the application itself disappears. There is zero room for legacy systems in a tier two environment. Piggybacking on a tier two platform can be very powerful, but it is also very risky at this point. You know, that whole risk-reward thing. Undoubtedly, we’ll see the emergence of porting tools for tier two platforms, much like we see platform independent (ha!) environments like Java now. Of course, I’m assuming that tier two platforms will all have competition as time goes on.

Tier three is what Andreessen is pushing for… because the most recent company he founded provides a tier three platform. It’s essentially a public installation of Sharepoint server - application code lives in the tier three platform, displays in the platform UI to end users and leverages the platform for most of its functionality. Again, Andreessen sees this as a far superior to tier one and two for developers , but I feel he’s actually writing from the perspective of the platform provider.

If you’ve ever delved into UML, you know that there are several different ideas about what programming is. To some, it’s a whole lot of typing, for others it’s dragging widgets from a toolbox onto a canvas, for the architects, it’s diagramming. Essentially, it all comes down to how much control you want as a developer. There are certain expectations attached to every tool. Hammers are not designed to screw, plane or cut. If you want a tool that does those three things, and you only have a hammer, you’re in for a long day. Platforms are tools for programming, and as a developer, you need to be sure that the tool is right for what you’re trying to accomplish. Sacrificing control for ease is a trade-off to be analyzed, not accepted as the Golden Brick Road.

Afterthought: Joel Spolsky, also as usual, has some words concerning the relative futility of shuffling programming labor from tool to tool.