Facebook iOS App Ditching HTML5 For ObjectiveC 240
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."
Re:WORA.... (Score:5, Interesting)
The problem with WORA is that the interpreter has to both be present and consistent across all environments. It worked for Java, because Sun wrote all of the initial JVMs, and every such JVM conforms to the same spec. Even then, Java was for the desktop/server. Sun had to change to a new spec for mobile, which they recognized was a completely different playing field. The scope of WORA that Facebook wanted to apply wouldn't have worked even they were using Java.
Something as massive and as fractured as HTML5 where everybody "supporting" it has actually only implemented a portion of the standard and not the full thing, it's virtually impossible to get right. Not only this, but there needs to be a layer that changes elements based on device capability and type. This layer does not exist in the standard. Thus, WORA cannot and does not work for HTML5.
And to be honest, it may never work.
Re:About time (Score:5, Interesting)
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.
As long as they... (Score:4, Interesting)
But will it help? (Score:5, Interesting)
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.
This is exactly what Apple wanted. (Score:5, Interesting)
Apple's formula for success under iOS:
1. Control the hardware
2. Control the software
3. Make others do the work and because (1) and (2), you get to take a BIG cut of their business. No, not BIG... HUGE.
Part of (2) is to not allow any development that might result in GOOD write-once/run-anywhere software. Backing HTML5 is a perfect example. The amount of effort required to produce a decent product is just plain insane. Even big companies like Facebook can't do it. Little companies don't even try. In the end, damn near everybody who tries to deploy an application that runs on an iOS device comes to the same sad realization: cough up the dough or go home.
Products that actually worked, and worked well (e.g. Flash, Silverlight, etc.) were killed with feeble excuses like battery consumption and quality control. How the DoJ didn't launch an investigation into anti-competitive practices is a mystery to me. The "browser included in OS" investigation of Microsoft seems a pale shadow of the "you don't run software on iOS devices- despite the fact that their OWNERS want you to- unless you pay us a shiatload of money." /Bitter? You betcha.
Re:UI and OS abstraction library (Score:5, Interesting)
Nope, I'm going to stick by my original statement. In 11 years of professional development, the majority of which had a GUI in some shape or form- 10% is the highest I've ever seen, the average is probably on the order of 3-5%. GUIs just aren't that hard to write and don't really do that much.
Using a 3rd party library can work as well- if your platform supports the toolkit you want to use, and supports it well. Swing last I checked was a nightmare that never worked the same on any two platforms. I'm going to assume it's been fixed, as it's been years since I've used it, but trust me, it was shit. Tk looks like shit on all platforms, it's an ugly UI. It's good for a quick one off, but you'll never see it in professional software.
Then there's the question of what OSes you target. If you ever want to target a proprietary hardware OS, all of those get thrown out. They won't work, and porting them would take more time than rewriting by orders of magnitude. Nor would an OEM selling your stuff ever want to bloat the ROM with a whole QT library. And don't forget, until about a year ago the phone market was dominated by proprietary OSes, until Android came.
Then there are the smartphone OSes- Android, iOS. They don't support any of those. So once again, you're back to not using them.
And in the end, that's why you don't use them- because they aren't truly universal. Because you can't count on them being available on the next port. And the tiny cost to encapsulate the small amount of functionality you actually need is well spent to have the flexibility to say yes when an opportunity to port to a device for a few million comes up.
Now if you're only porting to Windows, Mac, and Linux you're probably good with one of those libraries. Which are all those 3 run on.
Re:About time (Score:4, Interesting)
This is definitely true. The Financial Times native app got replaced with a nearly-equivalent HTML5 "app". Safari asks for permission to store extra data locally, and then it generally feels pretty responsive (relative to other news apps, which in all honesty feel a bit bloated). I'm not sure how compatible it is with other platforms, though - it might have a bunch of really ugly ipad-specific hacks behind it, who knows.