We Like FBML
As a developer, I am far more interested in coding in FBML than in HTML for the following reasons:
- It’s a superset. FBML isn’t a “proprietary language,” it’s a set of tags added to HTML that make it easier to write social apps. With FBML, I can show or hide elements of the page based on whether two users are friends — it’s a simple tag that Facebook handles on their side. If I were using HTML, it would be up to me to figure out if the two users are friends through an API call.
- It’s high performance. With FBML, I can add features and logic to a page without my server doing any work. This is because certain features of Facebook (ranging from friend links to wall functionality) are just built in and are reduced to simple view elements.
- It’s a view layer. If you knew nothing about CSS, you could still create an attractive Facebook page with an appearance consistent to the rest of the site just using the built in tags.
As a developer, FBML is handing parts of the logic of my app, most of the appearance, and offloading work from my server. OpenSocial, as we currently know it, offers none of these features and touts that gaping hole as a key advantage!
OpenSocial is Java
I’m far from the first person to compare OpenSocial to Java, but I agree that the comparison is apt. When I was in high school and read about Java, I was excited that there would finally be a platform that would run all the world’s software regardless of the hardware and OS it ran on. Java made a huge splash but it took a long time for the reality to come anywhere near the hype. The challenge for OpenSocial will be to get real apps running in real containers in a way that resembles something more than some interesting demos. That plus a real security model would do the trick.
A Press Piece Masquerading as a Technical Feature
If Facebook developers aren’t excited about a platform that uses open standards, who is all the talk about open standards aimed at? Developers who haven’t written social apps yet? The ones who have been chomping at the bit with some really great ideas, but have been waiting on the sidelines because Ning didn’t have a platform yet? Obviously, it’s something that sounds technical, but it’s PR. Open standards sound good, proprietary language doesn’t. Which makes it too bad that…
OpenSocial Needs Its Own Markup Language
OpenSocial needs its own markup language to be successful. There needs to be a clean way for containers to extend that markup language and API calls in a namespaced and gracefully degrading way. It would be a significant change in the architecture of OpenSocial to do it, but I believe it’s necessary. Otherwise, all we’ve got are iframes — widgets with some small degree of integration into the container.
OpenSocial is an Opportunity
I’m annoyed at this one aspect of how OpenSocial is being positioned, but at a higher level, I still think it’s a good idea with lots of potential. I don’t believe for a moment that developers will be able to write once and run anywhere if their app has any interesting functionality. But I also don’t think it’s necessary to have 100% parity on all containers. The best thing about Facebook apps is how well they integrate with Facebook. To write a really good OpenSocial app, it should be focused on particular containers and integrated with the unique features those containers offer. I’m also glad to see other networks start to open up and offer a little healthy competition against Facebook’s platform. As Facebook app developers, we’ve already received inquiries about OpenSocial development and intend to pursue it aggressively. Should be pretty easy — it uses open standards!
Thanks for the last two posts; some great insights into these new platforms, and well-written!