Skip to content

Mapstraction

I briefly referred to Mapstraction in the last article, but wanted to draw a bit more attention to it.

The idea behind Mapstraction is to provide a common API for a large number of mapping services, (like Google maps, Yahoo Maps, and many others) abstracting away the underlying APIs, and providing a Javascript based library to access these major mapping services in a programmatically identical way. I really don’t see an industry consortium getting together to develop and publish a common API, at least any time soon, and indeed, this is arguably a better approach, being developed by client side developers scratching their own itches, rather than a committee of server side folks, who, even with the best will in the world, have a swag of interests that probably don’t align with the users of these APIs.

I feel that abstraction layers like this will become increasingly common, and more important, in fact, fundamentally important to maintaining the open nature of the web as we move toward an application/service based web, from a predominantly document based web.

The personal computer era was characterized by platform wars, in particular the Mac versus Windows battle for ascendancy. Fundamental to this were the platform APIs - with Win32 winning out. Once developers start focussing on a particular API, your increasing investment in knowhow, tools, hardware, and related services in that API ecosystem mean that changing platforms is very hard and expensive. That’s why developers who target both Mac OS X and Windows are rare. Ironically, Microsoft now face the challenge of competing with their own entrenched API - the aging Win32 API (32 standing for the once cutting edge 32 bit nature of Windows 95 and its successors) is not going anywhere soon despite I am sure Microsoft’s dearest wishes and efforts - maintaining backward compatibility with what is now an ancient architecture, while innovating is a huge resource drain.

The era of the web (especially since the rise of strong standards proponents in the later 1990s) has been characterized by notionally common APIs - the DOM, CSS, HTML - I say notionally, because anyone who has developed professionally for the web knows that there is sufficient difference in the implementation of these “APIs” from browser to browser (and even version to version) to render this more an ideal than an actuality. However, as I have taken to saying to folks these days, as someone who has spent the last decade targetting both the Mac (OS 8/9 then X, as well as Windows from 95 through to Vista) - if you think web developers have it tough with the browser inconsistencies, try targeting two entirely different platforms. Even at its worst, it is an order of magnitude less pain than writing software for both the Mac and Windows, and besides that several different variations of each. In the case of the Mac, on two different chip architectures.

The web of the last 3 or 4 years, increasingly one of data, services and applications, looks more to me like the world of the Mac versus Windows. Competing services provide different APIs, and once developers begin investing in those APIs (and similarly users invest in those services - using Flickr over Photobucket, or Facebook over linked in for managing our relationships online) changing “platforms” becomes increasingly difficult and costly.

So abstract APIs - Vendor Independents APIs (VIAPIs anyone?) - like Mapstraction, cool as they are, are in fact profound. They play a very similar role for developers (and so ultimately end users) as microformats, by abstracting away the underlying services, essentially making them interoperable.

We’ve far from seen the last of them, and while Mapstraction is almost certainly not the first such VIAPI, it may well be the first prominent one, and a pointer to a web of even fewer silos, and much more interoperability.

At the end of a long year, here’s to Tom Carden, Steve Coast Mikel Maron and Andrew Turner for doing something very cool, and very important.

I look forward to VIAPIs for photo services, social networks, and more.

{ 2 } Comments

  1. Erik Mogensen | December 14, 2007 at 5:11 am | Permalink

    Ah, but isn’t javascript also a platform? Do you discount the possibility of a newer and better scripting language as the de facto web programming platform?

  2. john | December 14, 2007 at 7:58 am | Permalink

    Erik,

    in a sense, Javascript is a platform, being the defacto standard language for web programming.

    It is however a standard in both the de facto and de jure sense - codified by a standards body (ECMA) and widely and interoperably implemented across essentially all modern browsers. In the medium term I would discount a newer scripting language (better or otherwise) becoming the de facto web programming language - standardization has become a given, both legally, and in terms of market expectation, and the cost of implementing a new scripting language, both to implementers and adopters is so significant, that I find it difficult in the medium term to imagine the drivers for the success of a new scripting language.

Post a Comment

Your email is never published nor shared. Required fields are marked *