Slashdot Mirror
Facebook iOS App Ditching HTML5 For ObjectiveC
Wrath0fb0b writes "The New York Times reports that Facebook is overhauling their iOS App to ditch their HTML5 based UI for a native ObjectiveC one. This is an about face from their position a few months ago in which FB said HTML5 would allow them to write once run anywhere. While WORA certainly has a lot of appeal for both programmers (due to desire not to duplicate effort) and management alike (due to desire not to pay programmers to duplicate effort), the large number of negative reviews that FB for iOS has illustrate that this approach is not without drawbacks. No matter how the new app is received, this is more fuel on the native vs. web-app fire."
Well, 'better' is relative. The question is often 'is it better enough to justify the decreased portability and increased cost of supporting multiple platforms?' Sometimes the answer is yes, sometimes the answer is no.. sounds like the answered wrong in this case.
They're having trouble returning a few hundred lines of text and 10 photos. Methinks HTML rendering speed is not even remotely their problem.
Better, in the sense that cost considerations aside, technically, it is superior almost every time.
In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice? ..and even then there's performance tradeoffs.
Write it all in assembly and get off my lawn. :)
..don't panic
If it were purely about performance, then they could just use web services to grab the data they needed, style it on the client side and run it in an HTML control. How would drawing content using a native app help performance if the data requirements are the same -- rendering HTML isn't *THAT* slow on iOS, is it?
And with a web app, they have far more control over QA and the release process, and can potentially turn around minor updates much faster than if they had to jump through the App Store release process.
OTOH, they think they have a problem, then good for them. The current client has been buggy for me for quite a while, with navigation buttons sending me to random parts of the application -- they clearly have QA issues that aren't going to be helped (and likely will be made worse) by an app rewrite.
I think you mean bastards. If you really want to do your part to produce orphans ...
I've been dabbling in Objective C. It's... interesting. I regret nothing... well, unless I have those dreams with the brackets. So many brackets! And the garbage! Piling up everywhere! Was it five references or six? Do I feel lucky? What? Where was I? Oh. Yeah, it's OK.
I think the problem with the Facebook "app" was that it didn't seem to store anything locally -- meaning every UI event involved a request over the internet, which does not make for a responsive UI.
It seems to me that the Facebook app's issues are not so much about HTML5 performance, but rather the way that they handle transactions with their servers. The network performance of the app is atrocious. Look at the traffic of the iOS app and compare it to the Facebook mobile website. How many hundreds of XMLHTTPRequests do you think it should take to render a page?
There's nothing inherently wrong with the HTML5, it's their ludicrous network activity that kills the app.
If 50% of your modules have GUI calls, you're developing your software wrong. MVC isn't just for webpages. If you have UI specific code in your business logic, you fail.
If the GUI code is more than a tiny fraction of your overall code, you're working on absolutely trivial software. I can't say I've ever worked on a GUI app where the GUI itself was more than 5-10% of the code.
Basically, there's two ways of writing cross-platform apps:
1)Write your main business logic as a library. Then for each platform, write code that runs the UI and calls it as appropriate
Pros: Can take advantage of all the features of the OS, and make a customized experience for it. Easy to fit in with design standards for the OS. Minimizes bugs due to differences in APIs and capabilities between platforms.
Cons: May not be possible to write the buisness logic in this way, or may not be easy. May require ugliness in the business logic to do so. May be hard to maintain the line of abstraction between the two halves, depending on how the platform is implemented.
2)Abstract away the UI and OS specific calls into a library, and implement them for each OS.
Pros: Easy to do, with a little bit of discipline. It's always possible to do it this way, and *if* you can implement each API call so they act identically on all platforms then maintenance is a breeze and no ugliness in the business logic.
Cons: Subtle differences between how platforms handle common APIs can cause bugs. Differences between how they handle less common APIs can cause major issues. Cannot take advantage of advanced OS specific features, may not be able to follow UI standards for each platform. You'll end up with features not working on some platforms if they don't provide a needed API.
It's probably about a 50/50 split between the two paths (and I won't suggest a path, it really depends on your code and target platforms). But this is how it's done. And in either case, in fact in ALL well designed software the GUI is far separated from the business code.
I still have more fans than freaks. WTF is wrong with you people?