
Ask HN: Facebook canvas app vs. FB Connect/Platform? - neo
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 &#38; reputation game.<p>By my calculation, it seems that the only a few benefits for developers in doing FB canvas apps anymore:<p>1) User doesn't have to open another browser window/tab to a site whose domain/brand they're not immediately familiar with.<p>2) If the user bookmarks the app, the app appears in the upcoming left profile/nav bar.<p>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" &#38; commented upon from within the user's newsfeed/live feed.<p>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.<p>Please mention if you're currently actively preparing or have already deployed a FB Connect &#38;/or canvas app. Thanks!!
======
jfarmer
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.

~~~
rykov
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.

------
geuis
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.

------
chaosprophet
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.

------
cellis
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?

