Ask HN: Facebook canvas app vs. FB Connect/Platform? | Hacker News Reader

Ask HN: Facebook canvas app vs. FB Connect/Platform?

11 pointsneo5 comments

Given the latest Facebook announcements affecting developers, how would you weigh the pros/cons of betting on doing a Facebook canvas app as your user's primary means of interacting with your application (as opposed to going to your own domain which would then use FB Connect for login and other the FB API for other features such as friend picker, constant auth, profile sharing, etc.)? Some context: we're a social advice & reputation game.

By my calculation, it seems that the only a few benefits for developers in doing FB canvas apps anymore:

1) User doesn't have to open another browser window/tab to a site whose domain/brand they're not immediately familiar with.

2) If the user bookmarks the app, the app appears in the upcoming left profile/nav bar.

3) Presumably, I'd expect the new "secret sauce" FB newsfeed algorithm to include some preference towards native FB canvas app stories that can then be "liked" & commented upon from within the user's newsfeed/live feed.

A very prominent FB app company (top 20) told me that they're deprioritizing their native FB canvas app in lieu of their own site with FB Connect given they expect a "40-60% decline in native FB canvas app user activity with Facebook's recently announced changes". They think that Facebook can't be trusted to do well by developers since they're primarily interested in users.

Please mention if you're currently actively preparing or have already deployed a FB Connect &/or canvas app. Thanks!!

This is all from first-hand experience. I've been intimately involved with the Platform since its first launch and know most of the companies in the top 20.

Facebook has the destination site they want. You are not going to help them build it. The second you become even marginally inconvenient they will pay attention to everything you do and shut down your app without a second thought if they think it's in their interests.

They did it to Slide (Top Friends) and Zynga (FishVille). They will do it to you as soon as you even approach that level of success.

This isn't a condemnation. It's just the cost of doing business on the Facebook Platform. I like the fact that Facebook's motives are so transparent because (unlike Google) it makes it easy to anticipate how they'll react. They're completely rational and self-interested (for the most part -- the original live feed was a mistake, as was Beacon).

It's clear that Facebook has cared more about Connect than the Platform for a long time; at least a year. This latest change just formalizes it and finally incentivizes developers to build on Connect rather than the Platform.

See Scott Rafer's presentation "The Facebook Platform is Dead" from last October, where he predicts all of this.

But keep in mind, once Facebook has the Network they want, they're going to do the exact same thing they did on the Platform.

You are not safe there. If you're building on Facebook Connect you need an escape plan from Day 1.

Facebook giveth and Facebook taketh, and they will take.

Yep. Every developer/company that attaches itself to a larger platform (Apple Appstore, Facebook, etc) needs to ask "What would I do in the future if I were <platform company>?" and then build a strategy to account for that.

Company-sponsored platforms are self-interested moving targets just like everything else in business.

Just something to think about when you're coding iFartVille 3000.

There's a couple things to consider (having learned the hardway recently).

The company I work for, http://theinsider.com, uses Facebook Connect on our site. Before I started there, they had a fairly basic implementation of FB Connect that was put in place when that program was first made available. About 2 months ago I went through and re-wrote the entire FB Connect implementation our side to bring it up to date because the FB Connect API had changed a bit.

Within 2 weeks after we pushed my changes live, FB changed the 0.4.0 API we built against which resulted in some breakage on our side. This was pretty much without notice. So in the past week, I had started going through my code to update it again when I found that there is a completely new FP Connect JS api that is being released.

I got excited about it because the new api is much simpler to use, the js library is 10x smaller than the old one(which could pull in at close to 200kb at times), and its much better documented than the old one. However, its still alpha and we're having a couple of minor problems implementing it. That's mainly do to a change in the cookie structure, which is a problem we're addressing on our end.

The point of this is that in my experience, FB doesn't document much of their APIs in a consistent or well-organized manner. This is especially true on the FB Connect side of things. They can make sudden changes on their end that adversely affect companies and websites that are using their systems.

On the plus side, using FB Connect on our site has been really successful. We're getting more user interaction, more engagement, and higher page views at least in part of utilizing it.

The question of whether to use Connect or build a Facebook app isn't either/or. It depends on what kind of experience you're trying to build. The downside of FB apps is that they've been around for a while and have lost their luster. They really just clutter up a user's profile. Its much more difficult for users to find apps on Facebook now than it was a year ago, due to the constant changes that FB is making.

I'm currently building a flash game, that is primarily aimed at Facebook users. I plan to start it off as a FB canvas app, in order to establish trust with users, and after I have reached a critical momentum, I plan to switch over to FBConnect.

I've had a much harder time with Iframe apps (more bugs, less solutions) than FBML ones, for php implementations. Unless you have all the gotchas figured out for connect, you should go with FBML.

As for 2), doesn't this happen with XFBML, too?

Reply on news.ycombinator.com