I'm not saying that it's an easy problem. You have to find the right balance between which components should be native or not. It's clear from the other problems that Facebook's been able to solve that they know how to hire top-notch developers. They just failed to do so for their mobile efforts, which just reinforces the stereotype that they don't "get" mobile.
To clarify: I'm not saying that facebook's HTML5 developers can't hold their own -- they produced a great looking mobile app with a truckload of functionality (and believe me, I understand code bloat). Maybe someday it will run flawlessly on mobile. But right now to produce a nice experience in HTML5 you must optimize from the start. Run your code on the device from day 1, not in Chrome with the vertical web inspector! Host your scripts on dev servers with artificial lag. Figure out what's slowing you down on day 1 and work around it! And one day you won't have to :)
So anyway, if you put X efforts, the native app will always win, because it can do all the stuff the HTML5 app can do, but also more, faster, without intermediate layers, in a more native way and with more native look & feel.
Without to mention that for Facebook to use 2x resources to develop the application would be not an issue.
The current Facebook app, if developed by competent guys, is a 3 months project by 2 people, per platform. A joke for FB. (Note: I'm talking only about the app itself, not the backend that is an invariant).
Yeah, MZ is not smart so it is not surprising that he would say not correct things...
Heh...
1. The cost of maintaining iOS and Android is something like 1.5x the cost of maintaining just one or the other. Most of the investment is architecture and design. About 50% of the design is portable across iOS and Android.
2. Developing reliable HTML5 that behaves predictably is as expensive as developing for a native platform. You may already have the skills, but that doesn't make it less expensive.
3. Most touch frameworks (jQuery mobile, etc.) get you 85% of the way there and then you're stuck. To get an app that can compete with native in terms of realization of design, you end up with lots of non-framework code.
4. (Android specific) The same fragmentation that hurts native development hurts support for HTML5. The test matrix for HTML5/browser compatibility on Android is almost as daunting as the native support. Different device/os versions have different web cores that have different foibles. Its just as big a grab bag as ever.
5. Multimedia support for these environments is just atrocious. Unless you can proxy/convert all content, all but the most trivial content is inaccessible. You end up calling into other applications on the platforms which can present a much less compelling presentation to the user.
I'm not going to say its impossible. I'm leaving out all the arguments of performance because it just gets to be to specific to the use case. I have not seen a compelling example of a unified mobile & desktop browser code base that would eliminate all mobile maintenance. Besides just having people rip up my points, I'd be interested in hearing what HTML5 components people are finding make these issues manageable.
In the long run, its not black or white. We use HTML5/css/js for some things and native for most things. Its how we keep things moving but I'm sure we'll revisit this over and over to make sure we keep investing in the right platform.
The good thing about this is the browsers and standards people need a wake-up call. See the comments in Paul Irish's recent thread about this [1].
There are people who are content to plod along and debate the finer points of one attribute or another, while native APIs are steaming ahead. Quotes like "We burned two years" and "Betting completely on HTML5 was the biggest strategic mistake Facebook made" from Facebook's CEO are the kind of evidence that should get people to wake up and smell the coffee, if they still haven't done so.
1. https://plus.google.com/113127438179392830442/posts/fR3iiuN4...
And I'm talking about a small startup. To take the HTML5 approach to develop a mobile application for a very large company is simply silly IMHO, and Facebook CEO is right that this was an huge error in their side.
1. Allowing an IPO that was vastly overpriced.
2. Keeping Zuckerberg in the CEO role for too long.
3. Taking their users for granted.
Obviously the first has seriously damaged their credibility, and with it their ability to hire and retain people who could solve their problems and grow the business.
I believe the second has a similar effect. Aside from the catastrophe of the IPO, Facebook don't appear to be going anywhere strategically. The cat is out of the bag in terms of cost effectiveness (or lack thereof) of Facebook ads compared to alternatives like Google. And generating ad revenue on small-screen mobile is bound to be harder, whether you're using HTML5 or anything else, because the physical screen size only provides so much space.
The third will probably be what finally kills them. As long as they can maintain the critical mass of users, the "everyone's on Facebook because everyone's on Facebook" effect, they can get away with a lot. But no-one using Facebook goes there for the ads, and no-one really likes all the privacy invasion. These things are merely tolerated, and only up to a point, because people like being sociable and right now Facebook lets them keep in touch with their friends and family more conveniently than anyone else.
So when Zuckerberg says "Over the next three to five years, the biggest question on everyone's mind is really going to be how well Facebook does with mobile"[1], I think perhaps he's getting ahead of himself. The biggest question I would ask, if I were a potential investor, is whether Facebook will still have that critical mass of users in three to five years, or whether, like every popular social forum on the Web before them, they will have been disrupted by the new shiny.
Because of their other "mistakes", I will not allow their app anywhere near my devices. A general lack of trust is a mistake that Facebook can't fix.
Mark said they bet too heavily on HTML 5. Did that mean the people who wrote the HTML 5 standards failed them? Or that Google and Apple failed them for writing code that couldn't sufficiently run HTML 5 apps? Or that they overestimated their engineers' abilities to write good HTML 5 apps? Or that they thought HTML 5 was going to be something that it isn't?
Honestly, I don't think he meant any of those things. There is no hidden meaning here: They used HTML 5. It didn't work they way they'd hoped. Now they're using something else. That's it. End of story.
Props to the guy for finding something that wasn't good and fixing it. That's what a CEO is for.
Now they are optimizing for a higher quality product which requires different developer skills and resources. It seems to be paying off.
Neither strategy was wrong so much as maybe how long they stuck with a particular strategy.
One way to help is to ask for lower level OS apis to be exposed by browsers, so that the open source community can do the rest:
1. Ask for UDP to be exposed to trusted web apps installed by the user. This will let the P2P community race ahead without having to wait for WebRTC to get released and then fixed.
2. Ask for TCP to be exposed to trusted web apps installed by the user. This will instantly enable things like SMTP clients running in the browser without the need for WebSocket proxies/proprietary gateway servers.
3. Ask for POSIX to be exposed to trusted web apps installed by the user. This will lead to an explosion of database innovation in the browser. IndexedDB is design-by-committee. Insist on proper POSIX not the FileSystem API. Borrow from the Node API. Impedance mismatch is crippling browser storage.
4. Low-hanging fruit: ask for LevelDB to be exposed directly (http://code.google.com/p/chromium/issues/detail?id=128865). Most of the browser vendors are using LevelDB underneath IndexedDB, and just exposing LevelDB directly would already be a huge leap forward. No need to wait for the many IndexedDB bugs to get fixed by browser vendors.
Maybe HTML5 is in a similar position, may work well for web, but mobile app eocsystems are not yet technologically ready for it to be disrupted. We see it time and time again in history where a new tech takes a while before it becomes good enough to break through (CMOS vs CCD), (HDD vs Floppy vs Tape). (Mainframe -> PC -> Cloud)
There was, after all, a lot of rumour that Facebook would release their own phone. This made sense if your objective is to provide an alternative to mobile OS's, and even more, to overtake your competitors. The belief including the possibility of evolutionary superiority.
Things change. Google supplies Chrome through the app store despite the restrictions imposed by Apple, and this has not weakened the power of Google at the expense of Apple. There are many examples of stepwise cooperation. It has not diminished their independance. And Facebook likewise should probably not have been so concerned that acquiescing to the other majors on mobile would pidgeon hole them as a very very big Instagram style dependant.
Facebook has lost time by being over guarded in my view. On the other hand, this admission by facebook demonstrates a recognition of a kind of failure. I suspect the notion that Facebook will grow to be an organisation that is an evolutionary step beyond Google is now viewed as the real strategic error by them.
As to HTML5 being a mistake, I could be wrong, but I don't really think that that's what he actually means. He's trying to explain himself without admitting some things.
I think the situation is different for small companies and apps that have many fewer users: saving money on app development frees resources for content production.
Is there some expectation that HTML is suddenly a replacement for native apps? That's a rather unexpected (to me, at least) positioning of HTML.
When I used their app at the time, I always found myself waiting for the CSS for each view to load.
“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.”
http://blog.tobie.me/post/31366970040/when-im-introspective-...
There is an article for every statement that zuck made onstage. Getting pageviews is a priority, I guess.
Obviously, I don't work at Facebook so I don't know all the details, but I remember when Joe Hewitt built the native Facebook app, while it was awesome, it was lacking many features 4 months after it's release.
Since developing on iOS can take as much as 2 times longer than HTML development (+ the release cycle with Apple approvement system), it makes sense, in my mind, that they opted to have as much of HTML 5 code as possible.
DISCLAIMER: My first language isn't english.
Yet that's essentially what HTML5 apps are all about -describing the interface in markup and processing it at runtime. In what way is native not always going to be better for a given platform?
So if you want to collect fees from publishers, don't own the browser or the OS (and are not the content creator) - use a closed app.
From the viewpoint of FB this might be (a short-sighted) way forward. It's not in the interest of the publishers and content providers - but again that seemingly doesn't bother FB.
I sure am tired of hearing people talk about 'html5' as if the situation of native vs. browser apps is really any different now than it has been for the past 5 or 10 years.
I don't see these issues with the android version, and it doesn't seem like Facebook is jumping at getting a native android app out there.
Is HTML really to blame?
Is he blind or just wilfully ignorant?
Applications should be done natively.
HTML is for documents.
But never dare you touch a C*O for the failure of a corporation!
Here's an example of what a small team + HTML5 is capable of: http://ro.me
Thus, it seems pretty silly to act as if HTML5 is incapable.