Facebook Digs Deeper into the Black Hole of Custom Markup

Today, Facebook announced the ability for developers of Facebook apps to create and share custom FBML tags. The idea is that the tags would make some functionality the developers provided available to other people building things on Facebook. One of the launch examples is by iLike for creating and sharing music playlists. Read Write Web has a good intro if this is the first you’re hearing of it.

On one level, I’d like to applaud this move. It seems like a step forward in Mark Andresssen’s hierarchy of platform sophistication which distinguishes between “Access APIs”, “Plugin APIs”, and “Runtime Environments”. By letting independent developers share their data and functionality with each other using Facebook as a medium, they’ve significantly enriched the Facebook runtime environment.

This much is good.

However, the technical decision to use a markup language as the vehicle for this sharing seems to disregard much of the hard-earned wisdom the development community has won from two decades of experience on the web. As Pat Benatar and the browser wars taught us, Markup is a Battlefield. The divergence of markup implementations between the major browsers caused an epic nightmare from which the development community is only now starting to awake. Starting with custom tags and moving on to non-standard DOM behavior and rendering policies as the browsers got further and further apart, developing web content that worked reliably got harder and harder. Each of these moves towards divergence happened out of a dual motivation on the part of the browser vendors to both provide more value for their users/developers and also to gain competitive advantage. In the long run, the result was pain for everyone and a great slowing of technical innovation until these problems could be solved.

In the case of Facebook, implementing API features via markup causes problems on exactly the development pivot points where standardization is most important. Since FBML is neither XHTML nor XML, tools such as parsers and tag generation libraries built to those standards, many of which have had years of high quality feature and performance work put into them, are simply not available to devs building Facebook apps. At an even more basic level, the problem of viewing an in-development Facebook app locally is far beyond trivial. Since browsers can’t handle FBML, how do you render an app while you’re working on it? I know that there are workarounds for these particular problems, but we’ve had to develop them from scratch for Facebook specifically, which means we can’t rely on the great work of those who came before and our work will be helpful to fewer devs going forward. I wish that the Facebook API team would learn from this history and implement these great new APIs using existing standardized widely adopted technologies. Amongst their APIs that I’ve seen and worked with, I haven’t come across a single example that wouldn’t work great as a javascript library built on top of existing browser technologies along the lines of YUI or jQuery. Having this functionality exclusively in the realm of Javascript would make it easier to share code between wider projects and their Facebook-resident components (via Facebook ‘detection’ that was similar to browser detection). It would make our existing development methodologies and tools more effective in building Facebook apps. My bet is that it would even help with the security and privacy issues that FBML and the related technologies were specifically invented to solve; there’s lots of smart people in the wider world of web architecture thinking about those very problems.

The functionality provided in FBML is not markup. Some of it is user interface behavior and some of it is data access and APIs. On the web, this is what Javascript is for.

I understand the business case on Facebook’s side for the kind of lock-in that they get from creating custom technologies like this. Sitting in the middle of a giant mush pot of developers who are all staring fascinated at your every move must seem like perfect success for a certain kind of API team. However, in the long term, I think they’d create more value for themselves and others by taking advantage of the power of doing things the “web way”. More and better applications would be built more easily by more developers. And in the long run this would mean that there was more cool stuff to do on Facebook.

Tagged: facebook, markup, standards, javascript, html, fbml