How Facebook Mobile Was Designed to Write Once, Run Everywhere
readwriteweb.com
readwriteweb.com
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?
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.
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.
> 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.
Besides that still leaves you with Android and/or iOS plus web -- two to three times the development costs. This becomes very hard to justify for such a small percentage of total product users.
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.
Also, I read the first few pages of reviews, and if those are your users, good luck to you app developer!
(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.)
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.
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.
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?
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.
Except that, I don't disagree with anything else you said.
Fogbugz has their own custom compiler that generates code for the platform of their choice. Facebook has already written their own PHP->C++ compiler. I wouldn't be surprised if they have some team there working on some high-level infrastructure that lets them write UIs and code that gets compiled down to custom Objective-C/html+javascript/AndroidJava/etc...
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.
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.
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.
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".
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.