10 ms·

Facebook explains what's wrong with the mobile web

243 points by patrickaljord 14y ago

sabret00the 14y ago
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 14y ago
  By what criteria has Chrome OS failed?
  - sabret00the 14y ago
    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 14y ago
      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.
      - sabret00the 14y ago
        Maybe, but the question remains, is it viable now? Is Firefox OS viable now? The answer to both is an emphatic no. However it's felt more in regards to Mozilla as they don't have the resources to build Firefox OS and maintain Firefox along with other projects like Thunderbird. Android still doesn't have a good open source mail program and the port of Thunderbird was a hope.
      - fierarul 14y ago
        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.
  - alpeb 14y ago
    I'm also a big fan of ChromeOS' model. Chrome is advancing very very quickly and so is ChromeOS as a consequence. There have been big deployments at schools, for which it is a great fit. Maybe they just need to price it more aggressively.
    - TazeTSchnitzel 14y ago
      I think its big issue might be that people don't realise that a "Chromebox" or "Chromebook" is still a real computer. Their ads are helping somewhat, but I think people still don't know that web apps work offline, for example.
- clintjhill 14y ago
  It's a setback - but I find it less dramatic than what you make it to be. Mobile web still has tremendous value over native (specifically in deployment options). If some of these things get addressed by device builders we could see a real explosion of "apps" not unlike the explosion that has already occurred. I'm a fan of native implementations for the exact reasons Tobie laid out, but I'm a bigger fan of Mobile web for distribution reasons.
TazeTSchnitzel 14y ago
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!
- 54mf 14y ago
  Yes, I'm sure Facebook and their stable of developers just never thought of that. How silly.
  - TazeTSchnitzel 14y ago
    I think Facebook do know what they're doing, but are perhaps putting energy into the wrong things. Using a ton of JavaScript to avoid ever having to load another page is a nice idea, but it ends up bogging down the client. Using a lot of abstractions away from the DOM makes things slow. An occasional page load is probably beneficial. I'm also unconvinced they can't scale down images server-side to make them more mobile-palatable.
    - timpeterson 14y ago
      @TazeTschnitzel agreed, but then what would fb engineers do all day? they gotta "keep shipping"
  - notatoad 14y ago
    because they're a big company with a lot of staff, everything they do must therefore be "the right way"? That's a fallacy if i've ever heard one.
    - 14y ago
weej 14y ago
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 14y ago
  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.
k2xl 14y ago
"- 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 14y ago
  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 14y ago
    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 14y ago
      Yeah, achieving many of the scrolling effects they want often requires sites to do scrolling entirely "by hand", which degrades the quality of scrolling.
mrwilliamchang 14y ago
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 14y ago
  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?
realrocker 14y ago
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 http://kivy.org/#home. I would love to see Facebook put their resources into something similar to this.
- randomdata 14y ago
  > 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 14y ago
    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 14y ago
vital_sol 14y ago
Infinite scrolling is what I hate most about Facebook UI.
- viseztrance 14y ago
  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.
nohorse 14y ago
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.
devs1010 14y ago
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
photon137 14y ago
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 http://www.youtube.com/watch?v=uofg7m2rtQ4
Zenst 14y ago
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.
dfox 14y ago
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 14y ago
  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 14y ago
    I think the standards will become irrelevant when they start to dictate what means of interaction should implementation use.
    - VMG 14y ago
      They'll also be irrelevant if they don't support the modes of interactions that are currently employed.
majani 14y ago
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.
tmanderson 14y ago
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 14y ago
  This. Finding rigorous engineers is hard.
obilgic 14y ago
here is the html version https://gist.github.com/bfc267db98eb98b46e3e https://gist.github.com/bfc267db98eb98b46e3e
robomartin 14y ago
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 14y ago
  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.
coliveira 14y ago
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 14y ago
  Maybe they didn't get it before, but they're following your advice now by building for their users, not their convenience.
clebio 14y ago
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.
jlarocco 14y ago
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.
- st3fan 14y ago
  It works well for the native app. So it is not a "mobile phone" problem?
  - quest88 14y ago
    Good point. However, it's pretty crappy on my 3GS.
- javajosh 14y ago
  >"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.
beefman 14y ago
Can anyone explain why their mobile site works so much better than their HTML5 app did?
- joahua 14y ago
  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.
erichocean 14y ago
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 https://github.com/erichocean/blossom
- je42 14y ago
  on how many android devices have you tested it ?
- deleted 14y ago
  [deleted]
augustl 14y ago
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.
- erichocean 14y ago
  +1, and this would also be very useful on the desktop too!
- javajosh 14y ago
  Yeah, that's fucking hot. Imagine an onmemory event in the DOM. Juicy.
erichocean 14y ago
### 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 14y ago
  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.
- mquander 14y ago
  Yes, but unfortunately, if the site has good numbers on the desktop, they aren't always good in other browsers.
rodh257 14y ago
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?
lopatin 14y ago
HN question: Why is post on the front page for days now?
lttlrck 14y ago
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 14y ago
  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.
stagas 14y ago
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.

243 points by patrickaljord 14y ago

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 14y ago
By what criteria has Chrome OS failed?
- sabret00the 14y ago
  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 14y ago
    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.
    - sabret00the 14y ago
      Maybe, but the question remains, is it viable now? Is Firefox OS viable now? The answer to both is an emphatic no. However it's felt more in regards to Mozilla as they don't have the resources to build Firefox OS and maintain Firefox along with other projects like Thunderbird. Android still doesn't have a good open source mail program and the port of Thunderbird was a hope.
    - fierarul 14y ago
      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.
- alpeb 14y ago
  I'm also a big fan of ChromeOS' model. Chrome is advancing very very quickly and so is ChromeOS as a consequence. There have been big deployments at schools, for which it is a great fit. Maybe they just need to price it more aggressively.
  - TazeTSchnitzel 14y ago
    I think its big issue might be that people don't realise that a "Chromebox" or "Chromebook" is still a real computer. Their ads are helping somewhat, but I think people still don't know that web apps work offline, for example.
clintjhill 14y ago
It's a setback - but I find it less dramatic than what you make it to be. Mobile web still has tremendous value over native (specifically in deployment options). If some of these things get addressed by device builders we could see a real explosion of "apps" not unlike the explosion that has already occurred. I'm a fan of native implementations for the exact reasons Tobie laid out, but I'm a bigger fan of Mobile web for distribution reasons.

TazeTSchnitzel 14y ago

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!

54mf 14y ago
Yes, I'm sure Facebook and their stable of developers just never thought of that. How silly.
- TazeTSchnitzel 14y ago
  I think Facebook do know what they're doing, but are perhaps putting energy into the wrong things. Using a ton of JavaScript to avoid ever having to load another page is a nice idea, but it ends up bogging down the client. Using a lot of abstractions away from the DOM makes things slow. An occasional page load is probably beneficial. I'm also unconvinced they can't scale down images server-side to make them more mobile-palatable.
  - timpeterson 14y ago
    @TazeTschnitzel agreed, but then what would fb engineers do all day? they gotta "keep shipping"
- notatoad 14y ago
  because they're a big company with a lot of staff, everything they do must therefore be "the right way"? That's a fallacy if i've ever heard one.
  - 14y ago

weej 14y ago

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 14y ago
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.

k2xl 14y ago

"- 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 14y ago
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 14y ago
  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 14y ago
    Yeah, achieving many of the scrolling effects they want often requires sites to do scrolling entirely "by hand", which degrades the quality of scrolling.

mrwilliamchang 14y ago

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 14y ago
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?

realrocker 14y ago

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 http://kivy.org/#home. I would love to see Facebook put their resources into something similar to this.

randomdata 14y ago
> 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 14y ago
  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 14y ago

vital_sol 14y ago

Infinite scrolling is what I hate most about Facebook UI.

viseztrance 14y ago
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.

nohorse 14y ago

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.

devs1010 14y ago

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

photon137 14y ago

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 http://www.youtube.com/watch?v=uofg7m2rtQ4

Zenst 14y ago

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.

dfox 14y ago

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 14y ago
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 14y ago
  I think the standards will become irrelevant when they start to dictate what means of interaction should implementation use.
  - VMG 14y ago
    They'll also be irrelevant if they don't support the modes of interactions that are currently employed.

majani 14y ago

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.

tmanderson 14y ago

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 14y ago
This. Finding rigorous engineers is hard.

obilgic 14y ago

here is the html version https://gist.github.com/bfc267db98eb98b46e3e https://gist.github.com/bfc267db98eb98b46e3e

robomartin 14y ago

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 14y ago
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.

coliveira 14y ago

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 14y ago
Maybe they didn't get it before, but they're following your advice now by building for their users, not their convenience.

clebio 14y ago

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.

jlarocco 14y ago

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.

st3fan 14y ago
It works well for the native app. So it is not a "mobile phone" problem?
- quest88 14y ago
  Good point. However, it's pretty crappy on my 3GS.
javajosh 14y ago
>"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.

beefman 14y ago

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

joahua 14y ago
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.

erichocean 14y ago

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 https://github.com/erichocean/blossom

je42 14y ago
on how many android devices have you tested it ?
deleted 14y ago
[deleted]

augustl 14y ago

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.

erichocean 14y ago
+1, and this would also be very useful on the desktop too!
javajosh 14y ago
Yeah, that's fucking hot. Imagine an onmemory event in the DOM. Juicy.

erichocean 14y ago

### 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 14y ago
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.
mquander 14y ago
Yes, but unfortunately, if the site has good numbers on the desktop, they aren't always good in other browsers.

rodh257 14y ago

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?

lopatin 14y ago

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

lttlrck 14y ago

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 14y ago
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.

stagas 14y ago

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.