Facebook admits HTML5 not competitive with Cocoa Touch
Facebook's chief executive Mark Zuckerberg admitted that the company's mobile app strategy of targeting HTML5 as a lowest common denominator platform instead of iOS was mistake that wasted two years of its development efforts.
Speaking at the TechCrunch Disrupt conference, Zuckerberg said "we've had a bunch of missteps" in deploying mobile Facebook apps, and that "the biggest mistake we made as a company was betting too much on HTML5 instead of native [platforms]," he said, adding, "We burnt two years."
A report covering the event by The Verge cited Zuckerberg as saying "Native [platform development] is going to be the approach that we go with for iOS and Android" and that "We're betting completely on it."
Apple encourages developers to make use of its native Cocoa Touch platform for creating iOS apps, but also supports full HTML5 web apps as well as hybrid apps that essentially wrap up a web app in order to make it visible and available in the iTunes App Store.
Various parties opposed to Apple for any of a number of reasons have long hoped to deliver mobile apps untethered to the company's native iOS platform, and HTML5 has long been the only viable alternative to do this. But HTML5 has always offered a fraction of the performance of native platforms, making it only really suited to tasks where the web's inherent cross platform compatibility is more important than performance.
When it launched the iPhone, Apple initially announced it would not support existing Java applets (which would have required adding a Java Virtual Machine to essentially duplicate all the native API features of iOS), and over the first few months it also determined that it would be impractical and unnecessary to support Adobe Flash or Flash Lite, which were once significant mobile and web platforms.
This essentially forced developers to write fresh, native apps for iOS, resulting in new library of mobile software that followed Apple's design and security guidelines, quickly establishing Apple's App Store as the best place to buy apps, and therefore the best place for developers to deploy apps.
Efforts that mobile developers pour into native IOS apps aren't necessarily easy to translate into apps for other platforms however. And the closer the code is tied to Apple's Cocoa Touch, the more that's required to adapt it to work on a version of Android, Windows Mobile, generic Java phones, or other competing platforms.
That's why Facebook initially bet on HTML5 development, hoping that it could bring essentially the same code to any mobile device quickly. However, the actual result was that Facebook's largest and most valuable audience on iOS was saddled with a slower app than necessary.
The company addressed the issue only a few weeks ago with a new, significantly faster and more responsive version of its Facebook client that is native to iOS.
Facebook hired a series of former Apple employees, including touch-screen UI developer Greg Novick; iPhone software gurus Tim Omernick and Chris Tremblay; and creator of Apple's first-party Stocks app Scott Goodson, to develop its native Facebook app.
Even when relying on HTML5 code to ease the effort of keeping Facebook up to date across mobile platforms, the company's Facebook app for Android has lagged behind its iOS counterpart, despite being one of the most popular apps on any platform.
As part of its tense negotiating efforts with Apple over the past two years, Facebook also held up any version of its app for iPad, even while it delivered a version for Palm's now defunct webOS. It didn't launch an initial iPad version of its HTML5 Facebook app until October 2011.
Palm's webOS, like Microsoft's tablet-oriented Windows 8 API formerly known as Metro, are both based in HTML5, which is essentially just JavaScript executed by a web browser.
Apple and Google have both supported and contributed towards the open development of HTML5, mostly to prevent web development from being tied to proprietary technologies such as Microsoft's Internet Explorer with dependancies on Windows, or Adobe's Flash plugin.
However, HTML5's inherent association with the open web and untrusted servers requires layers of security and other compromises that makes it disadvantaged when compared to a native platform such as OS X's desktop Cocoa or iOS' Cocoa Touch.
While Facebook has the resources to target multiple native apps on a variety of mobile platforms, its decision to abandon HTML5 in favor of native apps will likely be closely considered by many developers without such resources, who are likely to continue to focus their efforts on native iOS development.
This contradicts the expectations of many pundits who have suggested that mobile app development would quickly migrate from Apple's leading App Store to generic HTML5 apps that can be deployed across a number of platforms, something that has simply never materialized and looks increasingly less realistic given Facebook's decision.
Speaking at the TechCrunch Disrupt conference, Zuckerberg said "we've had a bunch of missteps" in deploying mobile Facebook apps, and that "the biggest mistake we made as a company was betting too much on HTML5 instead of native [platforms]," he said, adding, "We burnt two years."
A report covering the event by The Verge cited Zuckerberg as saying "Native [platform development] is going to be the approach that we go with for iOS and Android" and that "We're betting completely on it."
Apple encourages developers to make use of its native Cocoa Touch platform for creating iOS apps, but also supports full HTML5 web apps as well as hybrid apps that essentially wrap up a web app in order to make it visible and available in the iTunes App Store.
Various parties opposed to Apple for any of a number of reasons have long hoped to deliver mobile apps untethered to the company's native iOS platform, and HTML5 has long been the only viable alternative to do this. But HTML5 has always offered a fraction of the performance of native platforms, making it only really suited to tasks where the web's inherent cross platform compatibility is more important than performance.
Pros and cons of native app development
When it launched the iPhone, Apple initially announced it would not support existing Java applets (which would have required adding a Java Virtual Machine to essentially duplicate all the native API features of iOS), and over the first few months it also determined that it would be impractical and unnecessary to support Adobe Flash or Flash Lite, which were once significant mobile and web platforms.
This essentially forced developers to write fresh, native apps for iOS, resulting in new library of mobile software that followed Apple's design and security guidelines, quickly establishing Apple's App Store as the best place to buy apps, and therefore the best place for developers to deploy apps.
Efforts that mobile developers pour into native IOS apps aren't necessarily easy to translate into apps for other platforms however. And the closer the code is tied to Apple's Cocoa Touch, the more that's required to adapt it to work on a version of Android, Windows Mobile, generic Java phones, or other competing platforms.
That's why Facebook initially bet on HTML5 development, hoping that it could bring essentially the same code to any mobile device quickly. However, the actual result was that Facebook's largest and most valuable audience on iOS was saddled with a slower app than necessary.
The company addressed the issue only a few weeks ago with a new, significantly faster and more responsive version of its Facebook client that is native to iOS.
Facebook hired a series of former Apple employees, including touch-screen UI developer Greg Novick; iPhone software gurus Tim Omernick and Chris Tremblay; and creator of Apple's first-party Stocks app Scott Goodson, to develop its native Facebook app.
Native app for other platforms
Zuckerberg also promised to deliver a native Android app, but only said it should happen "soon," adding that "it will be ready when it's ready."Even when relying on HTML5 code to ease the effort of keeping Facebook up to date across mobile platforms, the company's Facebook app for Android has lagged behind its iOS counterpart, despite being one of the most popular apps on any platform.
As part of its tense negotiating efforts with Apple over the past two years, Facebook also held up any version of its app for iPad, even while it delivered a version for Palm's now defunct webOS. It didn't launch an initial iPad version of its HTML5 Facebook app until October 2011.
Palm's webOS, like Microsoft's tablet-oriented Windows 8 API formerly known as Metro, are both based in HTML5, which is essentially just JavaScript executed by a web browser.
Apple and Google have both supported and contributed towards the open development of HTML5, mostly to prevent web development from being tied to proprietary technologies such as Microsoft's Internet Explorer with dependancies on Windows, or Adobe's Flash plugin.
However, HTML5's inherent association with the open web and untrusted servers requires layers of security and other compromises that makes it disadvantaged when compared to a native platform such as OS X's desktop Cocoa or iOS' Cocoa Touch.
While Facebook has the resources to target multiple native apps on a variety of mobile platforms, its decision to abandon HTML5 in favor of native apps will likely be closely considered by many developers without such resources, who are likely to continue to focus their efforts on native iOS development.
This contradicts the expectations of many pundits who have suggested that mobile app development would quickly migrate from Apple's leading App Store to generic HTML5 apps that can be deployed across a number of platforms, something that has simply never materialized and looks increasingly less realistic given Facebook's decision.
Comments
Perhaps the first breaker off a greater wave of common sense.
webOS??? Sounds like Zuck is having trouble prioritizing. No wonder he burned Facebook chasing after HTML5.
So in that sense HTML5 makes even less sense, because it's not a choice between 100% cross-platform or 100% native, it a choice between 100% cross-platform or 90% cross-platform (your company's portable C libraries) and 10% native.
The main reasons for this difference are foundational technologies like plist or CoreData storage, or native Java serialization frameworks. That stuff alone makes development much smoother for saving data to storage on mobile devices, something you do way too frequently to attempt in C struct and file IO routines.
Simply put, native development wins by just by being much more efficient, and the upside is much smoother performance.
Quote:
Originally Posted by otri
ascii, sorry man, but the effort to write in plain C is about 10x over writing in ObjC.
C is like latin. In all likelihood, there probably were not many romans who knew latin officially, or very well. That's why it has sort-of diluted into a dozen or so simpler, sloppier european languages. There were a few romans who were masters of the language, and they could use it with more poetry and metaphor than Shakespeare used english, and supremely concisely at the same time.
C is hard. That's not a good excuse not to consider it an option, though, because there are plenty of engineers who can use C the way Cicero used latin. If you need to make a piece of code that must run fast, run light, and be insanely portable, you are a fool not to use C.
Moreover, by my observation, "rapid application development" with ObjC and (especially) Java have not really made development of good software faster. They have certainly made development of crap faster, and 9 times out of 10 such crapware needs to be constantly maintained and changed. For "New-media" this fits the deployment model very well, since the code needs to be changed all the time anyway. If you are instead releasing an app that has a slow-changing feature-set, you are also a fool not to use C.
Ultimately it depends on what the functionality of the app would be. There's lots of scenarios where web apps have proved more popular, particularly things where the use is infrequent so people don't want to have to bother installing an app.
Personally I'm on the side of native apps are best. But mainly because apps are best when they function in a standard way. Unlike a lot of HTML5 apps which try to look like native apps but are always slightly different. Then there's the issue of different platforms looking different and having different physical buttons. e.g. iPhone style web apps look stupid on WP7, particularly when they have a back button on the screen.
Quote:
Originally Posted by otri
ascii, sorry man, but the effort to write in plain C is about 10x over writing in ObjC. So even if you gained cross platform compatibility, you would have expended that effort 10x already, like targeting 10 platforms. That would be positively insane. C and STL code bases make this more like a 4x effort, but it's still considerable.
The main reasons for this difference are foundational technologies like plist or CoreData storage, or native Java serialization frameworks. That stuff alone makes development much smoother for saving data to storage on mobile devices, something you do way too frequently to attempt in C struct and file IO routines.
Simply put, native development wins by just by being much more efficient, and the upside is much smoother performance.
That really depends on your developers and what you have them doing. From my experience managing developers if you get them to program in more than 1 language, irrespective of the languages being good they will always be far slower than someone who is dedicated to 1 language and has more time to become a super expert in it. So if you have developers writing apps in ObjC, Java and HTML5 there productivity level has a good chance of reducing to a point where the languages aren't offering a speed advantage any more.
Quote:
Originally Posted by Splinemodel
Moreover, by my observation, "rapid application development" with ObjC and (especially) Java have not really made development of good software faster. They have certainly made development of crap faster, and 9 times out of 10 such crapware needs to be constantly maintained and changed. For "New-media" this fits the deployment model very well, since the code needs to be changed all the time anyway. If you are instead releasing an app that has a slow-changing feature-set, you are also a fool not to use C.
Objective C is basically C, with some Object oriented stuff added on, which means it compiles down to the same type of byte code, it is not interpreted. There is a minor cost to calling an Obj C method rather than a C function, but Objective C is actually pre-processed to C. Except for portability the thing to use on native platforms is native code, it is probably easier to use, and probably more efficient to use NSString than C++ string::. The C version of NSString is CFString - in fact the beack end of a native iOS app can be written in non-portable C. I dont see that point of that at all unless there is some reason you cant use Objective C.
As I said: it is preprocessed to C:
- (int)foo:(NSString *)str { ...
Gets translated to a function like this:
int SomeClass_method_foo_(SomeClass *self, SEL _cmd, NSString *str) { .
The only exception I tend to use, if I start from scratch is to not use CoreData is I can help it, I use SQlite. Magic stuff breaks.
Quote:
Originally Posted by asdasd
Objective C is basically C, with some Object oriented stuff added on,
The problem is object oriented. There's a nice presentation somewhere on the web, by the Sony PS3 team, about why object oriented design practice leads to software architectures that don't match well with current hardware. This is true for any chip with a multilayered cache, but especially multicore. In a nutshell, it's important to put like data next to like data, the exact opposite of object bundling. In other words, if you take away the object oriented parts of objC, you are left with the part of the language that is fast and light, and also the part of the language that is ... C.
That said, objC + Cocoa + iOS is simply a better platform than what Android provides. Even if you are a ham-fisted moron, the iPhone app will turn out better than the Android app. I suspect part of this is due to objC itself. Generally speaking, I think objC is just fine. Mostly I am speaking against the commonly held fallacy that it's impossible (or just too hard) to develop a good app with C. You just need to contract a few C aces for a few months out of their embedded or game programming jobs.
It depends what you were expecting it to revolutionise. I don't think it was ever going to replace native apps. That much was clear in 2007. The iPhone launched with webapps only and that was the intended development method. Within 9 months it had a native SDK.
The best setup is native apps + cool websites (which will be HTML5). This has nothing to do with Flash, which HTML5 has already replaced for the most part.
The way it is currently worded, you're suggesting that people who wanted to deploy "applications" on the iPhone when it first came out were forced to resort to a native API. That is not true at all. The first "applications" on the iPhone were forced to be written in HTML5.
The native API option only arrived approximately 3/4 of the way through the original iPhone's release cycle.
DED doesn't provide this part of Zuck's quote: “When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.” See the video here: http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/
Global success was had on the web so long term, it seems even higher risk degrading it.
HTML5 and current web technologies are great, but they're not quite as good performance-wise as native, and likely never will be. This doesn't mean they suck, just that they can't cover every use...
Quote:
Originally Posted by Mikeb85
HTML5 and current web technologies are great, but they're not quite as good performance-wise as native, and likely never will be. This doesn't mean they suck, just that they can't cover every use...
This is a pretty cool example of what can be done with "traditional HTML and CSS with 3D transitions and HTML5 APIs."
http://chrome.blogspot.com/2012/09/moving-singing-and-dreaming-with-chrome.html
FWIW I think Safari will work as well as Chrome for viewing this. Pretty sure it supports WebRTC