Facebook explains what's wrong with the mobile web(lists.w3.org)
lists.w3.org
Facebook explains what's wrong with the mobile web
http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html
27 comments
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.
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.
Or is it the case that they didn't even know what tools they lacked? The post certainly smells that way.
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.
HN question: Why is post on the front page for days now?
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...
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.
By what criteria has Chrome OS failed?
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.
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.
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.
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.
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.
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.
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.
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!
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!
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)
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)
> 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.
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.
Eh, I just find it hard to believe FB honestly needs that much just to load the homepage. Now, the whole mobile site? Sure, that seems reasonable, considering how much you can do. But if that's the case, I wonder why Facebook aren't modularising it.
>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.
Just blame the standard?
If you designed an app with a 700KB JS analytics dependency that's your issue.
Just blame the standard?
If you designed an app with a 700KB JS analytics dependency that's your issue.
It seems like a matter of inadequate tools more than anything.
When I write native code, I write apps that are broken up into relatively small chunks, which are then demand-paged off the disk when needed. A freshly launched copy of my app that hasn't touched most of its code takes up very little memory.
And of course, all apps work that way, because that's how the system is built. It's actually substantially harder to avoid that lazy loading functionality than it is to take advantage of it.
Obviously, the systems used to lazily load machine code stored locally are different from what would be needed to modularize and lazily load source code being loaded over the network, but surely there's some way to improve this without making programmers do a ton of grunt work. If pages are loading huge amounts of JavaScript code that goes unused simply because it's easier to code that way, doesn't that mean the tools are deficient?
When I write native code, I write apps that are broken up into relatively small chunks, which are then demand-paged off the disk when needed. A freshly launched copy of my app that hasn't touched most of its code takes up very little memory.
And of course, all apps work that way, because that's how the system is built. It's actually substantially harder to avoid that lazy loading functionality than it is to take advantage of it.
Obviously, the systems used to lazily load machine code stored locally are different from what would be needed to modularize and lazily load source code being loaded over the network, but surely there's some way to improve this without making programmers do a ton of grunt work. If pages are loading huge amounts of JavaScript code that goes unused simply because it's easier to code that way, doesn't that mean the tools are deficient?
>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. Let's.
As of NOW they are inadequate for mobile devices, provide a sub-par experience to native apps, and move too much redundant BS over the network (even thin client-side-rendering style ones).
Heck, some Canvas/SVG demos even bring a Desktop browser to it's knees and the CPU to 100%.
Sure. Let's.
As of NOW they are inadequate for mobile devices, provide a sub-par experience to native apps, and move too much redundant BS over the network (even thin client-side-rendering style ones).
Heck, some Canvas/SVG demos even bring a Desktop browser to it's knees and the CPU to 100%.
My experience of Facebook code is that it's bloated and convoluted, having been an evolution of hacks built on top of each other. In fact it feels similar to Microsoft and legacy code that where carried into Windows and beyond. Granted certain FB teams have developed some really cool stuff internally, and I'm just looking at their client side stack. But can't help get the feeling, they are just not thinking creatively about HTML 5 and mobile.
Intuitively to me, 700kb seems excessive and could very probably be reduced. But even so, they could possibly break it up and cache 90% of that [1]. Or on demand loading (as others have suggested). Granted it needs to work across all platforms, but there are companies far smaller with fewer resources producing fast HTML5 apps for mobile.
And if they doing that already, then I just can't understand how something relatively simple, (posting and browsing content), can perform so poorly. One doesn't need 700kb of analytics to know the experience sucks. ;)
[1] http://stackoverflow.com/questions/5108376/how-do-you-cache-...
Intuitively to me, 700kb seems excessive and could very probably be reduced. But even so, they could possibly break it up and cache 90% of that [1]. Or on demand loading (as others have suggested). Granted it needs to work across all platforms, but there are companies far smaller with fewer resources producing fast HTML5 apps for mobile.
And if they doing that already, then I just can't understand how something relatively simple, (posting and browsing content), can perform so poorly. One doesn't need 700kb of analytics to know the experience sucks. ;)
[1] http://stackoverflow.com/questions/5108376/how-do-you-cache-...
A large portion of that 700kb of js is for user-level analytics to track everything, which is fed back into everything from Ads to Page Insights to News Feed algorithms. There's a lot going on that has nothing to do with loading and displaying content.
There's a lot going on that has nothing to do with loading and displaying content.
-- This is exactly the problem. for users, content is king.
-- This is exactly the problem. for users, content is king.
Just because it doesn't deal with directly showing content doesn't mean it has nothing to do with content.
Let's say Google used predictive algorithms based on what you've clicked/hovered on/looked at on the search page to generate your next query. That doesn't deal with loading and displaying content, but it is directly related to DECIDING which content is going to be shown. And if content is king, that's the most important thing of all.
Let's say Google used predictive algorithms based on what you've clicked/hovered on/looked at on the search page to generate your next query. That doesn't deal with loading and displaying content, but it is directly related to DECIDING which content is going to be shown. And if content is king, that's the most important thing of all.
Exception that proves the rule is google search. nobody wants to trade performance so they can be analyzed and ad-tracked "more better" for basic info...Example: 9x [!] do not track blocks @ http://www.independent.co.uk/
I know it's in vogue to rail on Facebook at every opportunity, but you're making an assumption that all this tracking and analyzation is ultimately only to serve you more targeted advertising or sell your info. While that might be part of the reason, Facebook also does a lot of work behind the scenes to determine what content to show you, just like Google does.
And while we're comparing Google and Facebook, why would it be ok for Google to analyze the heck out of your behavior but not for Facebook to do the same thing? Google and Facebook both make approximately the same percentage of their revenue (basically 100%) off of advertising, right?
And while we're comparing Google and Facebook, why would it be ok for Google to analyze the heck out of your behavior but not for Facebook to do the same thing? Google and Facebook both make approximately the same percentage of their revenue (basically 100%) off of advertising, right?
To be fair, I think you mis-understood me. There's no mention of FB. My example was a news site with 9 trackers. Plain vanilla newspaper - Independent is in London UK. The odd-couter-example might be x, y, or z. It might be google or it might be facebook. but why not just have opt in? The default inference is that [insert number here] would not find it worthwhile enough to bother. [1]
_______________
[1] Also, I did not mention, but on that topic you asked: FB data can be considered more sensitive. They start broadcasting and sharing stuff. Taking it "out of context", and sent to your network. Kind of ironic, but true. It begs the question: Why do you like this? or Why do your read that? Do I want to put footnotes on everything I do? To explain the "context" and the logic of my thoughts? Not really... =D.
_______________
[1] Also, I did not mention, but on that topic you asked: FB data can be considered more sensitive. They start broadcasting and sharing stuff. Taking it "out of context", and sent to your network. Kind of ironic, but true. It begs the question: Why do you like this? or Why do your read that? Do I want to put footnotes on everything I do? To explain the "context" and the logic of my thoughts? Not really... =D.
> This is exactly the problem. for users, content is king.
If I were someone significant at Apple or Google(+), I would pay attention here and formulate my attack plan based on this factor. Part of that would involve a browser add-on that syncs to multiple social networks, with the express purpose of taking power away from Facebook.
If I were someone significant at Apple or Google(+), I would pay attention here and formulate my attack plan based on this factor. Part of that would involve a browser add-on that syncs to multiple social networks, with the express purpose of taking power away from Facebook.
This would probably violate ToS for facebook.
they should abandon this concept altogether of pushing this burden onto the client-side (smartphone), they should be able to move any tracking logic server-side to get what they need from a mobile device, really I don't think companies should ever offload this burden onto a client-device, what are they tracking client-side (mousovers? keystrokes?) isn't this a bit invasive to the user?
They're tracking things like bounce rates and time on pages to find out who you interact with the most. Also, I'm sure they're analyzing how far you scroll the page, where you click away, and a variety of other things.
[deleted]
can you remove the word "loading" from your comment?
Yes, I'm sure Facebook and their stable of developers just never thought of that. How silly.
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.
I'm also unconvinced they can't scale down images server-side to make them more mobile-palatable.
@TazeTschnitzel agreed, but then what would fb engineers do all day? they gotta "keep shipping"
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.
True, but it's incredibly easy to play "armchair project architect," when you don't actually know anything about how a project works or its requirements or constraints.
Maybe this is a personal flaw, but I can't count the number of times I've looked at a project and thought "that's a stupid way to do it" only to later realize the problem is far more nuanced than I thought.
Maybe this is a personal flaw, but I can't count the number of times I've looked at a project and thought "that's a stupid way to do it" only to later realize the problem is far more nuanced than I thought.
While that is a problem, it wouldn't solve the uncanny valley problem with scrolling either way.
Standards for correct UI feel on iOS are extremely high, and you are looking at spending more development hours trying to create a write once run everywhere platform than just writing native code.
Standards for correct UI feel on iOS are extremely high, and you are looking at spending more development hours trying to create a write once run everywhere platform than just writing native code.
Huh?
I'm talking mobile web, not HTML5-written faux-native apps.
I'm talking mobile web, not HTML5-written faux-native apps.
I see. Point still stands. Their timeline and newsfeed scrolling are still going to be problems regardless.
I'm unconvinced. Web pages scroll fine for me, why can't the timeline and newsfeed?
Scrolling and js performance differ radically between web pages in mobile safari and uiwebviews on iOS.
Because it's infinite scrolling. They add stuff while you scroll. That's much more difficult to make smooth.
Here's an insightful and rather good approach (at least to me when I tried to implement something along the lines of this):
http://engineering.linkedin.com/linkedin-ipad-5-techniques-s...
Why can't they just load when you reach the end? I've found this tends to be what happens for me, anyway.
They could do that, but they don't want to. Their point is that web technologies can't deliver the experience they want. Telling them they want dumb things is not a legitimate response, especially as they can get the experience they want using other technology.
Seems like an issue they've struggled to solve unsuccessfully, and it's a pretty big problem for a core feature of their product unless they change the UI altogether for how they present the feed. Is there an example of an infinite scroll UI that pre-fetches text / image content on mobile web without the uncanny valley problem?
It's not all low-hanging fruit. The easiest way to pull in lots of code is make a library call. Libraries can depend on other libraries and how much gets optimized away is difficult to predict. Without good dashboards for watching the codebase and its effect on runtimes, it's easy to pull in too much.
Profilers and other performance tools allow people to make rational decisions about when to cut back, rather than groping around in the dark.
Profilers and other performance tools allow people to make rational decisions about when to cut back, rather than groping around in the dark.
You have to make a trade-off between simplicity and user expectations though.
For example, 6 months before the iphone was released we developed a mobile app at my work that was universally compatible. It ran on the lowest WAP2 phone you could imagine, by virtue of not using any javascript, using nothing that wasn't in the XHTML basic standard, and putting few controls on each screen.
And then the iphone happened and our users very vocally told us that the look and feel of this app was not acceptable. So, we built a version that runs only on modern smartphones and a very narrow range of browsers, but users are ecstatic about it, even though it does exactly the same things as before.
For example, 6 months before the iphone was released we developed a mobile app at my work that was universally compatible. It ran on the lowest WAP2 phone you could imagine, by virtue of not using any javascript, using nothing that wasn't in the XHTML basic standard, and putting few controls on each screen.
And then the iphone happened and our users very vocally told us that the look and feel of this app was not acceptable. So, we built a version that runs only on modern smartphones and a very narrow range of browsers, but users are ecstatic about it, even though it does exactly the same things as before.
This does not have to be a theoretical debate. Facebook content is available via their API. Most of the writes (liking, commenting, status updates, check-ins) are also available via API.
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.
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.
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.
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.
"Don't blame the technology, blame the implementation!"
Amen.
Amen.
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.
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.
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.
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.
"- 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.
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.
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.
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."
From the post, "[Scrolling performance] is one of [their] most important issues."
Yeah, achieving many of the scrolling effects they want often requires sites to do scrolling entirely "by hand", which degrades the quality of scrolling.
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.
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?
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.
> 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.).
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.).
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.
The problems with HTML5 are more real. The necessary tools are just not there.
> 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:
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
string = [ 1 ]
string.kind_of?(Array) # Returns true
iOS-style development in the browser is exactly what Blossom[1] provides, and specifically for the reasons you mention.
[1] https://github.com/erichocean/blossom
[1] https://github.com/erichocean/blossom
Infinite scrolling is what I hate most about Facebook UI.
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.
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.
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
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
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
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.
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.
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).
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.
The standards would be irrelevant if they ignored the major means of interaction.
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.
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."
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."
This.
Finding rigorous engineers is hard.
Finding rigorous engineers is hard.
here is the html version
https://gist.github.com/bfc267db98eb98b46e3e
https://gist.github.com/bfc267db98eb98b46e3e
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.
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.
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.
Maybe they didn't get it before, but they're following your advice now by building for their users, not their convenience.
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.
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.
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.
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.
>"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.
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.
> 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.
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.
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.
Kudos Facebook.
Exactly, which is why FB is putting pressure on their dependancies (browser vendors) to give them the tools and features to make mobile web apps that delight people.
What do you mean? IMO, the article is the evidence. Nobody else is complaining about this stuff because everybody else realizes that phones are different than desktops. Apparently only FB didn't get the memo.
The phone manufacturers aren't deliberately making infinite scroll perform poorly just to piss off Facebook. The devices, at this time, are not powerful enough to support infinite scroll when using HTML and Javascript. FB could get over it and use something else, but they've decided to whine about it instead.
Also, "native apps can do it, therefore HTML should be able to do it" is almost hilarious. Native apps are faster than HTML/Javascript. That's not news - that's the way it's always been and probably always will be. Everybody else adjusts their designs to deal with it; Facebook is just whining about it.
The phone manufacturers aren't deliberately making infinite scroll perform poorly just to piss off Facebook. The devices, at this time, are not powerful enough to support infinite scroll when using HTML and Javascript. FB could get over it and use something else, but they've decided to whine about it instead.
Also, "native apps can do it, therefore HTML should be able to do it" is almost hilarious. Native apps are faster than HTML/Javascript. That's not news - that's the way it's always been and probably always will be. Everybody else adjusts their designs to deal with it; Facebook is just whining about it.
After vast amounts of effort spent on fancy JITs and fast layout engines, browsers should be able to do this stuff - or at the very least, it would be cool if they could, and it's probably achievable. Editorialized submission title aside, this post is the starting point for an attempt to improve browsers in the future, and in the meantime Facebook has launched their native app to provide the desired experience a different way. Where exactly is the whining?
Why should the browser be required to deal with this? They used javascript to build up a giant page, why don't they use the same facilities to cull the parts of the page that have already scrolled off the top of the screen?
Everyone wants rich apps in the browser, but no one wants to pay the price of it.
Everyone wants rich apps in the browser, but no one wants to pay the price of it.
Read all the issues listed in the post - it's not just about removing stuff, there are a whole bunch of obstacles to pages trying to take control of scrolling in general or even modifying the DOM without causing stuttering.
I would think it's the caes that a "next page" link reduces engagement (some users will bounce before hitting next page). This implies less ad impressions. Facebook is not optimizing for the same things you are.
It's an easy solution with negligible end user consequences.
Do you have an evidence that getting rid of infinite scrolling will have very little impact on user engagement? It might have a lot.
Do you have an evidence that getting rid of infinite scrolling will have very little impact on user engagement? It might have a lot.
Can anyone explain why their mobile site works so much better than their HTML5 app did?
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.
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
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
on how many android devices have you tested it ?
[deleted]
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.
Yeah, that's fucking hot. Imagine an onmemory event in the DOM. Juicy.
+1, and this would also be very useful on the desktop too!
### 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. :)
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. :)
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.
Yes, but unfortunately, if the site has good numbers on the desktop, they aren't always good in other browsers.
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?