6 ms·

How Facebook Mobile Was Designed to Write Once, Run Everywhere

75 points by zalew 15y ago

sebbi 15y ago
Link is dead ...
samps 15y 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 15y 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 15y 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 15y 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.
    - tsunamifury 15y ago
      You may not have the experience of supporting a large web service, but I do. Believe me, supporting native apps for multiple platforms is not only a multimillion dollar money pit, but an integration nightmare. You end up building a web interface anyways then hacking together a ui in native code for every platform. The long term support structure can very quickly (exponentially) get out of hand.
      - jasonlotito 15y ago
        I don't personally, but the people I work beside do, and it doesn't seem from talking and working with them that it's as bad as you suggest, no where close. Having launched successful apps on multiple platforms for a website, I've seen it done successfully.
        tsunamifury 15y ago
        Website =/= web service Large saas, social media, and rich media delivery services have many times more complex factors than a simple content site. Why do you think Netflix, Facebook, many major banks and loan servicing institutions and most financial portals have chosen the web app strategy. It's not just because they are idiots and don't get it, it's that theyve recognized the unsupportable nature of multiple mobile platforms with such limited penetration.
        jasonlotito 15y ago
        Was referring to a "web site" akin to Facebook. A social network. Not merely a "content site." So, that point is moot. > It's not just because they are idiots and don't get it Didn't suggest otherwise. But your reasoning is flawed, I'd imagine. Your suggesting that they don't go native because smaller platforms have limited penetration? If so, that seems silly. Why not support the platforms with large penetration natively, and support the platforms with smaller penetration with a web app? I'm not suggesting going native for every platform, but going native for none because you can't do them all is even more silly.
- daveambrose 15y 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 15y 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 15y 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.
  - deleted 15y ago
    [deleted]
- falling 15y 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.
dilap 15y 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 15y 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 15y 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 15y 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.
rvenugopal 15y ago
How is this "Faceweb" approach different from Phonegap? I believe Phonegap too does progressive enhancement as described in this article
daveambrose 15y 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 15y 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 15y 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 15y 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 15y 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".
deleted 15y ago
[deleted]

75 points by zalew 15y ago

sebbi 15y ago

Link is dead ...

samps 15y 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 15y 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 15y 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 15y 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.
  - tsunamifury 15y ago
    You may not have the experience of supporting a large web service, but I do. Believe me, supporting native apps for multiple platforms is not only a multimillion dollar money pit, but an integration nightmare. You end up building a web interface anyways then hacking together a ui in native code for every platform. The long term support structure can very quickly (exponentially) get out of hand.
    - jasonlotito 15y ago
      I don't personally, but the people I work beside do, and it doesn't seem from talking and working with them that it's as bad as you suggest, no where close. Having launched successful apps on multiple platforms for a website, I've seen it done successfully.
      - tsunamifury 15y ago
        Website =/= web service Large saas, social media, and rich media delivery services have many times more complex factors than a simple content site. Why do you think Netflix, Facebook, many major banks and loan servicing institutions and most financial portals have chosen the web app strategy. It's not just because they are idiots and don't get it, it's that theyve recognized the unsupportable nature of multiple mobile platforms with such limited penetration.
        jasonlotito 15y ago
        Was referring to a "web site" akin to Facebook. A social network. Not merely a "content site." So, that point is moot. > It's not just because they are idiots and don't get it Didn't suggest otherwise. But your reasoning is flawed, I'd imagine. Your suggesting that they don't go native because smaller platforms have limited penetration? If so, that seems silly. Why not support the platforms with large penetration natively, and support the platforms with smaller penetration with a web app? I'm not suggesting going native for every platform, but going native for none because you can't do them all is even more silly.
daveambrose 15y 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 15y 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 15y 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.
- deleted 15y ago
  [deleted]
falling 15y 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.

dilap 15y 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 15y 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 15y 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 15y 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.

rvenugopal 15y ago

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

daveambrose 15y 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 15y 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 15y 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 15y 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 15y 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".

deleted 15y ago

[deleted]