Facebook explains what's wrong with the mobile web

http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

by patrickaljord • 14 years ago

243 109 14 years ago

lists.w3.org

sabret00the3• 14 years 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...

TazeTSchnitzel8• 14 years ago

By what criteria has Chrome OS failed?

sabret00the3• 14 years 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.

alpeb• 14 years 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.

clintjhill• 14 years 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.

TazeTSchnitzel8• 14 years 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!

54mf2• 14 years ago

Yes, I'm sure Facebook and their stable of developers just never thought of that. How silly.

TazeTSchnitzel8• 14 years 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.

notatoad• 14 years 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.

brendanib• 14 years ago

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.

001sky3• 14 years ago

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.

joering2• 14 years ago

can you remove the word "loading" from your comment?

devs10102• 14 years ago

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?

weixiyen3• 14 years ago

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.

TazeTSchnitzel8• 14 years ago

Huh?

I'm talking mobile web, not HTML5-written faux-native apps.

ender7• 14 years ago

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)

TazeTSchnitzel8• 14 years ago

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.

stcredzero2• 14 years ago

> 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.

mikeash• 14 years ago

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?

lttlrck3• 14 years ago

>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.

batista• 14 years ago

>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%.

skybrian• 14 years ago

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.

wamatt• 14 years ago

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-...

prostoalex• 14 years ago

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.

Joeri• 14 years ago

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.

weej2• 14 years 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.

se852• 14 years 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.

weej2• 14 years ago

"Don't blame the technology, blame the implementation!"

Amen.

lttlrck3• 14 years ago

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.

k2xl• 14 years 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.

54mf2• 14 years 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.

mrwilliamchang2• 14 years 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."

mrwilliamchang2• 14 years 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• 14 years 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?

realrocker2• 14 years 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. I would love to see Facebook put their resources into something similar to this.

randomdata2• 14 years 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.).

realrocker2• 14 years 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.

erichocean4• 14 years ago

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

vital_sol• 14 years ago

Infinite scrolling is what I hate most about Facebook UI.

viseztrance• 14 years 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• 14 years 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.

devs10102• 14 years 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• 14 years 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

Zenst• 14 years 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.

dfox2• 14 years 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• 14 years 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.

dfox2• 14 years ago

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

majani• 14 years 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• 14 years 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• 14 years ago

This.

Finding rigorous engineers is hard.

obilgic• 14 years ago

here is the html version

https://gist.github.com/bfc267db98eb98b46e3e

robomartin• 14 years 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.

javajosh4• 14 years 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• 14 years 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• 14 years ago

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

clebio• 14 years 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.

jlarocco2• 14 years 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• 14 years ago

It works well for the native app. So it is not a "mobile phone" problem?

quest88• 14 years ago

Good point. However, it's pretty crappy on my 3GS.

javajosh4• 14 years 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.

joemoon• 14 years ago

> 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.

jlarocco2• 14 years ago

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.

mikebo• 14 years ago

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.

rmc• 14 years ago

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.

beefman• 14 years ago

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

joahua• 14 years 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.

erichocean4• 14 years 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

je42• 14 years ago

on how many android devices have you tested it ?

augustl• 14 years 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.

erichocean4• 14 years ago

+1, and this would also be very useful on the desktop too!

javajosh4• 14 years ago

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

erichocean4• 14 years 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• 14 years 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• 14 years ago

Yes, but unfortunately, if the site has good numbers on the desktop, they aren't always good in other browsers.

rodh257• 14 years 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• 14 years ago

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

lttlrck3• 14 years 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• 14 years 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• 14 years 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.

Facebook explains what's wrong with the mobile web

Related Stories