Is RSS at Risk? ~ tech support 8

I spent about a thousand words explaining RSS before I realized that, for the most part, if you are reading this blog I have to guess you have some familiarity with it (at least by just having heard of it). If you need some background, Wikipedia has a pretty good overview on RSS.

If you are a web site developer or author, there are three methods to get your Twitter feed or your Facebook business page information integrated into your site: via some sort of JavaScript-driven widget, via an API that is unique to each, or via RSS. This isn't limited to just Twitter and Facebook. PicPlz, Foursquare, and others provide these methods as well.

A JavaScript widget (whether via an embedded iframe or not) typically does not integrate well with a site, forcing the branding of the service, its color scheme, and its styles. For many sites, a Facebook widget or Twitter widget can look very out of place, almost like an afterthought. On top of this, because these widgets rely on JavaScript so heavily there is no alternative for those without JavaScript support (whether by choice, by restrictions, or by errors elsewhere on the page — see my post Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea)

The API approach gets around styling issues, but often each API has its own proprietary offerings and syntax, requiring you as the developer to learn it, integrate it with your own platform, and spend time maintaining it as the API changes (possibly on a whim). While using this method you have control over how the data is styled on your site, relying on a free service means that you will have less input and recourse should a feature suddenly change (as I say, free doesn't mean good: You Get What You Pay For). Many APIs are reliant on JSON solutions as well, requiring JavaScript to perform the calls, and therefore the rendering, unless you are processing all of the features server-side.

The third method I mention, and the point of this post, is RSS. Because RSS has a standardized XML structure behind it (spread across parallel but unique versions, not counting variants like ATOM), as a developer you always know what to expect from an RSS feed. A JavaScript developer can just as easily parse the XML structure as a server-side coder. Once you have built a function to parse and display an RSS feed from one source, you can re-use it for any other RSS feed, forking it if you want to present the data in a different way on your site. This means you have complete control over the presentation (HTML, CSS and code structure).

In addition, most blog platforms (I'd say all, but someone might surprise me with one I don't know) not only provide RSS feeds of their data (and can even rely on a service like FeedBurner to provide additional RSS versions), they also support RSS import. This little feature means that if you provide content from your site as an RSS feed, any blogger can integrate it into his or her blog with only a few clicks.

An example of just how robust RSS can be is demonstrated with podcasts (and even vodcasts). The structure of a podcast file is really just an RSS feed with attachments, much like you might attach a file to an email. A regular RSS reader should be able to process the file, even if it cannot play the music. A podcast reader should, conversely, be able to read a standard RSS feed, even if there is no music to play.

Another powerful adaption is GeoRSS, which allows geographic data to be embedded in a feed. Syndicated content can be associated with locations on a map, something which has proven to be useful to the rise of location-based social media. For example, you can get your Foursquare history as an RSS feed, with each location tagged with geolocation data. In fact, a precursor to Foursquare, Brightkite, allowed users to generate custom RSS feeds to track specific spans of time, locations, groups of users, and even control how many items to display. When it came time for Brightkite to shutter its location-based services, it made all user data available to its users via RSS feeds.

Because of these reasons I have typically ignored hype expressing that RSS is on its way out. And then I stumbled across the post Twitter and Facebook Both Quietly Kill RSS, Completely, which was followed up a couple weeks later with Facebook Listens. RSS Added Back to Pages. Will Twitter be next?

This reminded me of an exchange I had on the Picplz API mailing list, where I asked if they would update the RSS they provided with geolocation data (since most photos are associated with a venue pulled from Foursquare). I was told that the RSS pre-dates the API and essentially that there aren't any changes in the pipe.

In just the last few days I have been struggling with the new MapQuest, trying to figure out how to embed GeoRSS in the new platform. In addition, I noticed that my "classic" MapQuest maps were no longer showing the embedded GeoRSS. After going through the support forum I found that GeoRSS is not (yet) supported in the new MapQuest, and nobody had noticed that it appears to be broken on the classic MapQuest (the solution they told me I should use for now).

So now I find myself wondering about the future of RSS. When Google Chrome doesn't even show an RSS icon or format it for display, when a new location-based service isn't adding the GeoRSS features, when a major mapping service doesn't support GeoRSS in its latest release, when Twitter buries the link for RSS, and when Facebook toys with its removal, I am concerned that they are contributing to the eventual demise of RSS.

I understand that content drivers (Twitter and Facebook) who survive on advertising revenues want to drive their brand and, ideally, their advertising to end users. Widgets that include a brand and drive people back to the advertising on the parent site make sense. For services and platforms (Picplz and MapQuest), pushing developers to a proprietary API increases the developers' investment in your platform, making it less likely for them to peel off when they can't simply apply their code to the next shiny new thing.

Unfortunately, these all combine to make the barrier to content syndication higher for everyone. While we can still wield an RSS parser to syndicate much of this content (often the one built into a blog, but typically a module within a CMS or other platform), it may be a matter of time before we lose the freedom to rapidly and repeatedly re-use a tool already in our belt. It may also be a matter of time before we as developers forget we should always build an RSS feed when we are instead enamored with the ability to claim our product or service has an API — even if it's not offering any more than an RSS feed can offer.

As developers we need to make sure we are helping our users, future developers, and ultimately our clients, by leveraging standardized tools. When it comes to content syndication and generally sharing data, RSS is the common denominator and typically worthy of implementation as the first step in a solution. If we aren't continuing to use it and expect it, the walled gardens and self-congratulatory APIs will catch up to us.