How Facebook Mobile Was Designed to Write Once, Run Everywhere

http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php

by zalew • 15 years ago

75 29 15 years ago

samps• 15 years ago

This article suggests that the new iteration of the Facebook app for iOS is written mainly with Web technologies and the fronted runs in a WebView, which explains why it sucks so much more than the previous version. Has anyone else noticed lots of really sluggish content loading, occasional hangs, mysteriously empty panes, etc? While the app is polished enough to seem native (kinda), it seems to be an argument that Web technologies are not yet ready to be an alternative to native UIKit development -- on iOS, at least.

baddox• 15 years ago

Yep. I've spent some time investigating the possibility of using web views to replace some native Android/iPhone views (e.g. ListViews), and I assure you it's not easy. We didn't do anywhere near as much stuff as Facebook did (of I read that right, they bundle a version of WebKit with their app, and write client side compilers from JavaScript to native languages for phones with bad or no JavaScript environments). It's getting there, but web still hasn't quite arrived as the write once run everywhere platform. At least it's somewhat reassuring that Facebook still has lots of problems after spending many more hours on the mobile web than I have.

adamjernst• 15 years ago

What really intrigues me is that average users feel the same way; it's not just us. Read the iPhone app reviews (current average: 2.0 stars). Ouch!

Facebook should hire back Joe Hewitt. His native app was fast and powerful, at the very least. Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?

Splines• 15 years ago

Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?

You might as well add the Python SDK to that. The "we don't have the resources" claim rings a little hollow, in that the company probably very likely has the resources, but thinks such things are strategically unimportant.

carbon8• 15 years ago

"Read the iPhone app reviews..."

I went ahead and looked, and none of the complaints appeared obviously due to anything related to the current discussion.

The vast majority of them complain about "crashes" and problems logging in. The few complaints about it being "slow" appeared to be due to network issues, specifically related to getting new content from facebook. A handful report that content was attributed to the wrong user. Most of the remainder were just unsubstantial complaints. In the cases are something is actually mentioned, they are mostly about the lack of random features.

I've gone through many pages of comments on the app store reviews and I see no complaints that can be obviously attributed to the technology decisions discussed in the article.

smackfu• 15 years ago

Ratings reset every release, and this new release is only 10 days old, so I wouldn't read too much into that.

Also, I read the first few pages of reviews, and if those are your users, good luck to you app developer!

daveambrose2• 15 years ago

Yes. And I think the cause of the problem is that the environment is running in a WebView + lots of JS floating inside the view.

cageface• 15 years ago

Not only that but it doesn't really sound that much easier. By the time you've pasted all this stuff together, custom JS scrolling lib etc and all, how much work are you really saving yourself?

hboon• 15 years ago

But once they have set that up (which they have), they can build a feature once and deploy it on every mobile platform supported, iterate and fix things quickly without distribution delays (like 30-50% is on iOS?). It's not for everyone, and I don't like the Facebook iPhone app and I don't take this approach generally, but it works for Facebook because it works for most end-users.

falling• 15 years ago

Actually, while I'm still the first to say that web technologies are not ideal for apps UIs, the latest iteration (the one with the timeline) is working better than previous ones for me. Images or comments not loading or loading the wrong content are gone now.

dilap2• 15 years ago

Sure, it minimizes developer effort, but the end result of e.g. the iPhone app is very uninspiring and clunky. Compare it to a true native app like Path if this isn't immediately apparent to you.

(The use of the phrase "native goop" to describe the non-web parts seems telling. They don't seem focused on the end-user experience, but rather developer ease and (that old chimerical developer holy-grail) code reuse.)

flyosity• 15 years ago

That's the exact phrase that stuck out to me too. Reminds me of Java developers who exclusively use GWT to build web apps because they want to "abstract away" the browser component of the web app and write it like an applet or desktop app. It's no wonder that Facebook's native app is going downhill, because their developers think the web is king and native code is just clunky junk they're forced to deal with.

hello_moto• 15 years ago

Somehow your point got lost when you use GWT as an example.

Alright, it's time to explain the whole situation one more time (sigh).

GWT is a platform people. It has tons of goodies from doing the CSS sprites without having to write a home-grown CSS sprites merge scripts up until optimizing JS code.

Any developers that don't know their stack is limited to write high quality code, regardless you use GWT or pure JS (don't give me crap that front-end developers worth their salt without pulling the "yeah, only the best ones").

I used to code in GWT and we all need to know DOM API, we all need to know CSS. But we don't need to know the various "Object Pattern" in JS. We don't need to re-invent the module system in JS (we use Java package).

The difference is that we can write testable code via unit-tests that we can run automatically using JUnit, integrated to our build systems, without having to jump through hoops and prepare a full-blown infrastructure like those that required by Selenium or WebDriver.

funkah• 15 years ago

I feel like this is bound to happen anytime you're optimizing for ease of development rather than user experience. Same reason to beware of cross-platform UI frameworks.

But for Facebook, at this point perhaps their users are so entrenched that the app just has to work, however lackluster it may be. On the other hand, between this and the Python thing, I just can't understand why FB seems so stingy with its dev resources. I realize there is a lot of ground to cover but this is one of the biggest companies in tech we're talking about.

gsmaverick• 15 years ago

They aren't one of the biggest companies in tech. I believe they just barely passed 3,000 total employees recently. Compare that to Google, Microsoft and Yahoo who all have more than 10,000.

statictype2• 15 years ago

(that old chimerical developer holy-grail)

There's a reason why this is important - it allows the 'native' app to stay up to date with the desktop web app. Yes, the Facebook native app is less usable and more clunky than it was before - on the other hand, it's feature-by-feature more up to date with the main site.

Is that a trade-off worth making? Perhaps, perhaps not - but in the very least, there's an argument to be made, right?

dilap2• 15 years ago

There's an argument to be made, but I'd still argue against it :) As a user, I'd much rather have a polished, pleasant to use native app that lagged behind a feature or two occasionally than unified junk. As others have pointed out on this thread, FB's gotta have the dev resources to do separate versions (though maybe not the kind of developers happy to be working on such a "boring" problem).

I think code reuse is often a chimerical holy-grail because in and of itself it is not a good thing; what matters is user experience, the amount of development work, how easy it is to fix bugs, &c. But developers still often obsess over code reuse, even at the expense of things that matter.

rvenugopal• 15 years ago

How is this "Faceweb" approach different from Phonegap? I believe Phonegap too does progressive enhancement as described in this article

daveambrose2• 15 years ago

To me, there's pros/cons to this approach with the perspective of making it as EASY as possible for developers to ship across all types of hardware (which is great). But the con seems so big to me: the end-user experience is so slow (iPhone and Android) that when you think of "Facebook for Mobile", you think "Maybe I can wait to access FB on my iPad or back on my laptop when I'm home?"

All of the native apps that I've seen, played with and analyzed, speed = to some the best experiences for a user. I mean, doesn't a FB user want exactly that when they check the Newsfeed? For instance, today, I turned off 4G and moved to 3G on my Android, checked the FB app and it crawled. It junked new screen loads, comments, liking, etc. Switching over to 4G made (some of) the pain go away.

tomatohs• 15 years ago

Facebook's goal is to penetrate as many markets as possible with the fewest lines of code.

Does this mean they don't give a shit about experience? No. It means they want to have a large reach without much maintenance. After that is accomplished, then they can worry about experience on a per device basis.

I don't believe it's correct to just dismiss this as garbage because the application is currently buggy. The entire idea of this approach is to improve the experience across all devices, but for now they are limited because they are still on the first step, implementation. Also note the slide that says "betting on the browser," meaning that Facebook is betting that issues between platforms will eventually fade away.

protomyth• 15 years ago

> Does this mean they don't give a shit about experience? No. It means they want to have a large reach without much maintenance. After that is accomplished, then they can worry about experience on a per device basis.

Facebook maybe able to get away with this, but almost every other developer and plenty of device makers will not get that second chance and will be dismissed by customers.

This is the same thing that happened to cross platform Smalltalk programmers (e.g. VW, VisualAge). They sure could target a lot of machines, but their programs always acted crappy and slow with poor UIs. This is ok when your "customers" are forced to use your program like a custom app for a business, but it sure doesn't work for others. Even Adobe runs into user hate for their non-native widgets and ignoring platform conventions.

Most non-technical consumers are good about getting a feel for how things work on a platform (e.g. ctrl-c for copy on windows, smooth scrolling, metro on WP7). This leads to a disconnect when an app behaves differently. They may not be able to express the problem, but they will certainly notice it.

drivebyacct2• 15 years ago

The new Facebook mobile site is gorgeous and is faster than the native app on my Galaxy Nexus (for whatever reason the FB app takes ages to load, and ages longer to load data after it gets off a white screen). It's so nice in the browser and it's every bit as functional as the proper "app".

Sadly, they're doing some weird user agent sniffing and are giving me the WAP site currently and are also telling me I have a Droid Bionic, so I'm not 100% sure what's up with that.

After reading the comments here, maybe my experience is so pleasant due to the power of the Nexus and the tuning in the 4.0 browser.

pinaceae• 15 years ago

developer-centric vs. user centric approach in effect.

if you don't care about utilizing every inch of platform functionalities and performance to achieve a great user experience - why bother with such meta-apps at all? just let your user place a bookmark on the home screen and be done with it. save even more developer effort.

from a pure user perspective, this approach can be summed up pretty simply: "half-assed".

How Facebook Mobile Was Designed to Write Once, Run Everywhere

Related Stories