
Facebook explains what's wrong with the mobile web - patrickaljord
http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html
======
TazeTSchnitzel
Personally, I think the problem is people trying to be too clever, and loading
too much content at once.

Loading tons of JavaScript means that Facebook loads very slowly on my phone
on mobile internet. And what is it needed for? The most the JS needs to do is
make a pop-down notifications panel, and do one or two AJAX requests to post
comments and "like" items. Looking at the Network panel in Chrome, I see
Facebook has pulled down 700KB of JavaScript. Why? How could they possibly
need that much code?

Facebook also seems to think that sending full-size images down to my phone,
instead of compressed previews, isn't a problem. No wonder the GPU memory is
exhausted!

~~~
ender7
If the argument is that "you're using too much Javascript" then we all might
as well just give up on HTML5 applications right now.

Sure, we can break up our JS into modules that only get loaded on-demand
(something that is quite hard to do, by the way), but _eventually_ there will
be lots of Javascript on the page. Because, you know, it's an _app_. Any app
of decent complexity will involve a lot of code. By definition.

(as far as image previews go, I agree, that's stupid. Especially given the
performance concerns with large images on mobile browsers)

~~~
stcredzero
_> If the argument is that "you're using too much Javascript" then we all
might as well just give up on HTML5 applications right now._

That doesn't follow. We'd only have to give up if you _had_ to have that to
display that amount of content. UX should come first. If you don't take care
of your customer, someone else will do it for you.

------
weej
Developers need to treat mobile computing more like 1980/90s micro computing.

You have limited resources with numerous environmental factors that need to be
accounted for and respected (ex: bandwidth, latency, CPU, GPU, memory, UI/UX,
async task handling, and most importantly BATTERY LIFE).

It is a different mindset when developing for mobile that needs to account for
finite resources. If you're greedy, careless, or just don't really think
through and test your app appropriately it makes for a horrible user
experience.

Regarding the HTML5 vs. Native Apps:

HTML5/CSS/JS and frameworks that allow you to write once and convert to native
apps (ex: Phone Gap) have their place. The core take away is that without
developing native apps directly you’ll never get to maximize the phone’s
hardware and performance will suffer. UIs will be sluggish and network IO
suffers from high latency (wrappers).

HTML5/CSS/Javascript frameworks like Phone Gap cannot take full advantage of
the hardware and SDK features like alarms, custom hardware
access/config/acceleration, background services, and (taking advantage of) the
standard UI controls (transitions, buttons, look ‘n feel).

If you’re focusing on content display/information consumption and your app
doesn’t need to rely on high performance from hardware and the UI then HTML5
is most likely a good fit. If performance, high availability/background
service, native look and feel and the such is critical to an app then native
is a better route.

My 2 cents.

~~~
se85
Very well said, in my experiences with building mobile apps that _HAD_ to
perform at close to native speeds with HTML/CSS/JS and Nitro/PhoneGap this is
exactly how you need to treat the mobile web if you want things to perform.

You really cant blindly rely on any 3rd party code, or take first party code
as a given without means testing it, you need to be able to build
functionality from the ground up ensuring that performance is the number one
priority, or extensively test and research each library before introducing it
into your codebase to make sure it doesn't have any future gotcha's with
performance - and more often then not, you will find multiple gotchas, till
they start adding up and you end up with something like the old Facebook App.

There is no sandboxing in JavaScript, so one mistake can mean the difference
between an app that performs and an app that lags, and hundreds of mistakes
accumulating with no quality control at all, as seen in the old FB app, is
just completely unacceptable.

I really can't understand why this is so difficult for Facebook to comprehend,
did they not have any JavaScript specific developers assigned to the project?
Did they assign a bunch of php developers to do this? What really caused this
failure?

The fact they are using the technology as a scapegoat for their own
incompetence is a pretty dishonest way of going about shifting the blame for
their failures away from themselves, but I'm not one to believe in company
wide conspiracies.

I think it is more likely that this whole thing probably got escalated by a
bunch of "web" developers who were in over their head and decided to blame the
technology stack and escalate that message to management, instead of the
truth, which is that they messed up really really bad!

Don't blame the technology, blame the implementation!

edit: some minor edits to the phrasing of a few sentences.

~~~
lttlrck
Well said.

Zuckerberg recently admitted on AllThingsD they burnt 2 years going done this
path. That's not just a bunch of web developers, that's a clueless head of the
mobile division.

~~~
se85
Thanks, I just read that article.

2 years for that? Thats embarrassing as hell, I can see why he is lying
through his teeth and deferring the blame.

It seems that every time Zuckerberg talks, he's just more and more full of
shit, can't say thats surprising though! Its a trend that has been around
since before FB was even in existence.

------
jlarocco
Almost all of their problems are due to them expecting mobile phones to behave
exactly like desktop computers. And then they're unwilling to change anything
on their side when they run into problems.

For example: "It's typically a problem on the newsfeed and on Timeline which
use infinite scrolling (content is prefetched as the user scrolls down the app
and appended) and end up containing large amounts of content (both text AND
images). "

Well then don't use infinite scrolling when sending data to a phone and have a
"next page" link. Problem solved. It's an easy solution with negligible end
user consequences.

And there's a lot of whining about running out of memory because of "too much
content". Then send less content. It's impossible for a person to see very
much content at once on a phone, anyway, because the screen is less than 3x5
inches. You don't need to send a person's entire "timeline" just so they can
see 3 entries at once.

~~~
javajosh
_> "Almost all of their problems are due to them expecting mobile phones to
behave exactly like desktop computers. And then they're unwilling to change
anything on their side when they run into problems."

Do you have _any* evidence for this wild claim? It seems like your second
paragraph is an attempt to infer some evidence for a much narrower claim, that
FB has unrealistic expectations of browsers, but even that doesn't pan out.

Infinite scroll in a web page, mobile or otherwise, is a valid UI choice, and
if the browser can't support that, then it's the browser's fault.

Your last paragraph also doesn't make any sense. Nowhere did the OP claim to
be sending the entire timeline to show 3 entries. This is, at best, an
exageration, and at worst a fabrication designed to harm. But your use of the
word "whining" implies more of the latter, and therefore that your hatred of
FB is actively affecting your judgement.

Because you're post is information-free and shows evidence of a strong
negative bias, I'm down-voting it.

~~~
joemoon
> if the browser can't support that, then it's the browser's fault

If you're creating a subpar user experience, then it's your fault. You can
blame the webview all you want, but your users are going to blame you.

~~~
kc0bfv
Right. They know that, even if they haven't done much about it. They want to
be able to make their page slick, and a good user experience. This post
documents their problems and provides a path forward.

Kudos Facebook.

------
Zenst
Hmmm what is that old saying, a good workman does not blame his tools! Mobiles
today have more processing power than the old C64, Amiga and atari ST, STe,
TT. probably combined.

If they are having issues with memory and that appears to be the crux then
they need to redesign how there doing things. Just becasue you can chuck a
blob of content at a desktop webbrowser and chew memory like it is going out
of fasion does not mean you can be as lazy with your design when it comes to
thinner clients like mobiles.

The best optimisations come from a good design and whilst there desktop model
of doing things may work for them it does not mean the same approach can be
taken with thinner clients that will notice you chucking a ton of content
initialy.

The other thing is that all that Facebook are trying to do has been done in
one form or another by others and to read about facebook in effect complaining
how a entire platform is broken is not only wrong but concerning as there are
people who will take what facebook say as gospil and it is far from it that
this could end up being distorted if the tabloid news level types get hold of
it.

No platform is perfect and there will always be area's you want to change but
in this case it is facebook's approach that needs to change. I also have to
question if it is facebook beyond some forum email post as it is not on there
main site (not that I'd ever know).

Out of interest G+ works fine on my low memory android device, though the
previous version was better IMHO for my device as the new version does cater
for larger screens nd tablet factors more so I feel, but it still works fine.

I'll also confess to not ever touching a facebook application so when I read
this I do wonder how bad they are and wonder how they compare in usage
performance wise and would love to see a article comparing network usage and
phone resource usage for typical actions like uploading a picture for a post
or replying to a post with a picture in it, those type of things.

------
robomartin
I think a point is being lost here. It's easy to try to slice and dice FB and
their app. The post is about what is needed to make mobile web apps better FOR
EVERYONE. Don't discuss what FB can our could have done differently. It is
obvious that they've looked at this long and hard. Their post is very valuable
in bringing to the surface issues that affect the entire ecosystem, not just
one app.

~~~
javajosh
Yes. I'm rather shocked and appalled at how quickly people here have chosen
(without evidence) to dis FB's development efforts. The OP's message was an
informed, specific, actionable, and well-reasoned critique of the mobile
browser environment for ALL APPs. And it seems clear that FB was trying really
hard to make it work, but ran up against some very real browser and tooling
limitations.

------
augustl
Another thing I really miss for single page web apps (mobile or not) is iOS
style memory warings. It's an event that is emitted when you reach memory
limits, and in it you should clear out everything that the user doesn't
currently see (read: clear out as much as possible). This allows you to keep
DOM subtrees in memory when you navigate the app, in order to make navigating
back to previously seen sections of your app very snappy. At the same time you
don't have to worry about infinite memory growth as the cached in memory DOM
subtress will get nuked when the memory warning emits.

~~~
javajosh
Yeah, that's fucking hot. Imagine an onmemory event in the DOM. Juicy.

------
k2xl
"- Simple way to implement pull to refresh (via dedicated off-bound-scroll
events?). "

At first when I read this suggestion I thought it didn't seem like something
to include. This would force every smart phone to support this type of
scrolling wouldn't it?

I think there's an issue with many developers just doing too much on mobile
web without realizing the limitations of the device they're using.

People today are used to developing on systems where they don't have to think
about memory, hard drive space, or performance. But when you get to mobile web
you have to think about these things AND more (screen resolutions, landscape
vs portrait etc).

The problem with many suggestions for w3c is that they are often tied to what
specific companies (ahem Apple) are integrating (or not).

In terms of the Facebook app, I (along with many others) have just been
flabbergasted that they've not been able to make their app load fast. Tobie's
post gives some great insight, but I don't think it's impossible to create a
smooth, well run webview - especially when you have the resources Facebook
has.

~~~
54mf
It's definitely _possible_ to build a Facebook-like app with HTML5 that's
fast. I won't assume why they couldn't - my instinct is that the app is
significantly more complicated than it appears - but I am a bit confused by
some of their concerns. Pull To Refresh is trivial to implement with JS; I
know, because I've done it. Perhaps it wouldn't have worked with the code
structure they were using, but still, confusing.

~~~
mrwilliamchang
Given that the request for a pull to refresh API is a subpoint to "Scrolling
performance", I am guessing they found that their implementation of pull to
refresh had all the drawbacks they listed under "QoI issues".

From the post, "[Scrolling performance] is one of [their] most important
issues."

~~~
othermaciej
Yeah, achieving many of the scrolling effects they want often requires sites
to do scrolling entirely "by hand", which degrades the quality of scrolling.

------
tmanderson
Is it just me, or did a lot of this come off as "why can't everything be done
for me?"

The fact is, performance can never be ubiquitous, because there's always going
to be many manufacturers with many different devices -- that while all
implementing the same standards, handle things differently.

This problem is alleviated by the age-old web term "graceful degradation," and
when done right, can be exactly that -- graceful. That's too hard though,
right?

Developing front-end for the web is hard, and developing for the front-end of
the web WELL is much harder. I always hated Facebook's app because it wreaked
of shoddiness and flaunted it's lack of thoughtful development.

I can't help but feel that they went and hired a bunch of brilliant
programmers that had zero experience developing for the web. Developing a
front-end web app can be (and often is) a horrifying thing to any developer,
because the environment is so volatile (and really, unlike any other
development environment).

I'm extremely disappointed in Facebook because had they done things right, it
could have been an awesome thing. Instead, they released a shitty hybrid app
that was doing everything wrong, and then gave up and wrote this whiny and
semi-ridiculous list of what they want because "things are just too darn
hard."

~~~
bslatkin
This.

Finding rigorous engineers is hard.

------
erichocean
Blossom[1] works around the scrolling issues by drawing everything in the UI
to canvas elements, including "infinite" lists of the kind Facebook and
Twitter favor.

Because the canvas element in lists are a fixed size, we never, _ever_ hit
against resource limits and it always stays snappy.

That's allowed us to use native scrolling (plus an async JavaScript helper)
that works correctly on all supported mobile platforms (Safari, Chrome,
Windows 8).

[1] <https://github.com/erichocean/blossom>

~~~
je42
on how many android devices have you tested it ?

------
coliveira
This shows clearly that Facebook doesn't get mobile development. They are
trying to shift the blame for poor application performance from themselves to
the makers of mobile browsers. The point is that users don't care where the
blame is, they just see poor performance. The sensible thing for them to do is
to recognize that user experience is the most important thing and use the best
vehicle to solve that problem, be it a very thin html5 client or a fully
native app.

~~~
jarcoal
Maybe they didn't get it before, but they're following your advice now by
building for their users, not their convenience.

------
sabret00the
And there we have it. What I find super interesting is despite this setback
for Facebook and the failure of ChromeOS, Mozilla will still push on with
Firefox OS (B2G) when the resources are much needed elsewhere. Oh well...

~~~
TazeTSchnitzel
By what criteria has Chrome OS failed?

~~~
sabret00the
Chrome OS's only real milestone at this point is the fact that a few OEMs
decided to give it a go. It's certainly not eating away at any market-share.

~~~
thurn
ChromeOS is years before its time. It's an aspirational operating system where
Android is a realistic one. That also means that it's a little early to pass
judgment.

~~~
fierarul
If you judge the user base or commercial success it's pretty easy to pass
judgment and say it failed. I can't even buy one on amazon.de!

If you assume ChromeOS will be maintained for years to come by Google (because
they can afford it) and it will be improved then it might have a chance of
becoming something big.

So the only reason you say it's 'early' is because you assume Google will keep
it alive long enough to have a fighting chance.

------
realrocker
The chimera of using simple JS/CSS/HTML to develop mobile apps has failed.
HTML5 and WebOS put up a good fight but they are obviously not enough. Maybe
the direction to go from here would be to make native mobile app development
simpler for the Web guys and not the other way around. Maybe something like
the awesome Kivy Project which helps you develop solid opengl apps in python
for multiple platforms: <http://kivy.org/#home>. I would love to see Facebook
put their resources into something similar to this.

~~~
randomdata
> Maybe the direction to go from here would be to make native mobile app
> development simpler for the Web guys

The way I see it is that in order to build a quality web application, you need
to implement the same patterns and structures that the native developers have
been using for years. Once a web developer is comfortable with that kind of
development, the target platform doesn't really matter. Your code is going to
end up looking _very similar_ whether you target HTML5 or a native API.

We somehow built up a mindset that HTML5 is easier to develop with. That
couldn't be further from the truth from my point of view. It is just another
platform. HTML5 may only seem easier because quick and dirty "hacks" are still
accepted, whereas most modern native environments try to promote best
practices from the very start (MVC, etc.).

~~~
realrocker
I don't think mere MVC(in the general sense) implementation will do the trick.
The problem with Native App Development is threefold: 1\. Is not Cross-
Platform: Web Developers are comfortable with their code running everywhere
without even thinking about it. 2\. Has limited access to hardware libraries:
Same as above, the developers doesn't need to worry about the hardware. 3\.
Uses statically Typed Languages: Web Developers who would rather code in PHP,
PYTHON, ROR, JS are forced into the intricate worlds of Objective C, Java &
C/C++.

The problems with HTML5 are more real. The necessary tools are just not there.

~~~
randomdata
> 3\. Uses statically Typed Languages

Objective-C is kind of an odd duck there. I think for all intents and
purposes, Objective-C can be treated as a duck-typed language and shares many
of the same conventions as Ruby, given their shared Smalltalk heritage.
Consider the following code:

    
    
      NSString *string = [NSArray arrayWithObject:@1];
      [string isKindOfClass:NSArray.class]; // Returns true
    

Which compiles and runs just as you would expect the equivalent Ruby code to:

    
    
      string = [ 1 ]
      string.kind_of?(Array) # Returns true
    

I would even argue that Cocoa (Touch) shares many similarities to Rails.
Someone coming from a Ruby on Rails background should feel right at home on
iOS, though perhaps less so on other platforms.

------
clebio
The part about needing better development support, debugging tools and such,
for mobile browsers seems valid. I'm not familiar enough with that to really
say, but I've felt similar things from my limited use of Chrome developer
tools (in comparison to native linux options, or OS X's Instruments, etc.).

Having worked in telecom engineering for the past several years, I do think
the network constraints are real. There are already several comments on this
thread regarding limited resources, though more around the mobile device
capabilities compared to desktops.

From a network perspective, for the mobile carriers, though, high-bandwidth
streaming content and chatty apps are a big deal. The 'data explosion' (that
we're just approaching the initial inflection point now) is essentially why
most carriers are metered plans. Users want lots of content and the options
for high-def streaming are only going to grow. Chatty, social, location-based
services (aka SoLoMo) cause a lot of connections (since cellular radios kill
battery, connections are torn down quickly).

The resource constraints now aren't the same as they were in the days of
campus mainframes, or even the now waning days of fat-client PC desktops and
laptops. But low-powered mobiles, running thin client apps over mobile
networks, clearly have several constrained dimensions. Some of those won't
change quickly. And there's some data to show that the slice of users whose
_only_ internet access is over their mobile device is growing.

------
beefman
Can anyone explain why their mobile site works so much better than their HTML5
app did?

~~~
joahua
In part this is probably due to discrepancies in the performance of Safari vs.
UIWebView browsers. Apple require a different JS engine due to sandboxing
concerns in native app contexts - apparently it benchmarks to around 1/3 the
performance.

------
rodh257
Lots of people are quick to jump on Facebook and claim that their well paid
developers are just poor at their job. What I'd like to see is a list of html5
mobile apps that are as interactive as Facebook is, so that we can see the
best practices in action. I'm struggling to come up with many that aren't
simple blog/news sites. Is anyone able to point me towards some good ones?

------
erichocean
_### What's missing? ###_

 _Mainly, dev tools on the device and/or easily accessible remotely._

 _Things we'd want to know more about as we develop:_

 _#### Down memory lane ####_

 _\- Heap size,_ _\- Object count,_ _\- GC cycles,_ _\- GPU buffer size,_ _\-
resource limits._

Arene't people just loading their mobile site in Chrome desktop, and profiling
there? I guess I don't understand this one (although WebKit does have a remote
debugging protocol now). If the site has bad numbers on the desktop, they're
going to _still_ be bad in other browsers (it's the same page/code after all).

Anyway, although I'm in hearty agreement that I'd like all of the things
mentioned to improve, I'm not in agreement that it would have prevented me
from making Facebook's HTML5 mobile site nice and zippy. :)

~~~
abraham
Every browser has it's own strengths and weaknesses. Optimizing code for one
browser could very well make the code run worse in a different browser.
Chrome/WebKit having good profiling and debug tools doesn't really help when
developing for other browsers.

------
dfox
I somehow fail to understand what does device-UI specific concerns like "pull
to refresh" and "momentum scrolling" (both of which are meaningful only for
touch-centric UI) have to do with mobile Web as a platform (and specifically
standardized HTML5/JS/whatever APIs).

~~~
gojomo
What mobile devices do you think major websites like Facebook should be
targeting that _don't_ have a touch-centric UI?

The standards would be irrelevant if they ignored the major means of
interaction.

~~~
dfox
I think the standards will become irrelevant when they start to dictate what
means of interaction should implementation use.

~~~
VMG
They'll also be irrelevant if they don't support the modes of interactions
that are currently employed.

------
mrwilliamchang
Given this list of concerns, I believe that Facebook made the right decision
in switching from HTML5 to native. The downside for them is now they have to
write native code to support both Android and iOS.

~~~
groue
Hum. UI code has to be different, anyway, in order to respect the hosting
platform conventions and avoid behavioral oddities. The non-UI code can, to
some extent, be shared. At least its design. Isn't it?

------
photon137
It's not as if the hardware isn't capable of doing awesome stuff (case in
point: the idTech 5 demo from John Carmack [1]) - the software using it also
has to be well engineered.

Good engineering for managing hardware resources at the browser level is still
lacking (at this moment, Chrome's various processes are eating up ~700MB of
memory on my system - disgraceful!) - and that's what bites Facebook the most.

[1]: <http://www.youtube.com/watch?v=uofg7m2rtQ4>

------
vital_sol
Infinite scrolling is what I hate most about Facebook UI.

~~~
viseztrance
I don't think it's all that bad, but if the application lags perhaps they
should rethink the interface to suit their environment. Still waiting for a
startup to complain on how they've rewritten in C their laggy html5 mmorpg.

------
devs1010
They just need to stop trying to push the limits of mobile devices and aim for
a middle ground, not everyone has a top of the line smart phone and these
sorts of issues are to be expected. I see plenty of opportunity in creating
lightweight browser based web apps using an all javascript solution (node js
backend, backbone or something front-end) and keeping things lighweight

------
stagas
It isn't a matter of how much JavaScript or how many LOC you have. It's a
matter of design. If they were designing something with a focus on excellent
performance (which is what they really needed) instead of feature XYZ (which
they thought they needed) then it would be an app with excellent performance.
Don't blame the tools for bad design choices.

------
lttlrck
The admission that they couldn't figure out why their app was crashing is a
pretty big indictment for a company in this space.... if they lacks tools, why
didn't they write them and give them back to the community?

Or is it the case that they didn't even know what tools they lacked? The post
certainly smells that way.

~~~
kyrra
On iOS can they even do this? Without jailbreaking an iPhone, getting access
to that type of control is not possible. I would say this falls more on Apple
to provide better tooling for doing development on their browser.

------
majani
I believe the main reason Facebook has been negligent on mobile is because of
Opera Mini. It has handed Facebook a huge lifeline in mobile. Its been the
only bearable way to use the mobile site since Facebook's inception, and
chances are its the most common way of access.

------
lopatin
HN question: Why is post on the front page for days now?

------
obilgic
here is the html version

<https://gist.github.com/bfc267db98eb98b46e3e>

------
nohorse
Native apps allow for localizing of resources and using the full screen.
Alternatives like PhoneGap allow for native HTML5/JS development. Titanium re-
compiles HTML/JS to native, but you still need all the proper SDKs. Until the
mobile vendors embrace web-as-native we'll never get native response out of
web tools. WebOS did, but died, MS supports native HTML/JS for Windows 8 but
not for phone. FireFox OS is hopeful but fringe for now.

