I’m done building Facebook apps for clients

this is the thing about monopoly - the only recourse one has against it is to whine.

In case anyone didn't see it down at the bottom, this comment was left on the post:

  Ryan (& Everyone Else) –

  My name is Mike Vernal, and I manage the engineering team for Facebook
  Platform.

  I understand and am legitimately sorry for the frustration you guys are
  experiencing.

  I think there were three themes in this post — frequency of change, bugs,
  and documentation. I wanted to give you some more context on all three
  points, not as a way of excusing the problems you’ve had but as a way of
  adding some additional context.

  Over the past year or so, we’ve been pushing to simplify and standardize
  our development platform as much as possible, to address some of the root
  causes of the issues you point out here. For instance, we’ve been trying
  to move from FBML to IFrames over the past year because we think that
  IFrames are both a lot simpler to develop for and a lot simpler to
  maintain because they’re based on standard web technologies. We’ve also
  been moving towards simpler ways of integrating Facebook context
  (e.g., iframe-based social plugins) because they’re easier to use, debug,
  and maintain.

  Our end goal is to have a technology stack that is simple and
  standards-based, because we believe that’s actually the best way to
  address many of the issues you raise here.

  In terms of bugs, you’re right — we haven’t been doing a good enough job
  here. We’re working on this. We’re triaging bugs on a daily basis and
  working through the bug backlog. We’re continually adding more automated
  unit + functional tests to help prevent regressions and issues in the
  first place. And we’re working on our communication processes — the way
  the system works today, we actually copy verified bugs from Bugzilla into
  an internal bug tracking system, and we then use that internal bug
  tracking system to drive bugs to resolution. We don’t do a good enough
  job of communicating back to the Bugzilla bug the internal status and when
  we actually push a fix, which we’re working on. 

  In terms of documentation, again, you’re right. We’re building up a team
  and focusing on this as well.

  That said, actions speak louder than words. If you don’t see meaningful
  improvement by the end of October, please let me know. My email is
  mvernal@facebook.com.

  Thanks,

  -mike

Yup, the whole point of putting a `Like` button your page is so that site visitors can broadcast your page to their friends. However, to cause that broadcast to actually occur you have to put a bunch of Open Graph meta tags on your page and also (I think?) have a registered Facebook Application to go along with your site.

There's no place that's documented except for the developer forums.

Most smaller operations are going to be pretty much writing software for a primary target platform.

It is nice that there are technologies like cross-platform application framework or CSS, that let you create code for your target platform that you might just be able to port to another platform at a later date. But that doesn't take away from the fact that you're likely going to be betting on a given platform at a given time.

Perhaps what you want to say is "don't develop for a platform that will stand in the way of you porting at a later date" - indeed, all the walled-garden stuff seems to have this lock-in quality and would make sense to avoid - if you have a choice.

Very interesting. As an FB developer, some of the bugs they introduce (and re-introduce) are baffling. Their QA process always appears non-existant.

I'd like to believe him, but would have to see it first. We often file bugs that sit there forever, and some parts of their platform break on a weekly cycle, if not more often.