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."

Comments

Ask any grey beard.

[xtal]

Native code is _always_ better.

Re:Ask any grey beard.

[jythie]

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.

Re:Ask any grey beard.

[xtal]

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. :)

Re:Ask any grey beard.

[Simon Brooke]

Speaking as a greybeard (both literally and as a thirty-year veteran of this industry), bullshit. When I was young there were still a few people around who could write software by writing opcodes out in pencil on the train home and have them work first time without bugs (Chris Burton, who helped build the Manchester Mark One, I'm thinking of you), but most people can't. And most people cannot write C well enough to outperform the software that the same person can write in a decent high level language.

Virtually no-one, now, can write anything sophisticated or complex in opcodes. Virtually no-one can do it even in assembler (yes, I know you did a little assembler project in CS101, but that really doesn't count). Yes, I know that a few rare geniuses can write exceedingly efficient fault free code in C or C++. Most complex programs written in C or C++, however, are too expensive in debugging and maintenance costs to outweigh any very small performance advantages they might have over high level languiages. Grow up, and live in the modern age. Toggling switches on the console, teletypes, punchcards, assembler and C are all history.

(Mind you, of course, there is some exceedingly bloated code around. I recently installed, on Windows, a Bluetooth device driver that was 60 Megabytes, which I found unbelievable... the fact that we have high level languages is no excuse for bloat or sloppy engineering practices.)

WORA....

[jythie]

Has appeal in theory (and sometimes practice); looking great on paper, but it is easy to get swept up in enthusiasm for the concept and not really think though how applicable it is to any given environment.... and even when it does work it is pretty rare for something to truly 'work anywhere' in the real world.

C'mon

[tthomas48]

They're having trouble returning a few hundred lines of text and 10 photos. Methinks HTML rendering speed is not even remotely their problem.

Good start

[MrEricSir]

That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.

At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.

Re:Good start

[roc97007]

That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.

At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.

And (this is the point, really) not just on IOS! Blaming the problems on html 5 and changing to old crufty Objective C sounds like a rationalization. An excuse used by executives to board members who don't know any better.

Ask any game developer

[perpenso]

Re:Ask any grey beard. Native code is _always_ better.

Ask any game developer, well those working on anything beyond the simple casual game segment.

Makes no sense to me

[benjfowler]

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.

Why does FB care about write-once run-anywhere?

[Jake73]

They are a multi-billion dollar company dealing with an app running on one of (if not the) most relevant and widely-used smartphones in the market. They should dedicate a team specifically for the iPhone. And if Apple changes the API every week, they would be wise to rewrite the app every week just to maintain that market.

I don't care for Facebook and have my issues with Apple, but this is just a business decision on ROI.

what what what?

[roc97007]

But... isn't html 5 the latest and coolest thing, and Objective-C some really old thing that Apple inherited from medieval times?

And and... hang on... wasn't the coolness of html 5 the excuse for Apple not supporting some old and crufty thing called Flash?

Re:what what what?

[Dynedain]

This is just Facebook trying to blame their shoddy implementation on someone else.

None of the bugs and issues reported by users are HTML5 caused problems.

No.

[Anonymous Coward]

UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements. It is plainly obvious you understand nothing on this topic.

The issue is UI *latency*. HTML based UI cause increased round trips from mobile devices to their data-centers creates a terrible experience for users when compared to native apps. Mobile devices already are worse off when it comes to network latency, and this exaggerates the problem.

HTML + CSS + JS is the worst "modern" paradigm to base any kind of UI on. Don't get me wrong.. its also a horrible data/text layout language too. It can't even do what layout programs used for producing magazines 50 years ago did. Not to mention the standards themselves are so horrible that nobody in the entire world has ever in the history of standardization been able to produce a reference implementation. And judging by the several hundred KiB sizes of webpages these days, it would be more efficient if you just hosted a damn PDF file, at-least it would look the same everywhere.

Re:No.

[Anonymous Coward]

at-least it would look the same everywhere.

And here we have the problem. Web pages are not supposed to look the same everywhere.
Yet PHBs trying to achieve that are what cause literally every problem in Web standardization.

Just serve me the information, and I'll render it how I like.
Quit obsessing about controlling my user agent!

iOS 6 FaceBook support

[Dixie_Flatline]

Given that Apple is integrating FaceBook support into iOS 6 (I've got it on my phone right now, and the 'post' button works exactly as advertised), it seems to me that this is probably being done in no small part because Apple is doing a bunch of stuff in Obj-C anyway. I have no idea what the FB API stuff is like (or even if it's available to devs like me) but there's clearly *something* going on under the hood.

So Apple does some of the heavy lifting, and the FB programmers just piggyback off of it. At that point, why not switch?

Re:The Thin GUI Line

[AuMatar]

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.