Big changes coming to Facebook Platform

Today’s Developer Roadmap post by Facebook has outlined some big changes coming down the pike for Facebook Platform. Here are the big 3 changes (well, as far as we see them):

No new FBML apps

Facebook will no longer accept new FBML Canvas applications by the end of the year. These are the types of applications that launched the Facebook Platform way back in 2007 (the same year that saw the iPhone and The Simpsons Movie). FBML apps have a lot going against them, most importantly is the fact that there’s really no good reason to write them anymore. It used to be that developers who wanted to write Canvas applications had to choose between FBML and the simpler but not-as-powerful IFrame method.

But IFrame has now caught up and surpassed FBML in terms of power, so there’s really no reason why a developer building a new application in 2010 should even consider using FBML. There’s also another issue at stake here. FBML Canvas apps require all of the data traveling between a user’s browser and the application itself to be routed through the Facebook servers. This is a legacy design from 2007 that was done to give Facebook more control, and allow for user authentication, but it’s costing Facebook a lot of money to run these servers that do very little but act as proxies.

Since new FBML Canvas apps no longer provide any real value, and they cost Facebook a lot of money to support, Mr. Zuckerberg et. al. would like to just sweep them under the carpet. Looks like that’s what they’re doing.

Parts of the Classic REST API are being deprecated

Whatever we said about FBML apps is doubly true of the Facebook “Classic” REST API. Born in 2007, it now looks like patches upon patches with no coherent vision. It’s been so far surpassed by the Graph API that Facebook never even bothered to mention any non-Graph API support for their very important location updates yesterday. It’s been clear for a long time that this API needs to be put to rest, and deprecating parts of it is definitely the beginning. We can all say Amen.

OAuth 2.0 will be required for authentication

Another nail in the Classic REST API coffin. OAuth 2.0 goes hand in hand with the Graph API that Facebook would like to push everyone towards. Enough said.

Facebook has historically moved very quickly, which contributes to a good part of their success. Moving quickly means getting things out to customers quickly rather than perfectly and dealing with the consequences later. Today’s Developer Roadmapupdate is a good example of how to deal with those consequences, and will ensure that Facebook developers will continue to have loads of things to do as Facebook continues to innovate.

K&R and thoughts on the Graph API

With this post I’m going to do something I promised myself I wouldn’t do while writing this blog - kvetch like an old grumpy man. But there’s a point:

While I was in San Francisco for f8, I had the good fortune to attend an informal meeting of Facebook developers to discuss the changes to the Platform that were announced at f8. It was graciously hosted at the offices of one of the leading Facebook development companies in the city. They were beautiful offices high up in an historical building with great views, and more Red Bull than a developer could drink.

While there, I noticed a copy of the iconic Kernighan and Ritchie (K&R) book on the C language sitting on a desk. What transpired was a short conversation between myself and one of the employees of the company:

Me  : Very impressive, someone still reads K&R.
Him : <Blank Stare>
Me  : The Kernighan and Ritchie book on C – it’s a classic
Him : <Blank Stare>
Me  : You should read this book, it’s so beautifully written. Look how thin it is, and the whole language is thoroughly described with examples and exercises.
Him : Yeah, the Rails documentation is much thicker
Me  : <Blank Stare>
Him : That’s our CTO’s desk – it’s probably his book

Okay, so the point here is that I’m realizing that you can actually get a degree in Computer Science without ever reading K&R. Without learning C. Without really understanding what goes on at all levels inside the computer without it all getting abstracted away. I was starting to feel bad that this whole drag-and-drop Rubyization of the world was creating developers who weren’t grounded in the basics. Who didn’t deeply understand how to properly analyze an algorithm. And who probably didn’t read stuff from guys like Joel Spolsky who kvetched about it all.

But then something else crossed my mind. The reason I love C and K&R so much is because it works on so many levels. You can use it to develop (practically) on the bare metal. You can use it to write customer-facing applications. You can use it to build a server. However, it’s becoming true that the higher off the metal you get, the harder it is to use C (or even C++). Web apps, Application Servers, Multi-tiered architectures, virtualization – all of these things are so much easier to do with more “modern” languages. And you know what, I’m okay with that.

So here’s my wish: Go get a copy of K&R and read it. I used to own 3 copies: one for work, one for home, and one for lending out. Even if you never plan to use C, please read it. It’s the best technical documentation you’ll ever read, and something you should aspire to. And the reason this is true is that the language is robust and, most importantly, simple.

Which brings me to the new Facebook Graph API and the way it simplifies everything. I think we should all say Hurray. K&R reminds us that simple does not have to mean not powerful. And what the Facebook guys did with this API reminds me of what Dr. Kernighan and Dr. Ritchie had done previously. Go read the book so you too can be inspired to continue building things that are both powerful and simple.

Postscript

For sheer entertainment value, you can’t beat the first version of the Java Language spec. In particular, check out the index entry for index entries to see all of the great references they included, and see how many you can understand. Their description of multiple inheritance (Section 20.3.5) is inspired, obscure, and absolutely brilliant.