There’s been no shortage of discussion on Facebook of late — Facebook as the new Google, Facebook vs MySpace, etc. etc. — and their overall strategy deserves some discussion, to be sure. But you’ve read all of that by now. As with any great period of hype and furious activity, there are also by now some misconceptions about what you can actually do with Facebook from a practical perspective. I obviously have no idea what I am talking about, but here are some observations after writing some Facebook code (for Cruxy) for a little while now, and why I think all those Facebook apps in your sidebar aren’t what is going to matter.

• Embedded Facebook applications still run externally. This seems to get missed quite a bit by folks that have not actually looked at the FB technology offering. Whether in an iframe or via FBML, Facebook “applications” are still essentially executing in an external website — when you are interacting with a 3rd-party application via your Facebook account, you’re interacting with an external site (integrated at the presentation layer). This is a very efficient way for Facebook to balance the extensibility they want to get for their platform, with a relatively (actually, very) simple technical solution. Of course, it does mean the user experience of Facebook is beholden to some extent to the external application developer — if your app goes down, then the user’s Facebook account is impacted. This is the right gamble to make, kudos to them for doing it — the carriers could learn a thing or two about balancing control and openness from this.
• The Canvas concept is cool, and FBML is not “their own language”. I would attribute that quote except for the fact that I have seen it so many times I wouldn’t know where to start. The concept of the Canvas is essentially that Facebook can render your own application pages within the context of the rest of their UI, by virtue of the Facebook platform sucking in your presentation markup, combining it with the rest of the Facebook presentation, then sending it down to the browser. They do the iframe thing too, but the canvas goes a step beyond in that you can use additional markup tags, referred to as Facebook Markup Language, to make your application share more of the look-and-feel of the rest of Facebook. It’s obvious why they did this — to allow application developers to build a look and feel that closely resembles the rest of the Facebook experience. Custom tags are nothing new on any large web project, it’s amazing that this has gotten so much negative attention for standards non-compliance. Aside from the presentation-vs-data argument, which you could make to a degree, reverse engineering some CSS to get your app to look like something else is a tried-and-true tactic, and what Facebook has done here is offer something much more compelling and convenient for the developers. Custom tags are a form of modular ui development, and they work, and if they hadn’t done this we’d all be hacking up our styles to try to match the Facebook controls anyway.
• The Facebok Profile elements are not truly dynamic. When you have your application add something to a user’s Facebook profile, you’re basically just injecting a piece of static markup into their profile. This makes a ton of sense for performance reasons (you’d hate to see the core “view some user’s profile” operation get bogged down with external server access). It does, however, get interesting when you’re trying to put some dynamic content in there. No timers, etc., the only way I’ve found to really do this is to have your own server responsible for initiating the periodic updates on its own, which means your own server has to deal with persistent user authentication sessions and such. Look at all the Facebook apps for example that don’t update your status until you actually go and interact with the app, and give it a chance to run something to update your profile markup, or the abundance of “refresh now” buttons on third-party profile elements. Anyway, I point this out to draw the distinction that Facebook profile elements are not really dynamic application components a-la some other widget/nugget/snippet systems, and this is very much intentional.
• Development lifecycle management services are weak. Down the road, it’ll be nice to see the way you manage applications, associate them with developers, etc., improve. This is the one area where I think the model really falls down right now. You need to be able to easily share API access keys and application ownership (from the developer standpoint) between users, make the app available to multiple users for testing without opening it publicly, put it through test/release cycles, and all the rest. This will get better, it’s one of 80/20 things right now.
• The Facebook API, separate from the embedded “Facebook Application” experience, is powerful. A set of web services (REST) offering the ability to manage friend data, interrogate it, etc. , whether or not you’re actually building an application design to be experienced through the context of your Facebook account. And this leads us to our conclusion.

In general, the power of the Facebook platform is NOT in the Facebook-resident applications, but in the non-Facebook applications that use Facebook services. There has been some discussion on whether Facebook apps are widgets, whether they offer better extensibility than MySpace (here, here, and here are some good examples), and related. There are some good thoughts here. Personally, though, I think the compelling point isn’t that Facebook is a new platform into which you can inject dynamic application content (widgets or otherwise). It is that Facebook offers a platform API that you can use to build social networking functions into your own, separate, application. This is clear, but this is not what everyone is talking about. Even though Facebook is the cat’s pajamas right now, and yes it’s a cool destination that a lot of people go to, over-time it’d be hard to imagine a single destination where everyone in the known universe would go to use all kinds of disparate applications integrated only though their set of “friends”. Social networks, over time, are inherently too interested-oriented for this to be a viable model. The brilliance in this overall move by Facebook is not as a super-extensible, friend-to-all-developers application container, it is in its ability to, through the APIs and not just through hosted canvasses, offer a core social-networking library to web developers. How relationships are managed, navigated, etc., is value Facebook can add. Being a one-stop shop for all of your application needs is interesting at the moment, but not going to be the long-term success of Facebook.