Facebook explains what's wrong with the mobile web
lists.w3.org
lists.w3.org
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!
I'm also unconvinced they can't scale down images server-side to make them more mobile-palatable.
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.
-- This is exactly the problem. for users, content is king.
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.
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?
_______________
[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.
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.
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.
I'm talking mobile web, not HTML5-written faux-native apps.
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)
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.
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?
Just blame the standard?
If you designed an app with a 700KB JS analytics dependency that's your issue.
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%.
Profilers and other performance tools allow people to make rational decisions about when to cut back, rather than groping around in the dark.
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-...
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.
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 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.
Amen.
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.
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.
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.
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 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.
Kudos Facebook.
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.
Everyone wants rich apps in the browser, but no one wants to pay the price of it.
Do you have an evidence that getting rid of infinite scrolling will have very little impact on user engagement? It might have a lot.
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.
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.
From the post, "[Scrolling performance] is one of [their] most important issues."
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."
Finding rigorous engineers is hard.
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).
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.
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 problems with HTML5 are more real. The necessary tools are just not there.
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
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.
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. :)
The standards would be irrelevant if they ignored the major means of interaction.
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.
Or is it the case that they didn't even know what tools they lacked? The post certainly smells that way.