

How Facebook Mobile Was Designed to Write Once, Run Everywhere - zalew
http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php

======
samps
This article suggests that the new iteration of the Facebook app for iOS is
written mainly with Web technologies and the fronted runs in a WebView, which
explains why it sucks so much more than the previous version. Has anyone else
noticed lots of really sluggish content loading, occasional hangs,
mysteriously empty panes, etc? While the app is polished enough to seem native
(kinda), it seems to be an argument that Web technologies are not yet ready to
be an alternative to native UIKit development -- on iOS, at least.

~~~
adamjernst
What really intrigues me is that average users feel the same way; it's not
just us. Read the iPhone app reviews (current average: 2.0 stars). Ouch!

Facebook should hire back Joe Hewitt. His native app was fast and powerful, at
the very least. Is employing one talented full-time iOS developer really too
much to ask from a company as big as Facebook?

~~~
Splines
_Is employing one talented full-time iOS developer really too much to ask from
a company as big as Facebook?_

You might as well add the Python SDK to that. The "we don't have the
resources" claim rings a little hollow, in that the company probably very
likely has the resources, but thinks such things are strategically
unimportant.

~~~
tsunamifury
You may not have the experience of supporting a large web service, but I do.
Believe me, supporting native apps for multiple platforms is not only a
multimillion dollar money pit, but an integration nightmare. You end up
building a web interface anyways then hacking together a ui in native code for
every platform. The long term support structure can very quickly
(exponentially) get out of hand.

~~~
jasonlotito
I don't personally, but the people I work beside do, and it doesn't seem from
talking and working with them that it's as bad as you suggest, no where close.
Having launched successful apps on multiple platforms for a website, I've seen
it done successfully.

~~~
tsunamifury
Website =/= web service

Large saas, social media, and rich media delivery services have many times
more complex factors than a simple content site. Why do you think Netflix,
Facebook, many major banks and loan servicing institutions and most financial
portals have chosen the web app strategy. It's not just because they are
idiots and don't get it, it's that theyve recognized the unsupportable nature
of multiple mobile platforms with such limited penetration.

~~~
jasonlotito
Was referring to a "web site" akin to Facebook. A social network. Not merely a
"content site." So, that point is moot.

> It's not just because they are idiots and don't get it

Didn't suggest otherwise. But your reasoning is flawed, I'd imagine. Your
suggesting that they don't go native because smaller platforms have limited
penetration? If so, that seems silly. Why not support the platforms with large
penetration natively, and support the platforms with smaller penetration with
a web app?

I'm not suggesting going native for every platform, but going native for none
because you can't do them all is even more silly.

~~~
tsunamifury
I was referring to the actual penetration of mobile users vs desktop browser
users -- which is often on the order of 5% or less. This makes it a very
expensive investment for such a minority of users.

Besides that still leaves you with Android and/or iOS plus web -- two to three
times the development costs. This becomes very hard to justify for such a
small percentage of total product users.

------
dilap
Sure, it minimizes developer effort, but the end result of e.g. the iPhone app
is very uninspiring and clunky. Compare it to a true native app like Path if
this isn't immediately apparent to you.

(The use of the phrase "native goop" to describe the non-web parts seems
telling. They don't seem focused on the end-user experience, but rather
developer ease and (that old chimerical developer holy-grail) code reuse.)

~~~
statictype
_(that old chimerical developer holy-grail)_

There's a reason why this is important - it allows the 'native' app to stay up
to date with the desktop web app. Yes, the Facebook native app is less usable
and more clunky than it was before - on the other hand, it's feature-by-
feature more up to date with the main site.

Is that a trade-off worth making? Perhaps, perhaps not - but in the very
least, there's an argument to be made, right?

~~~
dilap
There's an argument to be made, but I'd still argue against it :) As a user,
I'd much rather have a polished, pleasant to use native app that lagged behind
a feature or two occasionally than unified junk. As others have pointed out on
this thread, FB's gotta have the dev resources to do separate versions (though
maybe not the kind of developers happy to be working on such a "boring"
problem).

I think code reuse is often a chimerical holy-grail because in and of itself
it is not a good thing; what matters is user experience, the amount of
development work, how easy it is to fix bugs, &c. But developers still often
obsess over code reuse, even at the expense of things that matter.

~~~
statictype
Often, code reuse leads to less bugs and less duplicated effort which leads to
more time spent on important things like features and usability.

Except that, I don't disagree with anything else you said.

Fogbugz has their own custom compiler that generates code for the platform of
their choice. Facebook has already written their own PHP->C++ compiler. I
wouldn't be surprised if they have some team there working on some high-level
infrastructure that lets them write UIs and code that gets compiled down to
custom Objective-C/html+javascript/AndroidJava/etc...

------
tomatohs
Facebook's goal is to penetrate as many markets as possible with the fewest
lines of code.

Does this mean they don't give a shit about experience? No. It means they want
to have a large reach without much maintenance. After that is accomplished,
then they can worry about experience on a per device basis.

I don't believe it's correct to just dismiss this as garbage because the
application is currently buggy. The entire idea of this approach is to improve
the experience across all devices, but for now they are limited because they
are still on the first step, implementation. Also note the slide that says
"betting on the browser," meaning that Facebook is betting that issues between
platforms will eventually fade away.

~~~
protomyth
> Does this mean they don't give a shit about experience? No. It means they
> want to have a large reach without much maintenance. After that is
> accomplished, then they can worry about experience on a per device basis.

Facebook maybe able to get away with this, but almost every other developer
and plenty of device makers will not get that second chance and will be
dismissed by customers.

This is the same thing that happened to cross platform Smalltalk programmers
(e.g. VW, VisualAge). They sure could target a lot of machines, but their
programs always acted crappy and slow with poor UIs. This is ok when your
"customers" are forced to use your program like a custom app for a business,
but it sure doesn't work for others. Even Adobe runs into user hate for their
non-native widgets and ignoring platform conventions.

Most non-technical consumers are good about getting a feel for how things work
on a platform (e.g. ctrl-c for copy on windows, smooth scrolling, metro on
WP7). This leads to a disconnect when an app behaves differently. They may not
be able to express the problem, but they will certainly notice it.

------
rvenugopal
How is this "Faceweb" approach different from Phonegap? I believe Phonegap too
does progressive enhancement as described in this article

------
daveambrose
To me, there's pros/cons to this approach with the perspective of making it as
EASY as possible for developers to ship across all types of hardware (which is
great). But the con seems so big to me: the end-user experience is so slow
(iPhone and Android) that when you think of "Facebook for Mobile", you think
"Maybe I can wait to access FB on my iPad or back on my laptop when I'm home?"

All of the native apps that I've seen, played with and analyzed, speed = to
some the best experiences for a user. I mean, doesn't a FB user want exactly
that when they check the Newsfeed? For instance, today, I turned off 4G and
moved to 3G on my Android, checked the FB app and it crawled. It junked new
screen loads, comments, liking, etc. Switching over to 4G made (some of) the
pain go away.

------
pinaceae
developer-centric vs. user centric approach in effect.

if you don't care about utilizing every inch of platform functionalities and
performance to achieve a great user experience - why bother with such meta-
apps at all? just let your user place a bookmark on the home screen and be
done with it. save even more developer effort.

from a pure user perspective, this approach can be summed up pretty simply:
"half-assed".

------
drivebyacct2
The new Facebook mobile site is gorgeous and is faster than the native app on
my Galaxy Nexus (for whatever reason the FB app takes ages to load, and ages
longer to load data after it gets off a white screen). It's so nice in the
browser and it's every bit as functional as the proper "app".

Sadly, they're doing some weird user agent sniffing and are giving me the WAP
site currently and are also telling me I have a Droid Bionic, so I'm not 100%
sure what's up with that.

After reading the comments here, maybe my experience is so pleasant due to the
power of the Nexus and the tuning in the 4.0 browser.

