Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Facebook iOS App Ditching HTML5 For ObjectiveC

samzenpus posted more than 2 years ago | from the goodbye-5 dept.

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

cancel ×

240 comments

Sorry! There are no comments related to the filter you selected.

Ask any grey beard. (4, Insightful)

xtal (49134) | more than 2 years ago | (#40482819)

Native code is _always_ better.

Re:Ask any grey beard. (5, Insightful)

jythie (914043) | more than 2 years ago | (#40482923)

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. (5, Insightful)

xtal (49134) | more than 2 years ago | (#40483009)

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. (-1)

Anonymous Coward | more than 2 years ago | (#40483427)

Don't read this... it is a curse...

In 1952, a little boy named Jimmy was having a jolly good time playing on the abandoned railroad tracks just past the backyard of the property he lived on. Being that he could not go anywhere without his favorite blanket, he also, unsurprisingly, had that with him. After a few hours, Jimmy noticed that it had gotten awfully foggy out, and he could no longer see more than 20 feet in front of him.

Jimmy, frightened by this sudden change, decided to head home. While walking past the shed in his backyard, Jimmy spotted a strange teddy bear that he'd never seen before propped up against the tree behind his shed. He noticed that it was waving at him, and, with his blanket covering his head, began to walk faster. It became difficult for Jimmy to move properly, and he couldn't move any faster than he was moving now; this frightened him even more.

Jimmy then heard something creeping up behind him; he instinctively knew it was the mysterious teddy bear. Given that it was walking considerably faster than him, Jimmy gave up all hope of running away and decided to go on the offensive! He turned around and used his blanket to smack the teddy bear away from him. However, after that happened, Jimmy was thrown about 10 feet into the sky by an unseen entity, and upon landing, he bounced around on the ground a few times by making himself flail like a fish.

Once Jimmy stopped bouncing around, he immediately noticed that something was amiss; he felt a strange object sitting directly under his precious ass. Even though most of his body was not sitting on this object, the rest of his body stayed at the same height as the area that was sitting on top of the object, as if his body was a piece of wood. Being a sharp lad, Jimmy was quickly able to determine that the object his butt was sitting on was, in fact, the teddy bear!

Seconds after realizing this, he heard the teddy bear say, in a small infant's voice, "Like, tsk, owie!" The teddy bear's voice sounded like an echo, as if it was talking in a very small, enclosed space. Following this, Jimmy heard a "vvvvvvvvvvvv" sound, followed by the teddy bear being sucked right up Jimmy's snappyhole as if it were a mere spaghetti noodle! While it was being sucked up, Jimmy noticed that the part of the teddy bear that was currently being sucked up would get smaller so as to fit inside his precious snap.

Jimmy, no longer able to move, began panicking. All of a sudden, Jimmy's brain was filled with information that he had never come across before. Jimmy knew, from that point on, that his ass was becoming something completely different; his ass was becoming a rumblehouse ass! That teddy bear was going to use Jimmy's ass as a bouncehouse!

Jimmy began screaming, rolling all over the ground, and punching random objects. However, he realized his protests were futile when the teddy bear began bouncing off of the sides of Jimmy's ass and inflicting tremendous amounts of tickle upon it! Each time the teddy bear bounced off of the sides of his ass, more tickle was inflicted upon Jimmy's anus. From that point on, Jimmy became a mere shadow of his former self. For the rest of Jimmy's life, all of his brain power was used to relive the events of that nightmare again and again. He was never able to function normally again.

Now that you have read even a single word of this, the same teddy bear will get sucked right into your snappyhole and then use it as a bouncehouse in order to inflict extreme amounts of tickle upon it! To prevent this from occurring, copy this entire story and post it as a comment three times.

They need to share a language (2)

tepples (727027) | more than 2 years ago | (#40483779)

In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice?

I agree in principle [pineight.com] . However, sharing components among versions of an application for different platforms works only if all the platforms can run programs written in the same language, and in practice, there are a lot of platform pairs that lack a shared language. For example, how do you share a component between an application for Windows Phone 7, which runs only C# and other languages that compile to verifiably type-safe CIL and do not use the DLR, and the corresponding component for iOS, which runs Objective-C++? Xamarin's answer is to let the Windows Phone 7 port dictate the choice of implementation language for all platforms. This way, components shared with an application for WP7 run in Xamarin's CLR reimplementation for non-WP7 platforms, which Facebook can afford but many individual developers cannot.

Re:They need to share a language (-1)

Anonymous Coward | more than 2 years ago | (#40483795)

*Don't read this... it is a curse...

In 1952, a little boy named Jimmy was having a jolly good time playing on the abandoned railroad tracks just past the backyard of the property he lived on. Being that he could not go anywhere without his favorite blanket, he also, unsurprisingly, had that with him. After a few hours, Jimmy noticed that it had gotten awfully foggy out, and he could no longer see more than 20 feet in front of him.

Jimmy, frightened by this sudden change, decided to head home. While walking past the shed in his backyard, Jimmy spotted a strange teddy bear that he'd never seen before propped up against the tree behind his shed. He noticed that it was waving at him, and, with his blanket covering his head, began to walk faster. It became difficult for Jimmy to move properly, and he couldn't move any faster than he was moving now; this frightened him even more.

Jimmy then heard something creeping up behind him; he instinctively knew it was the mysterious teddy bear. Given that it was walking considerably faster than him, Jimmy gave up all hope of running away and decided to go on the offensive! He turned around and used his blanket to smack the teddy bear away from him. However, after that happened, Jimmy was thrown about 10 feet into the sky by an unseen entity, and upon landing, he bounced around on the ground a few times by making himself flail like a fish.

Once Jimmy stopped bouncing around, he immediately noticed that something was amiss; he felt a strange object sitting directly under his precious ass. Even though most of his body was not sitting on this object, the rest of his body stayed at the same height as the area that was sitting on top of the object, as if his body was a piece of wood. Being a sharp lad, Jimmy was quickly able to determine that the object his butt was sitting on was, in fact, the teddy bear!

Seconds after realizing this, he heard the teddy bear say, in a small infant's voice, "Like, tsk, owie!" The teddy bear's voice sounded like an echo, as if it was talking in a very small, enclosed space. Following this, Jimmy heard a "vvvvvvvvvvvv" sound, followed by the teddy bear being sucked right up Jimmy's snappyhole as if it were a mere spaghetti noodle! While it was being sucked up, Jimmy noticed that the part of the teddy bear that was currently being sucked up would get smaller so as to fit inside his precious snap.

Jimmy, no longer able to move, began panicking. All of a sudden, Jimmy's brain was filled with information that he had never come across before. Jimmy knew, from that point on, that his ass was becoming something completely different; his ass was becoming a rumblehouse ass! That teddy bear was going to use Jimmy's ass as a bouncehouse!

Jimmy began screaming, rolling all over the ground, and punching random objects. However, he realized his protests were futile when the teddy bear began bouncing off of the sides of Jimmy's ass and inflicting tremendous amounts of tickle upon it! Each time the teddy bear bounced off of the sides of his ass, more tickle was inflicted upon Jimmy's anus. From that point on, Jimmy became a mere shadow of his former self. For the rest of Jimmy's life, all of his brain power was used to relive the events of that nightmare again and again. He was never able to function normally again.

Now that you have read even a single word of this, the same teddy bear will get sucked right into your snappyhole and then use it as a bouncehouse in order to inflict extreme amounts of tickle upon it! To prevent this from occurring, copy this entire story and post it as a comment three times.

Re:Ask any grey beard. (1)

wonkey_monkey (2592601) | more than 2 years ago | (#40483903)

Better, in the sense that cost considerations aside...

Yep, that one's usually waaay down the list ;)

Write it all in assembly and get off my lawn. :)

Now, real programmers... [xkcd.com]

Re:Ask any grey beard. (-1)

Anonymous Coward | more than 2 years ago | (#40484147)

**Don't read this... it is a curse...

In 1952, a little boy named Jimmy was having a jolly good time playing on the abandoned railroad tracks just past the backyard of the property he lived on. Being that he could not go anywhere without his favorite blanket, he also, unsurprisingly, had that with him. After a few hours, Jimmy noticed that it had gotten awfully foggy out, and he could no longer see more than 20 feet in front of him.

Jimmy, frightened by this sudden change, decided to head home. While walking past the shed in his backyard, Jimmy spotted a strange teddy bear that he'd never seen before propped up against the tree behind his shed. He noticed that it was waving at him, and, with his blanket covering his head, began to walk faster. It became difficult for Jimmy to move properly, and he couldn't move any faster than he was moving now; this frightened him even more.

Jimmy then heard something creeping up behind him; he instinctively knew it was the mysterious teddy bear. Given that it was walking considerably faster than him, Jimmy gave up all hope of running away and decided to go on the offensive! He turned around and used his blanket to smack the teddy bear away from him. However, after that happened, Jimmy was thrown about 10 feet into the sky by an unseen entity, and upon landing, he bounced around on the ground a few times by making himself flail like a fish.

Once Jimmy stopped bouncing around, he immediately noticed that something was amiss; he felt a strange object sitting directly under his precious ass. Even though most of his body was not sitting on this object, the rest of his body stayed at the same height as the area that was sitting on top of the object, as if his body was a piece of wood. Being a sharp lad, Jimmy was quickly able to determine that the object his butt was sitting on was, in fact, the teddy bear!

Seconds after realizing this, he heard the teddy bear say, in a small infant's voice, "Like, tsk, owie!" The teddy bear's voice sounded like an echo, as if it was talking in a very small, enclosed space. Following this, Jimmy heard a "vvvvvvvvvvvv" sound, followed by the teddy bear being sucked right up Jimmy's snappyhole as if it were a mere spaghetti noodle! While it was being sucked up, Jimmy noticed that the part of the teddy bear that was currently being sucked up would get smaller so as to fit inside his precious snap.

Jimmy, no longer able to move, began panicking. All of a sudden, Jimmy's brain was filled with information that he had never come across before. Jimmy knew, from that point on, that his ass was becoming something completely different; his ass was becoming a rumblehouse ass! That teddy bear was going to use Jimmy's ass as a bouncehouse!

Jimmy began screaming, rolling all over the ground, and punching random objects. However, he realized his protests were futile when the teddy bear began bouncing off of the sides of Jimmy's ass and inflicting tremendous amounts of tickle upon it! Each time the teddy bear bounced off of the sides of his ass, more tickle was inflicted upon Jimmy's anus. From that point on, Jimmy became a mere shadow of his former self. For the rest of Jimmy's life, all of his brain power was used to relive the events of that nightmare again and again. He was never able to function normally again.

Now that you have read even a single word of this, the same teddy bear will get sucked right into your snappyhole and then use it as a bouncehouse in order to inflict extreme amounts of tickle upon it! To prevent this from occurring, copy this entire story and post it as a comment three times.

Ask any game developer (1, Insightful)

perpenso (1613749) | more than 2 years ago | (#40483003)

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.

Re:Ask any game developer (1)

Anonymous Coward | more than 2 years ago | (#40483495)

As a user, I much prefer an app written on the native platform, be it Objective C on iOS, or Java on Android.

The interesting thing is that most apps I encounter on the iPhone tend to be native code, while on Android, they are merely front-ends for a mobile browser website.

Re:Ask any game developer (0)

windcask (1795642) | more than 2 years ago | (#40483625)

Ask any Web Developer, trying to write JavaScript without JQuery.

Ask any Mobile Developer, simultaneously writing for iOS and Android.

Android Native Development Kit (3, Informative)

perpenso (1613749) | more than 2 years ago | (#40483809)

Ask any Mobile Developer, simultaneously writing for iOS and Android.

The need for the Android NDK (Native Development Kit) answered that question. Java-like approaches are fine for certain classes of apps but for many classes native is better.

Re:Android Native Development Kit (2)

AuMatar (183847) | more than 2 years ago | (#40484015)

And allows code sharing. The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to. Pretty much all cross platform phone apps are C++ backends with a thin GUI layer in whatever that platform is pushing.

WP7 only runs CIL (1)

tepples (727027) | more than 2 years ago | (#40484119)

The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to.

I agree, so long as an application is limited to Windows, Mac OS X, X11/Linux, Android, and iOS. So what's the best practice to introduce Windows Phone 7 into that mix? It only runs C# and other type-safe managed languages that don't use the DLR. C++/CLI doesn't count because any nontrivial C++/CLI code that will compile with /clr:safe is a syntax error in a compiler for Standard C++.

Re:Ask any game developer (0)

Anonymous Coward | more than 2 years ago | (#40483835)

I work on a complex, 3D, multi-threaded game engine with complex shaders and AI, and I agree that native code is far superior.

Native code can be highly portable if written with competence. The only non-portable parts of the engine I work on are a few lines of startup code related to the fact that Windows makes modern OpenGL harder to use than most other platforms do. Otherwise, it's native C++, and highly portable.

GL on PS3/360/WP7 (1)

tepples (727027) | more than 2 years ago | (#40484183)

The only non-portable parts of the engine I work on are a few lines of startup code related to the fact that Windows makes modern OpenGL harder to use than most other platforms do.

Do the game consoles and Windows Phone 7 support OpenGL? I thought Xbox 360 and Windows Phone 7 used DirectX, and PS3 used something way off in left field because the OpenGL ES implementation that ships with the devkit isn't worth an expletive. Or is your game PC-only?

Re:GL on PS3/360/WP7 (0)

Anonymous Coward | more than 2 years ago | (#40484321)

PC (Windows/OSX/Linux), and Android. No DX supported yet, but we have the graphics API abstracted well enough that DX targets shouldn't be too hard. It's a matter of implementing our abstraction layer on top of DX, and it was designed to allow that.

WP7 isn't on the radar for us.

Re:Ask any grey beard. (3, Funny)

Kenja (541830) | more than 2 years ago | (#40483027)

What if I build an OS with a native API that runs on the souls of war orphans, but it also has a web browser? What then Mr Beard?

Re:Ask any grey beard. (3, Funny)

armanox (826486) | more than 2 years ago | (#40483139)

If you can do that I'll be impressed.

Re:Ask any grey beard. (4, Funny)

prgrmr (568806) | more than 2 years ago | (#40483209)

if he could do that, I'd pay money to fund the war to produce the orphans.

Re:Ask any grey beard. (1)

Firehed (942385) | more than 2 years ago | (#40483293)

I'll happily do my part to produce orphans.

Re:Ask any grey beard. (5, Funny)

Anonymous Coward | more than 2 years ago | (#40483431)

I think you mean bastards. If you really want to do your part to produce orphans ...

Re:Ask any grey beard. (1)

amicusNYCL (1538833) | more than 2 years ago | (#40484215)

I hate all the orphans in the world!

Re:Ask any grey beard. (1)

Kenja (541830) | more than 2 years ago | (#40483233)

Its proving difficult. Not the first part, but the web browser.

Re:Ask any grey beard. (0)

Anonymous Coward | more than 2 years ago | (#40483031)

I take it you have not tried ObjectiveC then?

Re:Ask any grey beard. (5, Funny)

Quiet_Desperation (858215) | more than 2 years ago | (#40483531)

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.

Re:Ask any grey beard. (0)

Anonymous Coward | more than 2 years ago | (#40483653)

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.

A few less square brackets are required now that Objective-C has literals and Automated Reference Counting (ARC) has made garbage-collection a minimal part of coding. It's much easier to think about object graphs anyway.

Plus if you just prefer to code in straight C or C++ you can do that and then only code a thin layer to touch the UI.

Re:Ask any grey beard. (1)

beelsebob (529313) | more than 2 years ago | (#40484127)

What about ObjectiveC do you not like? Aside - if you leave a shallow answer like "the syntax", rather than actually giving a thought out reasoned answer about semantics, I personally will come around to your house with a trout to slap you.

Re:Ask any grey beard. (0)

Anonymous Coward | more than 2 years ago | (#40484421)

Mostly all those brackets and stuff. Yeah, that's about it.

Re:Ask any grey beard. (2)

roc97007 (608802) | more than 2 years ago | (#40483269)

And while we're on the subject, get off my lawn!

Yeah but... (0)

Anonymous Coward | more than 2 years ago | (#40483537)

...for those of us who choose to accept ad hominem fallacies, isn't switching to ObjectiveC a bad idea just because Facebook programmers think it's a bad idea?

I kid! I kid! C'mon, I admitted that it's a fallacious argument!

Re:Yeah but... (0)

Anonymous Coward | more than 2 years ago | (#40483931)

" I admitted that it's a fallacious argument!"

No, you admitted you don't actually know what the fuck an ad hominem fallacy IS, and that you like to make assertions about things that you have no useful knowledge of.

Re:Ask any grey beard. (1)

SCHecklerX (229973) | more than 2 years ago | (#40483731)

Not if you don't own that device.

Re:Ask any grey beard. (1)

orlanz (882574) | more than 2 years ago | (#40483757)

The only thing true about this statement is that is will _always_ resolve to be "False". Or 0 for you grey beards.

Re:Ask any grey beard. (1)

Eponymous Hero (2090636) | more than 2 years ago | (#40484099)

you'd have to be a fucking moron to think html5 was ever "write once run anywhere."

Re:Ask any grey beard. (1)

gl4ss (559668) | more than 2 years ago | (#40484113)

in mobiles, since 2003 or so there has been certain developer marketing folk pushing for all-html/js solutions as the magic bullet that will make development cheaper by not having to need experts(who know what the device can do and how) and that it's just a matter of mapping javascript api's.

so after that mobile developers have been constantly bombarded with propaganda that in 1-2 years there's going to be so good js engines and renderers that it'll as good as native. an example about this is nokias web runtime(ultimately a big bunch of money wasted on that affair...).

so far it hasn't happened - not even on desktop, js just doesn't cut it. there's a certain subsection of apps where it doesn't matter that much though - but those apps could just as well be just web-sites... and if you want fancy stuff you're going to target the web engines with different code anyways right now.

and you can spend a LOT of time working out the kinks between the version tied to running on safari and the one running on IE9.

About time (0)

nwf (25607) | more than 2 years ago | (#40482859)

Thank goodness. Every app that I see on my iPhone that uses HTML to be portable suffers horrible performance. This includes FB, but also the iTunes store. Over the past few months, the iTunes store has become almost useless on my iPhone 4. FB was among the worst, but it did recently get much faster when they apparently upgraded their servers. It's still crap, don't get be wrong, but it's a good deal better than it was a month ago.

Re:About time (-1)

Anonymous Coward | more than 2 years ago | (#40483151)

And that is not a problem with the OS? RIMM uses HTM5 for apps and it runs smoother than hell on a Playbook and hte future BB10 shoudl be even better. Maybe the problem with iOS is that it is a good solution to "look how much i can spend" but it technically sucks?

Re:About time (5, Interesting)

Korin43 (881732) | more than 2 years ago | (#40483551)

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.

Microphone and camera from HTML5 (1)

tepples (727027) | more than 2 years ago | (#40484219)

Can HTML5 applications for PlayBook or BB10 use a device's microphone or camera? If so, what JavaScript API do they use?

Re:Microphone and camera from HTML5 (0)

Anonymous Coward | more than 2 years ago | (#40484541)

Can HTML5 applications for PlayBook or BB10 use a device's microphone or camera? If so, what JavaScript API do they use?

That is exactly the case for an API such as PhoneGap.

Re:About time (0)

Anonymous Coward | more than 2 years ago | (#40484505)

LOL get a load of this guy - "RIM is relevant! Buy their PlayBook! They're going to AMAZE you with BB10!"

Nice try, Mr. Heins, nice try. We're not falling for it.

Re:About time (1)

kelemvor4 (1980226) | more than 2 years ago | (#40483599)

Thank goodness. Every app that I see on my iPhone that uses HTML to be portable suffers horrible performance. This includes FB, but also the iTunes store. Over the past few months, the iTunes store has become almost useless on my iPhone 4. FB was among the worst, but it did recently get much faster when they apparently upgraded their servers. It's still crap, don't get be wrong, but it's a good deal better than it was a month ago.

Sounds like a problem with the iphone to me....

Re:About time (1)

bongey (974911) | more than 2 years ago | (#40483979)

Maybe they should have wrote the iTunes in flash.

Re:About time (1, Offtopic)

synapse7 (1075571) | more than 2 years ago | (#40484409)

I don't use facebook and do not worry about it.

WORA.... (2, Insightful)

jythie (914043) | more than 2 years ago | (#40482861)

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.

Re:WORA.... (4, Interesting)

steelfood (895457) | more than 2 years ago | (#40483459)

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:WORA.... (1)

dgatwood (11270) | more than 2 years ago | (#40484317)

In Facebook's case, the problem with WORA is much larger than that. Because the interpreter must be consistent across all environments, it is difficult to take maximum advantage of features that do not exist everywhere. Not just the sorts of device capabilities that impact HTML5, e.g. screen size, but also device features, e.g. address book, built-in camera, etc. that cannot be taken advantage of from within a web app.

As a result of this, the Facebook app was never WORA. It was a custom, probably iOS-specific, chimera of a web app and a native app that did some things with native code and other things with web code. This sort of design is inherently fragile, and there were a lot of bugs (of such severity that if you exited the app in certain views, you would be unable to launch Facebook until you deleted and redownloaded the app) that were almost certainly caused by the design.

More importantly, Facebook does pretty much everything with JSON and other similar services anyway (as opposed to providing static HTML content), so there is no real advantage to using HTML for the UI. It adds lots of complexity (two programming languages instead of one, plus the complex interface between them), reduces performance (even with JIT, JavaScript is likely to be a little slower than native code), and leaves you at the mercy of a browser engine for your UI instead of being able to code anything that the native widgets can support.

Re:WORA.... (0)

Anonymous Coward | more than 2 years ago | (#40484411)

Write once, suck everywhere.

First! (1, Informative)

sc0pie (1322903) | more than 2 years ago | (#40482883)

They should have done the native implementation first.

Re:First! (1, Informative)

Anonymous Coward | more than 2 years ago | (#40483489)

They did. Then they changed it to html5. Now they are correcting their mistake.

Is that why it sucks? (2)

blahbooboo (839709) | more than 2 years ago | (#40482915)

Weird, their web browser app is what I use since their app sucks. Guess this is why?

C'mon (5, Insightful)

tthomas48 (180798) | more than 2 years ago | (#40482935)

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

Re:C'mon (0)

prgrmr (568806) | more than 2 years ago | (#40483303)

No, they are having trouble getting a proprietary OS to play efficiently with an open standard, in order to communicate with their back-end servers to cooperate efficiently enough to get it all to scale across several million simultaneous users.

Re:C'mon (2)

alen (225700) | more than 2 years ago | (#40483413)

what is proprietary about iOS? it's freebsd for ARM with a GUI and support for proprietary API's. Safari is webkit just like chrome

Re:C'mon (1)

DdJ (10790) | more than 2 years ago | (#40483663)

Actually, a bunch of the APIs aren't even proprietary. A bunch of it is just an evolution of an openly-developed standard, with two companies behind it, that was deployed on multiple operating systems and multiple hardware platforms, and that has an open source implementation today.

http://en.wikipedia.org/wiki/OpenStep [wikipedia.org]

http://www.gnustep.org/ [gnustep.org]

(Not all, sure. But a bunch.)

Device features unreachable through Safari (1)

tepples (727027) | more than 2 years ago | (#40484523)

what is proprietary about iOS?

The cryptographic key for verifying what is allowed to run on one's own device.

support for proprietary API's

Some features of the device, such as the microphone and camera, can be reached only through these proprietary APIs, not through Safari.

Re:C'mon (4, Informative)

Anonymous Coward | more than 2 years ago | (#40483543)

This is about a browser, not a proprietary OS, and the fact that they have to communicate with back-end servers for several million users has nothing to do with HTML5 vs native. Facebook is having trouble, and it's most likely because the programmers assigned to the task weren't good enough.

There are HTML5 apps that look really good, for example, Fidelity has a nice app that looks sharp and is performant.

Now, personally, I'd rather write in native code than in HTML5, but that is a personal preference, not because HTML5 can't handle the task on iPhone.

Re:C'mon (2)

tthomas48 (180798) | more than 2 years ago | (#40483635)

I might buy that line of reasoning if I couldn't fire up the Facebook website on my phone and tablet and compare the speed with the app.

Re:C'mon (1)

Anonymous Coward | more than 2 years ago | (#40484079)

No, they are having trouble getting a proprietary OS to play efficiently with an open standard, in order to communicate with their back-end servers to cooperate efficiently enough to get it all to scale across several million simultaneous users.

they are having trouble with a company that doesn't care to increase browser rendering or performance, because it will kill their app business along with their walled garden.

Re:C'mon (1)

beelsebob (529313) | more than 2 years ago | (#40484399)

No, they're having problems getting a half baked open standard to support all the features of a proprietry OS, because as per usual, the WORA solution addresses the least common denominator, not the sum of all features.

No. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40483677)

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. (3, Insightful)

Anonymous Coward | more than 2 years ago | (#40483905)

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!

Re:No. (1)

Anonymous Coward | more than 2 years ago | (#40484309)

Hear hear. Why is it that decades after the web has become commonplace, websites still more often than not have white bars left and right, or a horizontal scrollbar, or a tiny font that's hard to read?
I think CSS gives web-designers too much freedom. There are a billion attributes, most of which make a website worse. The width of the page should be left alone, and the same applies to the font and size and colours. Even if someone out there has 30 point green on black courier as his default settings, it's for a reason and you shouldn't mess with it.

Editing (0)

Anonymous Coward | more than 2 years ago | (#40482947)

Real editing would allows me to take Slashdot seriously. Slashdot wonks suck at their job.

Re:Editing (1)

xtal (49134) | more than 2 years ago | (#40483047)

New here?

Good start (4, Insightful)

MrEricSir (398214) | more than 2 years ago | (#40482991)

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 (1, Insightful)

roc97007 (608802) | more than 2 years ago | (#40483369)

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.

Re:Good start (1)

Dog-Cow (21281) | more than 2 years ago | (#40483665)

Why would anyone use old crufty ObjC when there's a nice modern runtime and language to use instead?

Oh, I get it... you're stuck in 1995. Hint: NextStep is history!

Wasn't there some guy behind the app originally? (1)

swb (14022) | more than 2 years ago | (#40483407)

....and he departed FB or said he was done with iPhone development or some other small-scale hubris?

Part of me thinks that FB doesn't really *care* if the iOS app works, they just want to know what platforms you use FB on and if they see regular use from an iDevice, they know that you fit in a specific demographic bucket of "iPhone owner".

Re:Wasn't there some guy behind the app originally (0)

Anonymous Coward | more than 2 years ago | (#40484447)

No, FB went public.

Ignoring a major mobile platform, no , ignoring the mobile platform with the user base most likely to spend money, is not an option.

Re:Good start (2)

homb (82455) | more than 2 years ago | (#40483661)

The problem is that the Facebook engineers went too far.
In their hubris (not necessarily generally bad) they thought that they could literally create a very deep interface between their html code and the underlying native APIs. Essentially abstracting the underlying native APIs with a code interpreter that would allow their servers to send the same html to any device, and some additional stuff for those that had other features.
As usual, they started simple and everything worked, but then over a few months they added more features and the stuff kept growing in complexity and ultimately ate crap. And debugging some kind of virtual machine on a smartphone isn't the easiest thing.
So they're finally figuring out that it ain't working, and going back to native development on top of their standard JSON (or whatever) server API.

Makes no sense to me (5, Insightful)

benjfowler (239527) | more than 2 years ago | (#40483055)

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.

Orkut (0, Troll)

Anonymous Coward | more than 2 years ago | (#40483061)

Fuck Facebook.

Re:Orkut (-1)

Anonymous Coward | more than 2 years ago | (#40483183)

I can't ... I'm too busy with your mom ... and I'm not good at multi-tasking.

Re:Orkut (0)

DemonGenius (2247652) | more than 2 years ago | (#40484197)

Nice, I'm gonna use this one, although most likely in a different context. Thanks for the awesome comeback!

nails (0)

Anonymous Coward | more than 2 years ago | (#40483083)

This will be the first nail in the FB coffin.

di3k (-1)

Anonymous Coward | more than 2 years ago | (#40483131)

WODE . . . Write Once . . . (4, Funny)

PolygamousRanchKid (1290638) | more than 2 years ago | (#40483155)

Debug Everywhere . . .

Why does FB care about write-once run-anywhere? (4, Insightful)

Jake73 (306340) | more than 2 years ago | (#40483299)

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.

Does it need to run native? (1)

Anonymous Coward | more than 2 years ago | (#40483311)

What on earth is their app needing to do that native performance is required?? No thanks, i'll just visit the site.

what what what? (1, Insightful)

roc97007 (608802) | more than 2 years ago | (#40483317)

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? (2, Insightful)

Dynedain (141758) | more than 2 years ago | (#40483499)

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.

Re:what what what? (2)

roc97007 (608802) | more than 2 years ago | (#40483593)

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.

(You are absolutely correct. I was being ironic.)

Re:what what what? (1)

jbolden (176878) | more than 2 years ago | (#40483783)

The coolness of HTML5 video (h.264), was one of the many reasons. And that works great on the iPhone.

Worse problems than HTML5 (1)

cbybear (256161) | more than 2 years ago | (#40483373)

The UIWebView on the iPhone is plenty snappy enough.

I venture to say their network communications layer is poorly implemented. The app is a memory pig. The app is a battery pig. It is 10.5 MB for what? A portal to browse the FB website. Seems way over-engineered to be that big and have a little functionality as it does.

WORA - Fortran (2)

seyfarth (323827) | more than 2 years ago | (#40483429)

Write once, run anywhere? Didn't they say that about Fortran? Write it all in Fortran and get off my lawn.

Re:WORA - Fortran (1)

Old97 (1341297) | more than 2 years ago | (#40483897)

Oh you kids! I bet you are talking about some fancy modern FORTRAN like FORTRAN 77 or later. When I was a young coding buckaroo all we had was FORTRAN 66. Not that was definitely not portable. It wasn't even complete. Every vendor had to complete the language with their own extensions in order to do any thing with memory or I/O. You had it easy.

the enemy of my enemy is my friend (1)

alen (225700) | more than 2 years ago | (#40483463)

Facebook is google's enemy
they are frenemies with Apple

why support HTML5 which also supports your enemy when you could make your frenemie's platform "better" with a native app and hurt your enemy

Show Apple the Money! (0)

Anonymous Coward | more than 2 years ago | (#40483527)

Will Facebook have to pay Apple if people use the new Facebook App Store?

moldy old C/C++/Objective C live on (0)

Anonymous Coward | more than 2 years ago | (#40483615)

...on the desktop and handset.

Many performance issues with Ruby or PHP can be dealt with by adding more or bigger servers, but you can't throw more hardware into the consumer's handset (s/he can, but you can't).

Re:moldy old C/C++/Objective C live on (1)

TheSkepticalOptimist (898384) | more than 2 years ago | (#40483963)

They are not even talking about PHP or Ruby , this is app development using HTML 5 which can live on as a semi-native app on iOS which has nothing to do with server/network performance. BTW that moldy old C/C++ code is the reason why Ruby and PHP works in the first place.

Android version (4, Informative)

gauauu (649169) | more than 2 years ago | (#40483657)

Does the Android version use HTML5 as well? Because it is beyond horrible. I can't figure out why the app would actually be SLOWER and harder to deal with than viewing their site on a browser, but somehow they have managed it.

Re:Android version (2)

geoffrobinson (109879) | more than 2 years ago | (#40483797)

My guess is that the problem is on Facebook's end and Michael Stonebreaker was on to something when he critiqued Facebook's database architecture: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ [gigaom.com]

So to compensate for some of those issues, they have to go to a more responsive UI.

Re:Android version (2)

NormalVisual (565491) | more than 2 years ago | (#40484407)

An unresponsive UI isn't behind stuff like the app's apparent inability to follow outside HTML links without throwing errors, as happens all the time on the Android version for me. It really is one of the poorest excuses for an app that I've ever used.

As long as they... (3, Interesting)

Grizzley9 (1407005) | more than 2 years ago | (#40483857)

fix what's broken and allow the same functionality as the website. I hate it when apps like Pandora, FB, or even G+ or any others that have an app and a website where the website gives you many more options. They only give you the basic experience on the mobile app and am still tied to a computer for doing anything more than basic.

But will it help? (5, Interesting)

FellowConspirator (882908) | more than 2 years ago | (#40483891)

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.

Nothing wrong with HTML (1)

TheSkepticalOptimist (898384) | more than 2 years ago | (#40483921)

Its just that using HTML to build "native" apps for iOS has been proven to be poor over and over again.

Apple just does not want ANY competitive technology to shine on iOS. They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden. Building HTML apps that can be easily ported to other platforms wasn't going to be something that worked better then native iOS apps built for the walled garden.

It comes down to whether you want to be cheap and dirty or invest some time and effort into taking advantage of the native platform. There is no reason for Facebook to be cheap and dirty, they can hire a corporation worth of developers for each platform if they wanted to.

But if you are staring out and want to target all platforms but do not have the technical know-how or man-power to be able to write native apps for each platform, then use HTML, just don't be surprised when it is only an "acceptable" solution.

Their product is inherently crappy. (1)

PeanutButterBreath (1224570) | more than 2 years ago | (#40484025)

Sure, many find it useful anyway, but theirs is not a technological problem.

Mobile Devices (0)

TheNinjaroach (878876) | more than 2 years ago | (#40484105)

Mobile devices just don't have the CPU power and battery life to do HTML5 anywhere close to the efficiency of native code. WebOS made this point painfully clear many years ago.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?