Mark Zuckerberg: Our Biggest Mistake Was Was Betting Too Much On HTML5(techcrunch.com)
techcrunch.com
Mark Zuckerberg: Our Biggest Mistake Was Was Betting Too Much On HTML5
http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/
37 comments
But why did Facebook get away with it for so long?
http://www.quora.com/Facebook-Engineering/Why-does-Facebook-...
Why does Facebook not need to produce particularly high-quality software?
By paying less attention to quality, Facebook has been able to focus on other things, like making the company a fun place to work at that can attract and retain talented engineers. Facebook would probably be less fun if it cared more about quality.
Facebook's product is a website, so it can fix things quickly. It has a process which permits rapid deployment of new code, and rapid rollback of buggy changes. This reduces the cost of recovering from bugs.
Facebook's product has a lot of momentum and lock-in. The barrier for users or businesses to move off Facebook is very high. This gives Facebook a wider margin of error to ship glitchy software. If Google was broken for a day, you'd probably go to Bing and might not come back. If your iPhone pissed you off all the time, you'd probably buy an Android when you're faced with the decision in a year or two. If you can't order something on Amazon, you can order it from somewhere else. If Facebook is broken, you keep coming back until it works again.
Why does Facebook not need to produce particularly high-quality software?
By paying less attention to quality, Facebook has been able to focus on other things, like making the company a fun place to work at that can attract and retain talented engineers. Facebook would probably be less fun if it cared more about quality.
Facebook's product is a website, so it can fix things quickly. It has a process which permits rapid deployment of new code, and rapid rollback of buggy changes. This reduces the cost of recovering from bugs.
Facebook's product has a lot of momentum and lock-in. The barrier for users or businesses to move off Facebook is very high. This gives Facebook a wider margin of error to ship glitchy software. If Google was broken for a day, you'd probably go to Bing and might not come back. If your iPhone pissed you off all the time, you'd probably buy an Android when you're faced with the decision in a year or two. If you can't order something on Amazon, you can order it from somewhere else. If Facebook is broken, you keep coming back until it works again.
I'm not sure I 100% buy into the first statement. Why are fun place to work and quality products mutually exclusive?
I'd say that Facebook's acquisition of top talent has much more to do with them having huge pre-IPO monetary incentive and less to do with being a "fun place to work".
I'd say that Facebook's acquisition of top talent has much more to do with them having huge pre-IPO monetary incentive and less to do with being a "fun place to work".
Because quality either means writing tons of test code, or having lots of process and manual regression checks.
Any impediment to shipping code makes things less fun for many developers.
Any impediment to shipping code makes things less fun for many developers.
>* Why are fun place to work and quality products mutually exclusive?*
Because "fun place to work" obviously means beer and bongs passing around, in-office swimming pool, bikini models, pool and air-hockey tables, and Futurama watching marathons.
Which doesn't result in the highest quality products, if any products at all.
Because "fun place to work" obviously means beer and bongs passing around, in-office swimming pool, bikini models, pool and air-hockey tables, and Futurama watching marathons.
Which doesn't result in the highest quality products, if any products at all.
Or would you rather work at a place where every little change you want to make needs to be "approved", and any new ideas you wanted to try needs to be checked off by a manager, who may or may not want it implemented depending on the political situation?
No, because "fun place to work" means your #1 focus on building new features and getting them out to users as quickly as possible. Building quality products means the tedium of writing test suites larger than the rest of the code base, fixing them when they fail, and a sometimes-lengthy review process before pushing things to prod.
Not saying the stuff associated with quality is bad -- quite the opposite -- but (at least to me) that part isn't particularly fun.
Not saying the stuff associated with quality is bad -- quite the opposite -- but (at least to me) that part isn't particularly fun.
Is that really what's it's like, or is that just what it looked like in a movie about its early days?
Because people really, really like Facebook apparently...
Or they simply don't prioritize mobile. As has been extensively documented, they make virtually no revenue off of mobile use and see no easy way to improve that situation in the future. They're stuck in a situation where a great mobile experience is a near-term harm to revenue.
That doesn't seem right. Facebook has an increasing user base focused on mobile, their main priority for the moment has to be monetizing mobile. It's not a simple solution but it's a long standing problem that they've recognized.
Mark Zuckerberg notes the huge potential in revenue from mobile here:
http://techcrunch.com/2012/09/11/zuckerberg-says-on-mobile-w...
I don't think those arguments contradict. I'm saying that in the short term, more mobile users means less money for the simple reason that mobile users aren't checking Farmville or reading ads. Zuckerberg might note a "potential" for revenue in mobile but he's not getting any today. (Quick google turned up this link to that effect, there are lots of stories like this: http://www.forbes.com/sites/greatspeculations/2012/07/27/fac...)
So in the short term, a better mobile experience hurts, not helps, FB's bottom line. So they'll likely be looking at spending their development resources elsewhere.
So in the short term, a better mobile experience hurts, not helps, FB's bottom line. So they'll likely be looking at spending their development resources elsewhere.
> Zuckerberg might note a "potential" for revenue in mobile but he's not getting any today.
This isn't true any more. The new version of the Facebook iOS app includes sponsored "your friend liked [brand]" callouts periodically in the news feed.
This isn't true any more. The new version of the Facebook iOS app includes sponsored "your friend liked [brand]" callouts periodically in the news feed.
Except they have those same posts on the desktop version in addition to farmville and normal ads. That's even ignoring the fact that mobile ads are worth way less than desktop ones since people aren't really as engaged on mobile, and aren't likely to type in their credit card while they are on a bus.
> Except they have those same posts on the desktop version in addition to farmville and normal ads.
Yes, but they didn't have anything like it on mobile until just recently. The iPhone app was zero revenue. It is now non-zero revenue.
Yes, but they didn't have anything like it on mobile until just recently. The iPhone app was zero revenue. It is now non-zero revenue.
That is silly. No one leaves their phone number to go find a laptop to read Facebook.
Yes, yes, a million times yes. Facebook is very resource intensive (in terms of data+media loading over the wire) but there are certainly ways to work around this. Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good example of this. The main problem with HTML5 media apps today is that they must be developed with a primary focus on optimization from the start. This is unfortunate, and will hopefully change, but it is possible. But seriously, saying "HTML5 failed you" when you don't even compile your scripts and initial resources to require a minimal amount of requests is just ludicrous.
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 :)
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 :)
But that more or less just leads to the question: If HTML5 requires extra work to get right, isn't that what Zuckerberg was saying?
It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work that you have to put in anyways with native mobile apps, and then the lack of that work ends up biting you in the end.
One of the big promises of mobile HTML5 was that you could just take your desktop web apps, scale them down, give them new CSS, and they'd "just work". It doesn't work that way. You need to test on actual mobile devices from the start, you need to account for the lower CPU performance of them, you need to figure in higher latency over 3G connections vs. wired LANs.
You have to do all of this on native apps anyway, but you know you have to do it from the start, otherwise you can't even get your app to display, and the frameworks are built with this in mind. There're still some areas where HTML5 wins - it's easier to update the app, for one, and it's more familiar to web developers. But the developer-convenience scales were not shifted as far to the HTML5 side as people hoped they were.
I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". We aren't going to get that in a TechCrunch soundbite; there're a lot of specifics that depend upon exactly what your market is.
One of the big promises of mobile HTML5 was that you could just take your desktop web apps, scale them down, give them new CSS, and they'd "just work". It doesn't work that way. You need to test on actual mobile devices from the start, you need to account for the lower CPU performance of them, you need to figure in higher latency over 3G connections vs. wired LANs.
You have to do all of this on native apps anyway, but you know you have to do it from the start, otherwise you can't even get your app to display, and the frameworks are built with this in mind. There're still some areas where HTML5 wins - it's easier to update the app, for one, and it's more familiar to web developers. But the developer-convenience scales were not shifted as far to the HTML5 side as people hoped they were.
I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". We aren't going to get that in a TechCrunch soundbite; there're a lot of specifics that depend upon exactly what your market is.
> One of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y".
This should be the actual soundbite, and it bears repeating.
This should be the actual soundbite, and it bears repeating.
So why bothering at this point? If I have to optimize for a given platform, I'd rather use the programming environment that gives me the best tooling.
It depends on exactly how much you end up having to optimize for each platform, and how much reuse you get between platforms.
If your app is a simple broacherware+notifications app, then HTML5 is probably the way to go.
If you can afford expert developers for every platform and mobile is critical to your success then 100% native makes sense.
There just isn't a simple answer here. To quote nostrademons:
I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y"
If your app is a simple broacherware+notifications app, then HTML5 is probably the way to go.
If you can afford expert developers for every platform and mobile is critical to your success then 100% native makes sense.
There just isn't a simple answer here. To quote nostrademons:
I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y"
You're comparing apples and oranges. If you optimize for a mobile browser, you can target every modern mobile platform simultaneously, and most of your work overlaps with making your app work nicely for people on laptops and desktops.
If you go for a native app, you'll have to practically start over for every operating system.
If you go for a native app, you'll have to practically start over for every operating system.
Define "best". The best tools aren't necessarily the ones that give you maximum control or best performance. If that we're true we wouldn't have so many Ruby on Rails or Django web apps.
Good point. By 'best tooling' I'm mainly thinking about two things:
- How easily can I debug things if something breaks?
- In case I'm not happy with a certain behavior is it a dead end or can I simply swap out a parameter / function / module (in that order)?
These two aspects are IMO essential for choosing any development environment if I have the choice. This goes for web development too, which is why I'd prefer something like Django over something like Joomla for example. I don't even care so much about performance at that point.
Do you agree with me that at least in case of iOS, native beats html+js+webviews in those two points?
- How easily can I debug things if something breaks?
- In case I'm not happy with a certain behavior is it a dead end or can I simply swap out a parameter / function / module (in that order)?
These two aspects are IMO essential for choosing any development environment if I have the choice. This goes for web development too, which is why I'd prefer something like Django over something like Joomla for example. I don't even care so much about performance at that point.
Do you agree with me that at least in case of iOS, native beats html+js+webviews in those two points?
I wouldn't. Debugging js is quite easy, overall probably more straightforward than dealing with Xcode. And there are tons more choices in the js world, having both more developers and a more free-as-in-speech mindset.
The big downside is the one Facebook found, js in a webview is just... slow.
The big downside is the one Facebook found, js in a webview is just... slow.
Correction. Debugging JS in not easy. I have been working on a native application which has some HTML5 components in webviews. There is no easy way in XCode to debug JS in this kind of mixed application. In fact, it is a royal pain in the ass. You can run the JS in Chrome debugger or a web development IDE, but that can only work if all your functionality is in HTML5/JS and not a mix of Native and HTML5.
Thanks. I was gonna ask parent how he does it because if it's easy for him he might know some magic I'm not aware of.
Wow, I am going to save this one:
"It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work and then the lack of that work ends up biting you in the end."
I have never experienced such hard-torque spin in my life. It's not that you would need to put in overtime if you worked here. It's just that we really let you get away with never putting in overtime, if you don't want to. And then that lack of overtime ends up biting you in the end.
"It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work and then the lack of that work ends up biting you in the end."
I have never experienced such hard-torque spin in my life. It's not that you would need to put in overtime if you worked here. It's just that we really let you get away with never putting in overtime, if you don't want to. And then that lack of overtime ends up biting you in the end.
The point he's making is this:
If you put in <x> effort into HTML5 you'll have a slow, shitty version. If you put in <x+y> you'll have a nice fast version.
If you put in <x> effort with a native app, you have nothing. If you put in <x+y> you have a working, fast app.
You get a working prototype faster with HTML5, but that's not a fair comparison with a native app which took more work to get working at all.
If you put in <x> effort into HTML5 you'll have a slow, shitty version. If you put in <x+y> you'll have a nice fast version.
If you put in <x> effort with a native app, you have nothing. If you put in <x+y> you have a working, fast app.
You get a working prototype faster with HTML5, but that's not a fair comparison with a native app which took more work to get working at all.
But it's not really true, at least if you want a truly fluid UI... although I think it's possible to make UI written in HTML5 feel native, I have yet to use a single complex webapp that truly accomplishes it, unless it's hidden in a UIWebView in some app I use. (Gmail might come close if it didn't apparently use onclick instead of ontouchstart, and custom scrolling instead of -webkit-overflow-scrolling: touch, for no discernible reason.)
It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow.
And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing.
As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.
It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow.
And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing.
As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.
FWIW, I've had to do my desktop web development without the benefit of frameworks for the last 4 years, since the latency constraints on Google Search preclude using them. It's nowhere near as hard now as it was in 2007, when you had to worry about IE6/IE7/Firefox/Safari, and IMHO is the biggest hole in most web developer's skillsets. Mobile HTML5 is easier still as the vast majority of the market uses Webkit, though the Mobile Search team here tells me that you can't assume that since there're still a bunch of shitty Blackberries around. If you still need JQuery/Prototype/Closure to do anything useful in Javascript, I really would recommend learning the browser-native HTML5 APIs and CSS3, because they aren't that much harder and perform much better.
(I do like the better layout systems and widget libraries of native frameworks - I did desktop app development with Swing and MFC before HTML/JS, and it really was significantly easier to put together a complex UI that matches the native look & feel with those. HTML5 gives you the opportunity to be creative that you don't have when you overrely on a framework, though.)
(I do like the better layout systems and widget libraries of native frameworks - I did desktop app development with Swing and MFC before HTML/JS, and it really was significantly easier to put together a complex UI that matches the native look & feel with those. HTML5 gives you the opportunity to be creative that you don't have when you overrely on a framework, though.)
Livestand by yahoo! on iPad, but y! killed it. i hope they bring it back. it was really awesome app.
To be clear, I'm not necessarily backing his argument. Just clarifying it.
[deleted]
>Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good example of this.
An app which all of 50 people use --and many of them curse while doing it.
An app which all of 50 people use --and many of them curse while doing it.
According to comScore, Yahoo Mail is the third largest mail provider with over 300 million users.
Kicker:
> in the U.S., Yahoo is No. 1, with 96.6 million active users
http://news.cnet.com/8301-13772_3-20114975-52/microsoft-aimi...
Kicker:
> in the U.S., Yahoo is No. 1, with 96.6 million active users
http://news.cnet.com/8301-13772_3-20114975-52/microsoft-aimi...
On the Kindle Fire (and my Android phone) at least, their mail app puts most others to shame. It's one thing they've done extremely well.
50? It's more than 50 million if I am not wrong. Get your facts right.
I think your reasoning is flawed here, what is in the good side of HTML5 to develop a mobile app for Facebook, even assuming good HTML5 developers VS good iOS/Android developers? HTML5 is not faster to develop in environments like iOS that provide good API and tools, and the stuff you can't do in HTML5, you have to find a glue between the native side and HTML5 that is non optimal.
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).
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).
Facebook used HTML5 for a variety of political and technical reasons.
On iOS, using HTML5 decoupled deployment of functional changes from the App Store approval process. They could add a new feature on the servers and have it available on phones immediately. Certain parts of the new app still use HTML to allow new features without updating the whole app.
On Android, HTML5 let them support a large number of phones with fewer special cases to work around old versions of the OS and phone-specific bugs.
On iOS, using HTML5 decoupled deployment of functional changes from the App Store approval process. They could add a new feature on the servers and have it available on phones immediately. Certain parts of the new app still use HTML to allow new features without updating the whole app.
On Android, HTML5 let them support a large number of phones with fewer special cases to work around old versions of the OS and phone-specific bugs.
Except that, once you're done developing a hybrid app, you now have a giant chunk of reusable code. Facebook simultaneously supports several different platforms (normal website, mobile website, iOS app, Android app, Windows Phone app, Blackberry app, etc). Any amount of code reuse is a huge win when you're trying to maintain feature parity in many different directions.
Oh come on, you are making it sound as if it would be a massive investment for Facebook to develop native apps for multiple platforms.
If I can build a Facebook client that covers the most important features within 3 months (at 2 evenings per week after work) then I'd bet that a company like Facebook (with hundreds of developers that are much better than I am) could invest the needed resources (maybe 3-4 developers per platform) to create a truely amazing native experience.
I'd even argue that it is not an option for anyone in their position to even consider going HTML5 just to reuse some code. That would be just the wrong place to save a few bucks for them, considering that they need to make a transition to mobile pretty soon and failing to do so would be an open invitation for competitors to come and basically kill them.
Additionally I'd like to add that I am not convinced that is even possible (or if so many times harder) to create a content rich application like Facebook with webviews wrapped in native code that feels as fluid and responsive as a full native app. I have tried this in the beginning with my Facebook client (app link: https://play.google.com/store/apps/details?id=com.flipster) and failed miserably before stopping this webview nonsense, and so did the Facebook developers.
If I can build a Facebook client that covers the most important features within 3 months (at 2 evenings per week after work) then I'd bet that a company like Facebook (with hundreds of developers that are much better than I am) could invest the needed resources (maybe 3-4 developers per platform) to create a truely amazing native experience.
I'd even argue that it is not an option for anyone in their position to even consider going HTML5 just to reuse some code. That would be just the wrong place to save a few bucks for them, considering that they need to make a transition to mobile pretty soon and failing to do so would be an open invitation for competitors to come and basically kill them.
Additionally I'd like to add that I am not convinced that is even possible (or if so many times harder) to create a content rich application like Facebook with webviews wrapped in native code that feels as fluid and responsive as a full native app. I have tried this in the beginning with my Facebook client (app link: https://play.google.com/store/apps/details?id=com.flipster) and failed miserably before stopping this webview nonsense, and so did the Facebook developers.
Agreed.
On the scale of Facebook's resources, building well-functioning apps just isn't a hard problem. Not saying it's not hard, just saying it's not hard on the scale of Facebook's resources.
On the scale of Facebook's resources, building well-functioning apps just isn't a hard problem. Not saying it's not hard, just saying it's not hard on the scale of Facebook's resources.
Creating a functional and performant HTML5 app shouldn't have been hard at their scale either. So either it's actually impossible to do better than what they put out (which I find hard to believe -- is it really that much more complex than the HTML5-based LinkedIn app?) or there's some other reason.
I just can tell you what my experience is. I was unable to do it, but what you have to consider on Android is that a many customers are going to use crappy cheap phones with a weak processor, so every layer of abstraction added is going to hurt the performance a lot.
Additionally making the mobile app run smoothly on any device is just the bare minimum for what they should deliver. It's hard to not compare it against competition like the Android Google+ app, which absolutely crushes the Facebook app (I'm talking about the UI here, not about the social network itself), and that's where my sketicism comes from. Even if someone was able to deliver a WebView based app like Facebook, running smoothly on cheap devices, other competitors betting on native (like Google+) would still be in a different league.
Additionally making the mobile app run smoothly on any device is just the bare minimum for what they should deliver. It's hard to not compare it against competition like the Android Google+ app, which absolutely crushes the Facebook app (I'm talking about the UI here, not about the social network itself), and that's where my sketicism comes from. Even if someone was able to deliver a WebView based app like Facebook, running smoothly on cheap devices, other competitors betting on native (like Google+) would still be in a different league.
How re-usable is it really? The bulk of the work is being done at the server in this case, and the app is mostly UI code. UI code is very platform dependant. I think that HTML5 is probably the future, particularly if things like Firefox OS take off, and it's probably fine for a MVP mobile app (possibly combined with something like PhoneGap). Currently though, native apps definitely provide a better experience, and you should probably do it if you have the resources... and this is from someone who really enjoys web dev and dislikes iOS dev.
+1
The whole reusability thing is a red herring, it's like the whole Java run anywhere thing, it might save you duplicating UI code but the apps will look crap and run like a dog.
I do not agree with your reasoning.
First of all, if going native, you'll have to put in twice the effort for targeting both Android and iOS, while an HTML5 app can be easily ported to WinPhone or even Symbian.
Will it be shittier than a native app if doing a straight port with no effort to make it seem native? Most definitely YES, but at least you've got an app to give to your customers that want to use your product. Because no matter how cool the new Facebook app is on iOS, I'm still and will continue to be an Android user.
Also, I do not agree that it's easier to develop that native app in the first place. I can easily do things in HTML5 in terms of UI that I wouldn't know were to begin with native widgets. All is fine and dandy when you're using the standard widgets, but if you want to have non-standard behavior, or to put your personal touch on the design, then all hell breaks loose, because those native widgets ARE NOT as fluid, as easy to change or as composable as a bunch of divs with CSS attached. People underestimating this point have never worked on designing interfaces in both HTML5 and native widgets.
And for the record, I hate the native app because it's slower than when using the website in my browser. But the work they did also improved the mobile website, which I find to be awesome.
First of all, if going native, you'll have to put in twice the effort for targeting both Android and iOS, while an HTML5 app can be easily ported to WinPhone or even Symbian.
Will it be shittier than a native app if doing a straight port with no effort to make it seem native? Most definitely YES, but at least you've got an app to give to your customers that want to use your product. Because no matter how cool the new Facebook app is on iOS, I'm still and will continue to be an Android user.
Also, I do not agree that it's easier to develop that native app in the first place. I can easily do things in HTML5 in terms of UI that I wouldn't know were to begin with native widgets. All is fine and dandy when you're using the standard widgets, but if you want to have non-standard behavior, or to put your personal touch on the design, then all hell breaks loose, because those native widgets ARE NOT as fluid, as easy to change or as composable as a bunch of divs with CSS attached. People underestimating this point have never worked on designing interfaces in both HTML5 and native widgets.
And for the record, I hate the native app because it's slower than when using the website in my browser. But the work they did also improved the mobile website, which I find to be awesome.
The current Facebook app, if developed by
competent guys, is a 3 months project by 2 people
Joe Hewitt isn't an amateur.
No one said that. Everything post-Joe Hewitt and pre 5.0 was amateur.
They tasked amateurs who didn't know what they were doing into building a hybrid native app container which in turn embedded HTML5 content.
Am I wrong that this basic design is Hewitt's?
Am I wrong that this basic design is Hewitt's?
I can't speak for him, but I do believe that was his vision for the future. However, what he shipped (Facebook 3.0) was native. He was long off the product before the frankenstein HTML5/Native Facebook app shipped.
Gotcha. Thanks for correcting me.
You might have been right about his vision for the future of the Facebook app. I do recall a blog post by Joe in which he mentioned something like that he didn't like developing native apps for iOS anymore due to certain policies by Apple.
A relevant news item here: http://techcrunch.com/2009/11/11/joe-hewitt-developer-of-fac...
A relevant news item here: http://techcrunch.com/2009/11/11/joe-hewitt-developer-of-fac...
How can you make your HTML5 code as fast as native? Apple provides great tools to help developers optimize native apps because there are times when native needs to be tuned. Maybe HTML5 can be good enough for some apps, but if you're competing to win, I'd suggest that you offer the very best app for each platform.
Lots of fetch-stuff-from-the-network-and-show-it apps spend 99% of their time waiting on the network anyway; optimizing the last 1% isn't really worthwhile.
(Of course, this depends heavily on the app.)
(Of course, this depends heavily on the app.)
> How can you make your HTML5 code as fast as native?
https://developers.google.com/native-client/
https://developers.google.com/native-client/
Native Client apps are no more HTML5 than Flash is HTML5.
The key thing is that FB when the HTML5 route because they wanted to side-step Apple's signing process. They wanted to roll out updates on the server that downloaded to them without redistributing the app.
HTML5 webviews helped them do this, and worked on both android and iOS.
NaCL would, like java applets vs java apps, or flash, have let them do this too.
HTML5 webviews helped them do this, and worked on both android and iOS.
NaCL would, like java applets vs java apps, or flash, have let them do this too.
Where does the Instagram app use web views and/or HTML 5?
Yeah they could had focused on a mobile-first mobile site, but to be fair, if they didnt make the iso app how were they going to get a copy of your address book?
Maybe amateurs got assigned to it because it's hard right now to find HTML5 pros. And the problem is then HTML5.
Lnkedin's fancy HTML5 mobile website sits and fails at the spinner on the splash page when I view on Android. That is one of the main reasons I gave up on LinkedIn. Hat and its devolvement into a sourcer spam haven
Linkedin's android app is 85% native and only 15% HTML5 :(
the problem wasn't them betting too much on HTML5. Their problem was developing piece of shit apps that happened to use HTML5.
Yeah, MZ is not smart so it is not surprising that he would say not correct things...
Heh...
Yeah, MZ is not smart so it is not surprising that he would say not correct things...
Heh...
I don't work for Facebook. I work at a mobile company that does iOS and Android development. I work daily on our Android apps. Here is my experience:
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.
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.
Thanks you...
People think that HTML5 us the second coming. Thank you for putting it in context. Use the best tool for the job. I am tired of so much hype over HTML5 - like it's the greatest thing since sliced bread.
Zuckerberg's harsh words are a mixed blessing for HTML5. Some people will get the wrong message and just dismiss HTML5 altogether, which isn't what he said. His main point is he regrets building native apps with HTML5, and with the benefit of hindsight, he is right.
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...
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...
I agree, but feel that with Facebook's resources there was nothing stopping them from building a native application and a counterpart web application much like Twitter. Using a friend's device? Opt for the web interface. Using your own device? Native install.
These things can live in harmony, not exclusivity.
These things can live in harmony, not exclusivity.
But, the Facebook philosophy has always been, of hacking together what works today and think about other things later. HTML5 allows rapid fluid UI(as in feed based UI) development. The native app would have taken atleast 4-6 months for a barely tested app( As an Android Developer, I can vouch for that). They got the HTML5 app running in much less time. Having a lot of resources doesn't mean better quality work. More often than not, small teams are deliberately allotted such tasks to maintain homogeneity in design and code architecture. A mobile app is special type of software where the UI is very close to the other components(i.e Event Handling, Models etc.). Putting a large number of developers on it won't make it go any faster. Think of that scenario: 200 people working on a mobile app, pumping out features and testing sequentially!!How would that even work?
I think you misunderstood my point. Facebook has the resources to have a mobile and native app developed concurrently. I did not mean throwing more developers at a problem to get it completed faster.
In my opinion he was just issuing blanket statements to warm the cold reality that Facebook doesn't care about quality.
In my opinion he was just issuing blanket statements to warm the cold reality that Facebook doesn't care about quality.
the Facebook philosophy has always been, of hacking together what works today and think about other things later.
If this was really the case, why wouldn't he just say, "hey, it was just our first draft" or something similar, rather than blaming an entire technology?
If this was really the case, why wouldn't he just say, "hey, it was just our first draft" or something similar, rather than blaming an entire technology?
[deleted]
You do realize that the "standards people" are just Google, Mozilla, Microsoft, Opera, and Apple employees, right?
What you'll find amazing when you read W3C mailing lists is only a tiny minority of those people invited to participate actual work on apps that are used by end users.
What you'll find amazing when you read W3C mailing lists is only a tiny minority of those people invited to participate actual work on apps that are used by end users.
Standards people today are, almost across the board, completely detached from product people.
From the developer perspective, who wants to sit on mailing lists or participate in forums and argue about wording and syntax verbiage?
From the 'standard people' perspective, writing the code is 'the easy part', and getting all these competing interests (ie: other standards people) to agree on something is the 'hard part'.
They're both right...
From the developer perspective, who wants to sit on mailing lists or participate in forums and argue about wording and syntax verbiage?
From the 'standard people' perspective, writing the code is 'the easy part', and getting all these competing interests (ie: other standards people) to agree on something is the 'hard part'.
They're both right...
I wish standards people spent all of their time on mailing lists, things would happen faster. These are the people who write code for browsers, for the most part. We also need people who are working on websites to be in there and it seems like web devs are underrepresented.
I am a web dev and I joined the WHATWG mailing list because I want to be a part of these discussions.
OT but g+ urls suck completely.
For a company that rewards good Urls with high rankings, why didn't they even make an effort?
For a company that rewards good Urls with high rankings, why didn't they even make an effort?
The problem with apps developed in HTML5 that is not stressed enough IMHO is that the iOS API is good, while the HTML5 API to do a lot of advanced stuff is still limited. In short to develop a native application does NOT take more time than developing one in HTML5, at least for iOS devices. I can tell this first-hand as I used to advice an iOS/Android software company in the past, composed mainly of friends of mine, and in three years of projects the native approach always won: better responsiveness, more access to lower level primitives when needed, native look and feel, easy of development.
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.
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.
> develop a native application does NOT take more time than developing one in HTML5
Unless you already have an HTML5 desktop app. In which case, the only thing you're doing is modifying the UI for touch-based input and a smaller screen ... which doesn't take much time at all.
Facebook's problem was that their app sucked. It didn't suck because it was HTML5. It sucked because it was done poorly.
Unless you already have an HTML5 desktop app. In which case, the only thing you're doing is modifying the UI for touch-based input and a smaller screen ... which doesn't take much time at all.
Facebook's problem was that their app sucked. It didn't suck because it was HTML5. It sucked because it was done poorly.
For an HTML5 desktop app to become a good HTML5 mobile app usually the changes are so big that you end anyway with a different set of code generating the output for the two "sides".
It does not matter that's HTML+CSS+JS both sides, the device, the interaction, the screen real estate, and the user behaviour when seeing this content in mobility is different.
Actually the risk is that trying to make an HTML5 desktop app also good for mobile is that you overlook a lot of good interactions that are not natural consequences if the starting point is the desktop app.
It does not matter that's HTML+CSS+JS both sides, the device, the interaction, the screen real estate, and the user behaviour when seeing this content in mobility is different.
Actually the risk is that trying to make an HTML5 desktop app also good for mobile is that you overlook a lot of good interactions that are not natural consequences if the starting point is the desktop app.
> For an HTML5 desktop app to become a good HTML5 mobile app usually the changes are so big that you end anyway with a different set of code generating the output for the two "sides".
I'm actually working on this right now.
HTML and CSS served to both desktop and mobile are identical. HTML is just headers and an empty body tag. CSS has shared code and @media specific to each interface.
Every visual element is built through JavaScript/DOM.
Javascript is split into two sections/folders. Logic and visual. Mobile and Desktop share the logic javascript, but not the visual.
Everything you can do on the desktop, you can do on mobile. The only differences are in how the visual elements are presented.
I'm actually working on this right now.
HTML and CSS served to both desktop and mobile are identical. HTML is just headers and an empty body tag. CSS has shared code and @media specific to each interface.
Every visual element is built through JavaScript/DOM.
Javascript is split into two sections/folders. Logic and visual. Mobile and Desktop share the logic javascript, but not the visual.
Everything you can do on the desktop, you can do on mobile. The only differences are in how the visual elements are presented.
I'm actually working on this right now.
Having been down this path before, I predict you will find that the "last 10%" of those small, annoying things that don't quite work like native mobile apps in HTML5 will take the same amount of time to fix as developing the rest of the app.
If you don't think this is the case then either you aren't far enough along to hit the problems or your app doesn't make heavy use of hardware (which - given that it is also a desktop app - it sounds like it probably doesn't). In the second case then using HTML5 makes good sense.
Having been down this path before, I predict you will find that the "last 10%" of those small, annoying things that don't quite work like native mobile apps in HTML5 will take the same amount of time to fix as developing the rest of the app.
If you don't think this is the case then either you aren't far enough along to hit the problems or your app doesn't make heavy use of hardware (which - given that it is also a desktop app - it sounds like it probably doesn't). In the second case then using HTML5 makes good sense.
> your app doesn't make heavy use of hardware
Bingo. Would be surprised if it lagged on hardware from 10 years ago.
Bingo. Would be surprised if it lagged on hardware from 10 years ago.
That, however, is not taking a large pre-existing desktop site and converting it to mobile.
> The only differences are in how the visual elements are
> presented.
IMHO is that the iOS API is good, while the HTML5 API to do a lot of advanced stuff is still limited.
Can you give a few examples? HTML5, CSS and JavaScript support many features on mobile devices these days: geolocation, access to camera/microphone, orientation detection...
In short to develop a native application does NOT take more time than developing one in HTML5, at least for iOS devices.
But then if you want to support Android, you need another native app. And then another one again if you want to support, say, the new Windows phones. In contrast, a web app that is mobile friendly can be reasonably portable across platforms with a single codebase.
Moreover, even if you can develop your app within the same time frame, you still have the App Store approvals process to pass, and you have Apple cutting significantly into your revenues if you're charging.
Obviously these arguments probably don't apply to Facebook, but you said you were talking about a small startup, where everything above is definitely relevant.
Can you give a few examples? HTML5, CSS and JavaScript support many features on mobile devices these days: geolocation, access to camera/microphone, orientation detection...
In short to develop a native application does NOT take more time than developing one in HTML5, at least for iOS devices.
But then if you want to support Android, you need another native app. And then another one again if you want to support, say, the new Windows phones. In contrast, a web app that is mobile friendly can be reasonably portable across platforms with a single codebase.
Moreover, even if you can develop your app within the same time frame, you still have the App Store approvals process to pass, and you have Apple cutting significantly into your revenues if you're charging.
Obviously these arguments probably don't apply to Facebook, but you said you were talking about a small startup, where everything above is definitely relevant.
That's what I saw observing the guys at Kiurma in the latest three years:
1) Most stuff is developed for Android and iOS, and all the rest is served via a CSS that is made mobile-friendly. So developing a native app for iOS + Android you cover 95% of the important target in the best way, and all the rest can stil access your services. So actually, for now, it's just two platforms and not N at least.
2) If you do the iOS application first, instead of trying to make the Android/iOS in parallel, then the Android app takes like 30% of the time of the first at max. You end just copying the iOS app just "translating it" into Java+Android SDK, so the time, in my experience is not 100% + 100%.
3) Anyway once you want to create a native look & feel in different devices, and want to make sure that the javascript, interaction, ..., all look the same across devices, even HTML5 is not exactly cut & paste.
4) It's true that apple takes 30%, but the possibilities of customers just hitting "purchase" button with a 0.99$ price tag or alike are a lot bigger compared to creating your way of making them paying. So IMHO the 30% cut often is justified by the advantages in the "processing" of the payment and in a raise in percentage of people motivated to buy because it's simply easier for them.
5) It's true that you can do stuff like playing videos, capturing images, or audio, or location. But trust me, if you try to do Instagram using this API the result is NOT the same. Doing stuff in HTML5 is often too slow, or you have too little control about how stuff is presented (see HTML5 playing of videos on iOS), or you can't use gestures well enough, or stuff are not working ok on Android or vice versa. Tons of problems.
6) A big pro of native is background. The iOS / Android location service that can awake your app when there is a significant change of position is extremely useful in a lot of social-alike apps.
So even with the small startup IMHO the quality you end with, responsiveness, and often also easy of development, more than justify to go native for everything but the most "just show some content" of the apps.
But after all, even Facebook should classify as a "most show a feed of stuff" app, that is one of the naturally prone to work in a decent way with HTML5, but still...
1) Most stuff is developed for Android and iOS, and all the rest is served via a CSS that is made mobile-friendly. So developing a native app for iOS + Android you cover 95% of the important target in the best way, and all the rest can stil access your services. So actually, for now, it's just two platforms and not N at least.
2) If you do the iOS application first, instead of trying to make the Android/iOS in parallel, then the Android app takes like 30% of the time of the first at max. You end just copying the iOS app just "translating it" into Java+Android SDK, so the time, in my experience is not 100% + 100%.
3) Anyway once you want to create a native look & feel in different devices, and want to make sure that the javascript, interaction, ..., all look the same across devices, even HTML5 is not exactly cut & paste.
4) It's true that apple takes 30%, but the possibilities of customers just hitting "purchase" button with a 0.99$ price tag or alike are a lot bigger compared to creating your way of making them paying. So IMHO the 30% cut often is justified by the advantages in the "processing" of the payment and in a raise in percentage of people motivated to buy because it's simply easier for them.
5) It's true that you can do stuff like playing videos, capturing images, or audio, or location. But trust me, if you try to do Instagram using this API the result is NOT the same. Doing stuff in HTML5 is often too slow, or you have too little control about how stuff is presented (see HTML5 playing of videos on iOS), or you can't use gestures well enough, or stuff are not working ok on Android or vice versa. Tons of problems.
6) A big pro of native is background. The iOS / Android location service that can awake your app when there is a significant change of position is extremely useful in a lot of social-alike apps.
So even with the small startup IMHO the quality you end with, responsiveness, and often also easy of development, more than justify to go native for everything but the most "just show some content" of the apps.
But after all, even Facebook should classify as a "most show a feed of stuff" app, that is one of the naturally prone to work in a decent way with HTML5, but still...
I suspect history will show their three biggest mistakes to be:
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.
[1] http://www.bbc.co.uk/news/business-19565937
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.
[1] http://www.bbc.co.uk/news/business-19565937
> 1. Allowing an IPO that was vastly overpriced.
As others have pointed out, that's a feature not a bug. They raised a ton of money for not much equity, which is the best case result for an IPO from the company standpoint. Not so much for the suckers who bought.
> 2. Keeping Zuckerberg in the CEO role for too long.
As a consequence of #1, Zuck did not give up control. He can stay there until the equity is worth $0.00/share.
The only consequence of #1 and #2 is that he pissed in the pool for all those that follow, because the suckers have been bled dry. And when you think about it, that means IPO is not as much of a possibility for all the future acquisition targets for FB. Total win for the company.
As others have pointed out, that's a feature not a bug. They raised a ton of money for not much equity, which is the best case result for an IPO from the company standpoint. Not so much for the suckers who bought.
> 2. Keeping Zuckerberg in the CEO role for too long.
As a consequence of #1, Zuck did not give up control. He can stay there until the equity is worth $0.00/share.
The only consequence of #1 and #2 is that he pissed in the pool for all those that follow, because the suckers have been bled dry. And when you think about it, that means IPO is not as much of a possibility for all the future acquisition targets for FB. Total win for the company.
I disagree pretty strongly on all three points.
The post-IPO share price decline is bad but I have not seen much, if any, evidence that it has hindered the ability to hire and retain employees. In fact, an easy case can be made that the smaller valuation creates much more upside for the RSUs that Facebook issues.
Mark is one of the premier CEOs of his generation. Removing him would be completely insane. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.
Facebook is extremely customer-focused and I don't think the privacy dust-ups suggest strongly otherwise. It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case.
The post-IPO share price decline is bad but I have not seen much, if any, evidence that it has hindered the ability to hire and retain employees. In fact, an easy case can be made that the smaller valuation creates much more upside for the RSUs that Facebook issues.
Mark is one of the premier CEOs of his generation. Removing him would be completely insane. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.
Facebook is extremely customer-focused and I don't think the privacy dust-ups suggest strongly otherwise. It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case.
> Mark is one of the premier CEOs of his generation. Removing him would be completely insane. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.
There aren't many CEOs in his generation (of large companies) so that's not a great comparison. Facebook is also a $40B company, it has dropped like a rock since the shares became liquid. How much lower before his leadership is questioned? With the lack of growth and low profits I could easily see another $10-15B dropping off in short order.
There aren't many CEOs in his generation (of large companies) so that's not a great comparison. Facebook is also a $40B company, it has dropped like a rock since the shares became liquid. How much lower before his leadership is questioned? With the lack of growth and low profits I could easily see another $10-15B dropping off in short order.
The post-IPO share price decline is bad but I have not seen much, if any, evidence that it has hindered the ability to hire and retain employees.
Please note that those three points were my projections for how history will look back on the company. I'm not claiming there is some mountain of robust scientific evidence to support my position right now.
Having said that, anecdotes predict the real data surprisingly often, and there doesn't seem to be any shortage of Facebook people who aren't impressed at half of the money they thought they had to fund their big house purchases disappearing before they could do anything about it. And of course, it's still relatively soon after the IPO, and a lot of the funds are only starting to become available around now. You wouldn't expect a mass exodus when a lot of money was still locked up.
As for recruiting new people, again I don't suppose Facebook are about to disclose hard data that makes them look bad, but where has the buzz gone? Pre-IPO, everyone and his brother seemed to want in, presumably in part because of the potential for a huge pay-off that everyone expected Real Soon Now. Without that incentive, and with plenty of other new businesses competing in the market that don't have Facebook's baggage, I find it hard to believe that they are still attracting the same quantity and quality of applicants as they did say 2-3 years ago.
Mark is one of the premier CEOs of his generation. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.
Is he, really? Or was he just in the right place at the right time, and if it hadn't been him and Facebook, it would have been someone else and their start-up instead?
As for being a $60B company, I think you're a little out-of-date. They're down to just over $40B already. In any case, I'm more inclined to judge big tech companies by how much money they actually make and not some random number the markets generate and label "market cap". And as of the first earnings call since going public, Facebook were actually making a loss.
Obviously that wasn't a typical earnings period because of the various stock-related factors, but they're taking roughly $1B per quarter in revenues, and making around $300M per quarter of profit after adjusting for the one-offs[1]. At that rate, to justify their current $40B valuation, they would need to sustain that level of profitability for over 30 years, or increase profitability through growth.
But where will this growth come from? By Zuckerberg's own admission, the market is increasingly moving to mobile for their social networking; that limits the opportunities to show as many ads. Their growth in user numbers has slowed to a crawl, because there are only so many people in the world to sign up and some of the ones who did sign up are going to get bored and do something else. And the return on investment for on-line advertising is falling over time, a pattern which has been evident for quite a while now, which is a third threat to a business model like Facebook's.
In short, I don't think Facebook are anything like a $60B company. If you do, I assume you're investing heavily at this point, since you'll surely see a 50% ROI?
It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case.
Perhaps not. But usually it is, particularly in entertainment industries, and particularly in fast-moving tech industries. Ten years ago, Microsoft were riding high after the release of Windows XP, Apple were a has-been, a couple of guys had started a little company called Google that was attracting a bit of attention as an alternative search engine, and Facebook wouldn't even exist for several years.
[1] http://www.nytimes.com/2012/07/27/technology/facebook-report...
Please note that those three points were my projections for how history will look back on the company. I'm not claiming there is some mountain of robust scientific evidence to support my position right now.
Having said that, anecdotes predict the real data surprisingly often, and there doesn't seem to be any shortage of Facebook people who aren't impressed at half of the money they thought they had to fund their big house purchases disappearing before they could do anything about it. And of course, it's still relatively soon after the IPO, and a lot of the funds are only starting to become available around now. You wouldn't expect a mass exodus when a lot of money was still locked up.
As for recruiting new people, again I don't suppose Facebook are about to disclose hard data that makes them look bad, but where has the buzz gone? Pre-IPO, everyone and his brother seemed to want in, presumably in part because of the potential for a huge pay-off that everyone expected Real Soon Now. Without that incentive, and with plenty of other new businesses competing in the market that don't have Facebook's baggage, I find it hard to believe that they are still attracting the same quantity and quality of applicants as they did say 2-3 years ago.
Mark is one of the premier CEOs of his generation. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.
Is he, really? Or was he just in the right place at the right time, and if it hadn't been him and Facebook, it would have been someone else and their start-up instead?
As for being a $60B company, I think you're a little out-of-date. They're down to just over $40B already. In any case, I'm more inclined to judge big tech companies by how much money they actually make and not some random number the markets generate and label "market cap". And as of the first earnings call since going public, Facebook were actually making a loss.
Obviously that wasn't a typical earnings period because of the various stock-related factors, but they're taking roughly $1B per quarter in revenues, and making around $300M per quarter of profit after adjusting for the one-offs[1]. At that rate, to justify their current $40B valuation, they would need to sustain that level of profitability for over 30 years, or increase profitability through growth.
But where will this growth come from? By Zuckerberg's own admission, the market is increasingly moving to mobile for their social networking; that limits the opportunities to show as many ads. Their growth in user numbers has slowed to a crawl, because there are only so many people in the world to sign up and some of the ones who did sign up are going to get bored and do something else. And the return on investment for on-line advertising is falling over time, a pattern which has been evident for quite a while now, which is a third threat to a business model like Facebook's.
In short, I don't think Facebook are anything like a $60B company. If you do, I assume you're investing heavily at this point, since you'll surely see a 50% ROI?
It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case.
Perhaps not. But usually it is, particularly in entertainment industries, and particularly in fast-moving tech industries. Ten years ago, Microsoft were riding high after the release of Windows XP, Apple were a has-been, a couple of guys had started a little company called Google that was attracting a bit of attention as an alternative search engine, and Facebook wouldn't even exist for several years.
[1] http://www.nytimes.com/2012/07/27/technology/facebook-report...
Your using the wrong FB share count. Despite what some sites report, the correct number is 2.74 billion which means $57 billion at current price.
I don't think it matters. By the argument I gave in my last post, they probably aren't worth anything like $40B. If the market cap figures everyone's quoting don't take some of the shares into account and the real number would be $57B, that just makes the valuation even more implausible.
Your incorrect corrections were rather matter-of-fact. And we are discussing the notion of Mark continuing as the CEO, not the plausibility of the company's current market value.
To be fair, I still can't find a single source to back up your higher figure, while I can find dozens with a quick Google search that quote a market cap of around the $40B that I and at least one other poster who replied to you were using. If you want the $60B you stated to mean something other than the most common valuation (market cap), you could clarify what exactly you're talking about instead, or the figure doesn't really further the discussion.
In any case, it still doesn't matter. Your argument for Zuckerberg's effectiveness is that he has built a very valuable company. Part of my argument is that it's funny money and the company isn't really that valuable at all. Whether we're thinking of the same kind of "funny money" doesn't make any difference to this argument.
In any case, it still doesn't matter. Your argument for Zuckerberg's effectiveness is that he has built a very valuable company. Part of my argument is that it's funny money and the company isn't really that valuable at all. Whether we're thinking of the same kind of "funny money" doesn't make any difference to this argument.
[i]He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.[/i]
Two things:
Q) Wasn't this $100 billion not so long ago? A) Yes, and if things progress, it'll be $2 billion in six months.[1]
Q) Who provided MZ with the finance, the clout and the film, not to mention a whole lot of other perks? A) The people who really made Facebook what it is.
Anyone who thinks that the Facebook saga is one lone libertarian hero proving Capitalism need to... re-evaluate their maturity levels.
[1] Please note the # of total shares about to hit the market.
Two things:
Q) Wasn't this $100 billion not so long ago? A) Yes, and if things progress, it'll be $2 billion in six months.[1]
Q) Who provided MZ with the finance, the clout and the film, not to mention a whole lot of other perks? A) The people who really made Facebook what it is.
Anyone who thinks that the Facebook saga is one lone libertarian hero proving Capitalism need to... re-evaluate their maturity levels.
[1] Please note the # of total shares about to hit the market.
It would be remarkable if a company with $10bn in cash and short-term investments had a market cap of $2bn.
http://www.google.com/finance?q=NASDAQ%3AFB&fstype=ii...
http://www.google.com/finance?q=NASDAQ%3AFB&fstype=ii...
I was (snarkily) suggesting something through hyperbole, but of course you're correct. However:
In short, I can't logically see how the extra 50% swimming free will raise their share price. But then again, that's why I'm not paid the big bucks to work at JP & the Street, there's no doubt some plan afoot.
August 15th, 2012: 268 million shares, 10% of shares outstanding.
October 14th: 249 million shares, 9% of shares outstanding.
<b>November 13th: 1.332 billion shares, 49% of shares outstanding.</b>
December 13th: 124 million shares, 5% of shares outstanding.
May 17th, 2013: 47 million shares, 2% of shares outstanding.
In short, I can't logically see how the extra 50% swimming free will raise their share price. But then again, that's why I'm not paid the big bucks to work at JP & the Street, there's no doubt some plan afoot.
Facebook has made a ton of mistakes, HTML5 does not rank anywhere near the top (it wasn't even the cause of their problems, there are plenty of well done HTML5 apps). Their app sucked, but was incredibly popular. Their new app sucks less and is still incredibly popular.
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.
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.
What I find most interesting here is how so much in depth analysis is coming out of one, simple statement with a very obvious meaning. You know how people used to try to analyze the life out of Beatles songs looking for all kinds of hidden meaning, until one day Paul McCartney straight up said, "There is no meaning other than what's on the surface level."? I'm getting that same vibe here.
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.
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.
It's not a surprise that a web software company would want web software to run and win everywhere, it's the same reason c++ devs want to write web apps in c++ even if that might be a terrible idea. In the end, the lesson is clear, you get what you optimize for. FB optimized for letting their web devs ship mobile code fast, and they were able to do that. The caveat is that the product they shipped wasn't that good.
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.
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.
Browser vendors are trying to do too much. Innovation needs to move from top-down to bottom-up. Browser vendors need to provide just basic access to bare metal and let OSS do the rest.
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.
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.
That sounds like a horrible mess. Presenting users with "Would you like to give this site access to UDP?" is not a question most users can answer to any level of competency. Developers dream, users nightmare.
WebGL has been a good example of the difficulties you face when offering low level access- buggy graphics drivers could result in an all-out crash.
WebGL has been a good example of the difficulties you face when offering low level access- buggy graphics drivers could result in an all-out crash.
Your proposed solution and criticism thereof presume that there is only one way to delegate trust to a web app and that it should entail that the user understand UDP.
Consider Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
And Alan Kay: http://www.drdobbs.com/architecture-and-design/interview-wit...
Consider Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
And Alan Kay: http://www.drdobbs.com/architecture-and-design/interview-wit...
Is it a case of HTML5 is a future disruptor, providing platforms don't try to subdue it in preference to Native? A good example is in mobile tech where a lot of apps that used data pre 3G performed poorly because the underlying technological dependencies (the data pipes, memory limitations and processing power) were not ready. Secondarily, the business models were not ready either (pay per MB).
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)
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)
The iOS app is still crap compared to the web experience. Users can't edit, or even delete, their own comments. The length of time for likes and comments to appear is unpredictable. Sometimes very quickly, sometimes users don't see their own comments for half a minute. Art is displayed oddly. It's almost always clipped at top and bottom on the page, requiring an extra step to actually see it. They seem to be under the mistaken impression that mobile users are like Twitter users, firing shots into the darkness, instead of curled up on their couches with iPads, composing little essays and looking at family photos.
Don't forget copy and paste.
This is all very interesting, but I do think the concentration on HTML5 is something of a foil. Strategically, I was under the impression that Facebook was positioning itself to be a third independant force, alongside Apple and Google. Considering the state of play when facebook started up in 2006, when users flooded into the browser venue, and where the iPhone hadn't yet been released, and where the idea of socially contextualless search and data could be leveraged and superseded by the Facebook social graph, I consider the decisions made with facebooks mobile strategy to be explicable.
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.
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 am sorry to see any negative publicity for HTML5 adoption but I understand that FB is a special case. Saving money on mobile development is not a priority for them.
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.
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.
I don't think they're saving money by making an HTML5 version. A slow app means less engaged users who are less likely to see or click on ads. At facebook's scale, that's potentially tens to hundreds of millions of dollars lost on the iPhone per year while it probably only costs a couple million to fund 5 engineers to make a decent native iOS app.
After some experience with html5 and javascript programming, I feel it is more and more like hacks, forcing natural application models into html5 with lots of hacks. Sure, there are applications fitting html5 well, but for many more others, I begins to doubt that html5 is a real good solution for future.
What is the common understanding when people deliberately tack on 5 at the end of HTML? I don't remember people talking about HTML 4 like that.
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.
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.
i hope this doesn't mean they will be forcing everyone into a native app. i ditched it long ago because their mobile site is quite good and 100x better for my privacy. same with yelp and youtube. gmail is good also, but i need the notifications there, so no choice but native.
Did nobody listen to the interview? He said that most mobile users use the mobile web interface (i.e. it is not going anywhere).
Weren't the issues with their use of HTML5 more related to the lack of proper asset caching (CSS/JS), not so much the performance of the rendering and code execution?
When I used their app at the time, I always found myself waiting for the CSS for each view to load.
When I used their app at the time, I always found myself waiting for the CSS for each view to load.
What Mark Zuckerberg really said:
“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-...
“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-...
Slightly offtopic, but this is what I hate about tech reporting: http://i.imgur.com/TYyKD.png
There is an article for every statement that zuck made onstage. Getting pageviews is a priority, I guess.
There is an article for every statement that zuck made onstage. Getting pageviews is a priority, I guess.
The main problem with native development is how you are not as flexible as your HTML counterpart. Even with the massive amount of capital that Facebook has, a full native app would always be behind.
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.
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.
Why isn't it as flexible? And a native app on a mobile device shouldn't try and replicate a full blown web app, it should have only the appropriate features that you would use on the go, but it should do these well and be snappy (read native).
Maybe for you, but the general public expect the same feature set. They can be presented in a different matter, but in the end they need to match. Look at the comment here, some people are complaining about lack of feature on the current app.
It occurs to me that if someone came out with a new technology and said "hey, you can now describe your entire interface's structure in one markup language, the visual look in a second language, and the code in a third language, and then your app will run anywhere that has the required runtime interpreter" they'd be shouted down faster than you can say "go Swing".
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?
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?
Guess what he's actually saying is that if you want to created "walled gardens" and locking-in users HTML5 is not the way.
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.
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'd say their biggest mistake is filtering the news feed by presumed interest. I talk to normal person after normal person who finds facebook increasingly more useless because this algorithm does not work correctly.
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 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.
Instead it's sometimes better to build an app on top of its native environment from the early days rather than spending enormous time to figure out the best workaround for life. You might choose the tool you're most comfortable with to build everything, at the same time just never ignore the quality that the users will experience.
A bad mechanic will always blame his tools. A saying the Facebook development team should print out, frame and hang in their building for all to see. Maybe Facebook should have asked the LinkedIn development team to build their app for them because they obviously know nothing about web development.
I've got both iPhone and android phone, and I always noticed strange scrolling and slow response on the iphone when using the html facebook app.
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?
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?
Ditching the HTML5 app was a good call but _please_ fix the atrocious way the new app mangles images with the resizing/stretching. It really kills the speed of the overall experience when I have to enlarge every image to have any clue what its a picture of.
This was just a strategy for Mark to downplay Facebook's troubles. Avoiding talking about Facebook's other problems by pushing HTML5 as their biggest mistake and saying how it's now fixed. This gives them more time and calms investors down.
For those interested, here is the specific quote on video from Techcrunch's live : http://www.youtube.com/watch?v=GBp_xCGIATk
That is facebook's biggest mistake?
Is he blind or just wilfully ignorant?
Is he blind or just wilfully ignorant?
[deleted]
Finally someone gets it.
Applications should be done natively.
HTML is for documents.
Applications should be done natively.
HTML is for documents.
Sure, blame it on HTML5, the voiceless culprit. Blame it on the janitor, the office assistant, the programmer.
But never dare you touch a C*O for the failure of a corporation!
But never dare you touch a C*O for the failure of a corporation!
This is absolute nonsense.
Here's an example of what a small team + HTML5 is capable of: http://ro.me
Here's an example of what a small team + HTML5 is capable of: http://ro.me
I find it amusing that everyone tries to "interpret" what Zuckerberg is saying. It is in pretty clear 3rd grade English folks. Don't try to spin things too much. Of course there are always agendas, do you think that Steve Jobs didn't have agendas? I did not hear much reinterpretation of his statements in his latter years...
I'm already seeing weird conclusions drawn from this. Anyone can tell you, the mobile web app for Facebook worked. Well. It was very, very fast and looked nearly pixel for pixel like the "native" Android app.
Thus, it seems pretty silly to act as if HTML5 is incapable.
Thus, it seems pretty silly to act as if HTML5 is incapable.
They are a bunch of PHP hackers, is it any wonder they can't write decent native apps?
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.