Full quote of what Mark Zuckerberg actually said about HTML5(blog.tobie.me)
blog.tobie.me
Full quote of what Mark Zuckerberg actually said about HTML5
http://blog.tobie.me/post/31366970040/when-im-introspective-about-the-last-few-years-i
120 comments
The context wasn't really necessary. I think we all believe HTML5 has a great future. Hardware gets better at a rapid rate and HTML5 (CSS, Javascript, etc) is still improving. The point is, and was, that it's probably best to produce native apps at this time, for the majority of apps. Facebook, for example, needs a 5 star app.
Not necessarily a majority of apps.
Facebook is a really, really popular app. They cannot get away with good effort alone. They must make their mobile app flawless and reliable, because if only a couple of users out of hundreds of millions publicly criticize their app, this hurts their reputation badly.
I do not agree with what most people are saying. HTML5, CSS, Javascript are already good enough standards for 99% of all apps.
The real problem lies with the popular mobile browsers. Anybody who ever tried developing a rich interface for Mobile Safari and for Android knows just how bad things are - and some people think having to support IExplorer 6 was painful.
Also, at least on iOS, the browser has better performance than a WebUI embedded in an app. From what I know the web component doesn't use the same Javascript engine for instance. Also, not sure if this changed, but on iOS 4 you couldn't upload files from the mobile browser (file fields in forms were deactivated). You also couldn't automatically place the focus on a form field, to force the keyboard to pop, because you couldn't trigger any mouse/keyboard event other than in response to a physical user action (I think this was a problem with mobile WebKit in general). And I also experienced many problems with Android's browser. I can't even remember all of them.
Facebook is a really, really popular app. They cannot get away with good effort alone. They must make their mobile app flawless and reliable, because if only a couple of users out of hundreds of millions publicly criticize their app, this hurts their reputation badly.
I do not agree with what most people are saying. HTML5, CSS, Javascript are already good enough standards for 99% of all apps.
The real problem lies with the popular mobile browsers. Anybody who ever tried developing a rich interface for Mobile Safari and for Android knows just how bad things are - and some people think having to support IExplorer 6 was painful.
Also, at least on iOS, the browser has better performance than a WebUI embedded in an app. From what I know the web component doesn't use the same Javascript engine for instance. Also, not sure if this changed, but on iOS 4 you couldn't upload files from the mobile browser (file fields in forms were deactivated). You also couldn't automatically place the focus on a form field, to force the keyboard to pop, because you couldn't trigger any mouse/keyboard event other than in response to a physical user action (I think this was a problem with mobile WebKit in general). And I also experienced many problems with Android's browser. I can't even remember all of them.
IMHO, HTML5 isn't the issue. It's just a convenient scapegoat to distract investors from the fact that they either lack technical prowess in mobile app development (fairly unlikely...) or simply have poor leadership, vision and direction to deal with the challenges of mobile apps. To succeed in mobile, Facebook needs their own ecosystem.
Apple, Google and Amazon are years ahead of Facebook at this point and they have a tremendous upper hand right now. I don't see how Facebook can continue their growth in the current post-PC world. They've basically peaked at this point with their facebook.com site, and for future growth my bet is that they'll start growing through acquisitions. Sounds like yahoo.com to me.
Apple, Google and Amazon are years ahead of Facebook at this point and they have a tremendous upper hand right now. I don't see how Facebook can continue their growth in the current post-PC world. They've basically peaked at this point with their facebook.com site, and for future growth my bet is that they'll start growing through acquisitions. Sounds like yahoo.com to me.
iOS6 adds file upload support for images.
What I don't get is why facebook has to be an app at all. If you build it as a purely browser-based app, you can get better performance than running it in a UIWebView, and updates can be pushed out without anyone's permission. With HTML5 app cache you can get the "instant launch" experience that a native app gives you. For interacting with the camera they could have used a helper app.
Why are people so desperate to put their free non-ad-supported apps in apple's app store? It doesn't make any sense to me. I recently built an offline web app using sencha touch, and it works great. No install necessary, just "add to homescreen".
What I don't get is why facebook has to be an app at all. If you build it as a purely browser-based app, you can get better performance than running it in a UIWebView, and updates can be pushed out without anyone's permission. With HTML5 app cache you can get the "instant launch" experience that a native app gives you. For interacting with the camera they could have used a helper app.
Why are people so desperate to put their free non-ad-supported apps in apple's app store? It doesn't make any sense to me. I recently built an offline web app using sencha touch, and it works great. No install necessary, just "add to homescreen".
Users are trained to want apps. They are not trained to add to homescreen.
Apps get notifications.
Apps get notifications.
The difference is that iOS allows Mobile Safari to turn memory areas into code pages, which is what you need to do to JIT JavaScript. It doesn't trust other apps not to be able to exploit that somehow, so UIWebView is not allowed to do this.
Are you 100% sure?
I believe webkit (either in safari or UIWebView) should be able to run JIT, while your custom engine can't.
I believe webkit (either in safari or UIWebView) should be able to run JIT, while your custom engine can't.
UIWebView doesn't support JS JIT, as it's still running in your process space.
That explains a lot of things. Thank you.
> They must make their mobile app flawless and reliable, because if only a couple of users out of hundreds of millions publicly criticize their app, this hurts their reputation badly.
Vehemently disagree. I know very few apps that are flawless and reliable, including Apple's native apps. A couple of users have already publicly criticized the app for YEARS now and it hasn't hurt their reputation to the point where they are losing users. Facebook has power because of the network effect. People are willing to deal with a flawed experience as long as the network effect is left in tact. Facebook will need to worry about a flawless app experience when the network effect diminishes.
Vehemently disagree. I know very few apps that are flawless and reliable, including Apple's native apps. A couple of users have already publicly criticized the app for YEARS now and it hasn't hurt their reputation to the point where they are losing users. Facebook has power because of the network effect. People are willing to deal with a flawed experience as long as the network effect is left in tact. Facebook will need to worry about a flawless app experience when the network effect diminishes.
> I think we all believe HTML5 has a great future.
I don't. Absolutely not. I have a confidence HTML5 will fail in the end.
> Hardware gets better at a rapid rate
Moore's Law is about to over. We have no free lunch anymore. The next Intel CPU (Haswell) gets only 10% performance improvement at the same clock.
And don't you hear our consumers complaining the battery life and the heat problem of their mobile devices? Things become worse on the coming wearable computers.
I can't understand why HTML/CSS/JavaScript advocates are so optimistic about this point. And looks like people completely forgot the buzzword of a decade ago, "green computing".
My simple question is, "Are you really a SOFTWARE engineer?" HARDWARE engineers will solve the problem. Hah!
> HTML5 (CSS, Javascript, etc) is still improving.
Yeah, at a deadly slow speed. There are many critical bugs which has been stuck for several years. I'm tired to wait them fixed. Apparently web standards became too complex and about to collapse. Many programmers completely forgot the KISS principle. Very sad.
I don't. Absolutely not. I have a confidence HTML5 will fail in the end.
> Hardware gets better at a rapid rate
Moore's Law is about to over. We have no free lunch anymore. The next Intel CPU (Haswell) gets only 10% performance improvement at the same clock.
And don't you hear our consumers complaining the battery life and the heat problem of their mobile devices? Things become worse on the coming wearable computers.
I can't understand why HTML/CSS/JavaScript advocates are so optimistic about this point. And looks like people completely forgot the buzzword of a decade ago, "green computing".
My simple question is, "Are you really a SOFTWARE engineer?" HARDWARE engineers will solve the problem. Hah!
> HTML5 (CSS, Javascript, etc) is still improving.
Yeah, at a deadly slow speed. There are many critical bugs which has been stuck for several years. I'm tired to wait them fixed. Apparently web standards became too complex and about to collapse. Many programmers completely forgot the KISS principle. Very sad.
> I have a confidence HTML5 will fail in the end.
When is the end? What will replace it in the browser? Will people stop using browsers? Why do you have confidence other than things are not perfect now?
>optimistic
Being optimistic makes people want to solve problems. Being pessimistic makes people think defeat is 100% likely so they never try to solve anything.
Our games already work very well in HTML5. They "work" on an iPad 3, but we still make native versions because the technology we use, Monkey, allows us to very painlessly do so.
On desktop, Chrome, Firefox, and IE all run the games perfectly on a now 4 year old computer build.
I'm not betting everything on HTML5 but to me it already is succeeding and I am confident that consumers will drive demand for it, vendors will produce and release devices which support it. Even if Apple, or the other big sellers don't support it there will be those who do and the great support will sell units and make anyone who doesn't support it well look bad.
When is the end? What will replace it in the browser? Will people stop using browsers? Why do you have confidence other than things are not perfect now?
>optimistic
Being optimistic makes people want to solve problems. Being pessimistic makes people think defeat is 100% likely so they never try to solve anything.
Our games already work very well in HTML5. They "work" on an iPad 3, but we still make native versions because the technology we use, Monkey, allows us to very painlessly do so.
On desktop, Chrome, Firefox, and IE all run the games perfectly on a now 4 year old computer build.
I'm not betting everything on HTML5 but to me it already is succeeding and I am confident that consumers will drive demand for it, vendors will produce and release devices which support it. Even if Apple, or the other big sellers don't support it there will be those who do and the great support will sell units and make anyone who doesn't support it well look bad.
I believe you will always be able to make html5 apps if you want. But I believe the iOS 'apps' model is going to become the standard for consumer pc's. This will cause native apps to no longer be second class citizens, and HTML based apps will have to compete with native just like they do on iOS. Right now basically all consumer computing happens through the browser, except for ms office, and it takes enormous effort to get a non-technical user to install software.
> Hardware gets better at a rapid rate and HTML5 (CSS, Javascript, etc) is still improving.
Hardware is only improving as fast the vendors see a need to. If the ARM chips in a smartphone suffice for say 90% of the games produce on a iPhone, why on earth increase it's power? We all know (hopefully by now) that the HTML5 spec chews through CPU, especially when called in parallel requests. It's not advantageous for Apple to optimize the HTML5 spec, otherwise it decreases lock-in.
Also, this is the same argument that happened in the 90's with desktop/laptops and only really has progressed now with the existence of modern browsers. The only way that this was possible was when telecommunication infrastructure was able to support always connected devices, which the late 90's and early 2000's has proven. We are almost there, but considering 3G (4G, LTE, or whatever) is still not 100% reliable, I don't see this happening anytime soon. I really think we are less "connected" (technologically speaking) than the general public gives us credit for.
Hardware is only improving as fast the vendors see a need to. If the ARM chips in a smartphone suffice for say 90% of the games produce on a iPhone, why on earth increase it's power? We all know (hopefully by now) that the HTML5 spec chews through CPU, especially when called in parallel requests. It's not advantageous for Apple to optimize the HTML5 spec, otherwise it decreases lock-in.
Also, this is the same argument that happened in the 90's with desktop/laptops and only really has progressed now with the existence of modern browsers. The only way that this was possible was when telecommunication infrastructure was able to support always connected devices, which the late 90's and early 2000's has proven. We are almost there, but considering 3G (4G, LTE, or whatever) is still not 100% reliable, I don't see this happening anytime soon. I really think we are less "connected" (technologically speaking) than the general public gives us credit for.
Also core count is increasing, but raw speed per core really isn't. Multicore really doesn't help web rendering very much. Nearly all javascript out there is single threaded and most dom rendering is too.
Raw speed per core is increasing DRAMATICALLY in mobile. Faster than even Moore's law would dictate. As the die process has shrunk, more transistors are fitting within the mobile TDP ceiling so modern processor methods are finally getting used. As recently as the ARM A8, out-of-order execution wasn't even used!
You can verify that this is correct by looking at any benchmark.
You can verify that this is correct by looking at any benchmark.
> Multicore really doesn't help web rendering very much.
There are people working on changing that, for what it's worth.
There are people working on changing that, for what it's worth.
Indeed. Blossom[0], a mobile MVC client framework for business apps, is being updated as we speak to split apps into a UI/animation thread, with the application/model layer/network in a web Worker on a separate thread.
Disclaimer: I wrote Blossom.
[0] https://github.com/erichocean/blossom
Disclaimer: I wrote Blossom.
[0] https://github.com/erichocean/blossom
There is also work from the other side, to make the browser engines take more advantage of parallelism. That's more what I was referring to.
Blossom sounds pretty neat!
Blossom sounds pretty neat!
Why are people downvoting this?
> Nearly all javascript out there is single threaded and most dom rendering is too.
http://en.wikipedia.org/wiki/Web_worker
http://en.wikipedia.org/wiki/Web_worker
That's really not a rebuttal. Yes, lots of browsers now support web workers. Yes, it is therefore possible to write multithreaded javascript. And that may become more common over time. But for now, the fact that it's possible does not change the fact that nearly all javascript is still single threaded.
IE10's chakra engine parallelizes interpreted javascript execution (on page load) with JIT compilation and garbage collection. So you can have up to three cores at work executing javascript even without web workers. Meanwhile, the rendering subsystem offloads to the GPU, and the whole thing can exist multiple times for multiple tabs, potentially involving dozens of cores executing your web apps.
http://blogs.msdn.com/b/ie/archive/2012/06/13/advances-in-ja...
http://blogs.msdn.com/b/ie/archive/2012/06/13/advances-in-ja...
Of course all of this is useless in the context of mobile web views because Android dropped web workers and IOS just picked them up.
I'd say it depends more on app type than on HTML5 progress.
For apps what are little more than glorified content viewers HTML is promising, for others — not so much. HTML5 brings some sanity and improvements, but at the roots it is still same old and lame HTML. You may spin and twist it, but at the end the question is "was it worth is". And the answer, most often than not is "hardly". Improving hardware won't change that, at least not substantially.
I think it adds the clarity that they don't think HTML5 is actually bad, but rather that it's still not ready for prime time (for them!)
The many other quotes I've read around the web don't mention this, giving more of a "HTML5 sucks" hint to the quote.
Even when HTML5 will be ready for prime time it could never compare to a native app. This isn't a new issue, cross-platform solutions have been around for ages and they always fell short.
Fell short in what way? Yahoo Mail came out in 1997 and people flocked to use it. You can guess what the UI was like for Yahoo Mail in 1997. But UX isn't only about UI. Being able to shop for a new computer or phone and knowing the stuff I use will continue to work is great UX as well. There are always tradeoffs. I'm tired of the anti-web brigade acting like web development is only good for the developer.
Once upon a time I worked at a company where we developed in a platform called Clipper. We used a cross-compiler to port apps from a PC to an HP-UX system. Although Clipper was based on C and the cross-compiler created C code it was never as optimized as it could be if written from scratch-actually it wasn't even close. In the years since I've heard numerous stories of similar situations. The one size fits all, which was best materialized by Java, never lived up to its name.
You say HTML5 could deliver a unified UX. I disagree. If the problem is the need for unified visual environments then HTML5 is the wrong answer to this problem - CSS is more close to the answer. HTML5 was supposed to be that kick-ass solution for delivering a more robust development platform for the web that could reduce the need for third-party plugins like Flash or Silverlight.
I won't argue that what HTML5 has achieved is no small step. But I wouldn't have high hopes of it ever manage to compare head-to-head with a native app, no matter how mature it would become-and that last part takes a lot of argument since evolution of HTML takes ages.
You say HTML5 could deliver a unified UX. I disagree. If the problem is the need for unified visual environments then HTML5 is the wrong answer to this problem - CSS is more close to the answer. HTML5 was supposed to be that kick-ass solution for delivering a more robust development platform for the web that could reduce the need for third-party plugins like Flash or Silverlight.
I won't argue that what HTML5 has achieved is no small step. But I wouldn't have high hopes of it ever manage to compare head-to-head with a native app, no matter how mature it would become-and that last part takes a lot of argument since evolution of HTML takes ages.
> You say HTML5 could deliver a unified UX. I disagree.
Me too, I never said that. I said that, using Yahoo Mail as an example, users are willing to sacrifice some integrational purity when ease-of-use and portability are so compelling. Today that balance hasn't been tipped on mobile. I'm willing to bet it will be, eventually.
Me too, I never said that. I said that, using Yahoo Mail as an example, users are willing to sacrifice some integrational purity when ease-of-use and portability are so compelling. Today that balance hasn't been tipped on mobile. I'm willing to bet it will be, eventually.
"HTML5" includes CSS, javascript and the actual HTML markup along with a myriad of other things.
Sure, if you're comparing like-for-like experience and performance. But HTML5 provides advantages with rapid development, cross platform, distribution etc. over native apps. The debate is whether these advantages are enough to sacrifice the quality of experience and performance provided by a native app (or rather, whether the gap is sufficiently small enough to justify going for HTML5). Zuckerburg's opinion appears to be... yes, but not quite yet.
Without context this partial quote makes deceptive buzz in general media and that's gonna hurt many people and businesses.
> Facebook, for example, needs a 5 star app.
Could you explain why?
Could you explain why?
Facebook relies on people using their service all the time, when they want. They want it to simply work. That's why they have this obsession about 24/7/365.25 uptime on their servers. It means also no friction when people use Facebook on their mobile, thus a 5 star app.
If you're being that precise the calendar actually has an average of 365.2425 days per year and not 365.25. In fact that was the major motivation for switching from the Julian Calendar a full 430 years ago.
http://en.wikipedia.org/wiki/Gregorian_calendar
http://en.wikipedia.org/wiki/Gregorian_calendar
Or, if you're being really precise, you'd say 24/7/52... </pedantry>
I was expecting this kind of comments if I had only written 365 days a year, thought I was covered, apparently not.
I was just kind of surprised to see the .25. If you had put just 365 I'd have read that as "a year" and not give it a second thought. Instead it got me thinking if it actually rounded out to .25 or not so I went and checked. Apparently that wasn't too appreciated... :) No offense intended.
I think the pedantry was invited by the attempt at specifics. C'est la vie.
They have cemented their position. They can, at this stage, suffer down time without too much concern (hell, even twitter was down recently)
Agreed, in fact it's ironic that they try sooo hard to have 100% uptime, as a small amount of downtime, can be a good thing.
No-one cares if vital utility x is working. It's not like they are texting their friends, about x being 'up'.
But if you take away x, often it highlights just how important it was, and it becomes relevant to them.
It reminds them just how much x, means to them.
Then, if x reacts to the adversity in a crowd pleasing way... instant karma and mindshare.
cf. new coke as well.
(speaking from experience in the hosting industry)
No-one cares if vital utility x is working. It's not like they are texting their friends, about x being 'up'.
But if you take away x, often it highlights just how important it was, and it becomes relevant to them.
It reminds them just how much x, means to them.
Then, if x reacts to the adversity in a crowd pleasing way... instant karma and mindshare.
cf. new coke as well.
(speaking from experience in the hosting industry)
I hypothesise user engagement would suffer in the face of down time. This, plus the added scrutiny this technical failure would place on their stock, means now is not a time when they can be careless about reliability.
I disagree. There is so many social websites out there that you need your users to think you are the only option, If your service is down, people will have a look at others', and might them interesting.
Probably the main reason that they have so much traffic going to the mobile website (aside from international audiences with dumbphones) is that the app sucks. My colleagues use the webapp on their androids because they hate the native app.
Interestingly, once html5 becomes fully ubiquitous, Facebook will probably already be sliding no matter how well it's native apps run. Will be a non-issue in the end.
"One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook..."
this is testament to just how bad the app was.
this is testament to just how bad the app was.
Not only that. I use the mobile interface rather than the app for two reasons: Sure, the app is badly done and buggy, but, most importantly, it gives Facebook permissions that they've shown time and again they shouldn't have. They've fucked up on more than one occasion, and I know casual users who balk at installing applications that request too many permissions.
That's definitely a contributing factor, in my opinion.
That's definitely a contributing factor, in my opinion.
I haven't used iOS in a while, but a couple of years ago the web app was faster (!) and had more features (like liking on comments, not just on status updates) than the native app (presumably because the browser used a JIT for JavaScript and apps an interpreter). I would use the web app for everything except uploading pictures.
While some of the audience will be because of that, I doubt the majority are. Last time I checked, Facebook's mobile site actually degrades fantastically well, all the way down to old Nokia feature phones. You can bet that in many countries that is a big deal.
Bingo. Outside of Tech Companies/Silicon Valley/Major US Metro Areas/the US as a whole, iPhones don't have that huge a market share. More people have Android phones, but often running old hardware, old software, and even more have feature phones. If you're reading Hacker News, forget that you're not a typical user at your peril.
This is what I came to say as well. The native apps lacked so much functionality that you would have to go to the web app to perform certain actions.
[deleted]
"...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."
I find this part of the quote interesting. Those people who use mobile web, what platform are they using? Are they using iOS or Android based devices, and using the web? Or are they using other lower end phones?
Could this number actually decrease if Facebook linked to the apps in their emails, rather than the mobile site? (I guess this might be hard to pull off, but would be better in the long run)
I find this part of the quote interesting. Those people who use mobile web, what platform are they using? Are they using iOS or Android based devices, and using the web? Or are they using other lower end phones?
Could this number actually decrease if Facebook linked to the apps in their emails, rather than the mobile site? (I guess this might be hard to pull off, but would be better in the long run)
My girlfriend uses the mobile web version of Facebook on a semi-dumb slider phone (it might be some variant of Symbian). I find it baffling because the browser is so terrible and the screen is 320x240, but she's perfectly happy with it. She never uses it for any other sites. I wonder if Facebook has an unusually high number of users like that. The demographic would be invisible to the rest of the web community because those users never leave Facebook.
I can't speak for others but I have an iPhone and choose to only access Facebook through the mobile site. Two reasons:
1. I prefer not to allow Facebook to run a native app on my phone. Various reasons boiling down to not trusting it to act in my best interest.
2. Poor performance of the iPhone app -- I hear the new version is supposed to be better but that still doesn't solve problem 1.
1. I prefer not to allow Facebook to run a native app on my phone. Various reasons boiling down to not trusting it to act in my best interest.
2. Poor performance of the iPhone app -- I hear the new version is supposed to be better but that still doesn't solve problem 1.
Facebook created a very specific version of their site for dumbphones a while ago, I think an article I saw about it said it was targeted at places like Africa etc where mobile phone use is becoming common, but computer usage isn't. Which makes perfect sense really, there's a much larger percentage of the worlds population that use phones over computers in less developed parts of the world. They're a growth segment, no point blocking them when you can hook them now.
Edit: http://www.readwriteweb.com/archives/free_mobile_facebook_wi... there we go, Facebook Zero.
Edit: http://www.readwriteweb.com/archives/free_mobile_facebook_wi... there we go, Facebook Zero.
Zuckerberg is right. HTML5 isn't suitable for the direction Facebook is going which is photos (hence why they bought Instagram).
LocalStorage quotas cannot be made bigger than 5MB[1].
I remember trying this Mozilla-built webapp[2] out in Google Chrome, it just didn't work.
1. http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html...
2. https://hacks.mozilla.org/2010/02/an-html5-offline-image-edi...
LocalStorage quotas cannot be made bigger than 5MB[1].
I remember trying this Mozilla-built webapp[2] out in Google Chrome, it just didn't work.
1. http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html...
2. https://hacks.mozilla.org/2010/02/an-html5-offline-image-edi...
Context absolutely matters! Techcrunch sold the article as Facebook betting too much on HTML5, period. His quote was that at the time 2 years ago, it was a mistake betting too much on HTML5 over native for their mobile application. And it's true, 2 years ago and even now, most phones have a hard time handling Facebook's intensive need in HTML5. It's true, Facebook could have spent more engineering resources improving the HTML5 spec and push it forward, but anyone saying context doesn't matter is just being ignorant.
"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." That's a hint of how crappy those native facebook apps are. It's barely usable.
That was the interesting part for me, too.
I am confused that none of the other comments in this thread touch on that.
At first I thought maybe there is a third class of phone that we are omitting, where there is no option for a native app, and so the browser is used. But I don't know what mobile device that would be. Certainly not a nokia phone (though maybe oneday!)
I personally started using Safari on my iOS for gmail. The HTML5 experience is simply better than iOS native email experience.
I have the app on my phone which I use primarily for notifications and then browse touch.facebook.com to actually interact with people.
The mobile app experience is that bad.
The mobile app experience is that bad.
As a web developer, this is a great thing to hear. Larger companies should focus on the web, and with this context, I don't have to be worried anymore about learning a native phone language.
I used to work on mobile products at Google using both, HTML5 for mobile and native. When betting on HTML5 you get the benefit of quick updates across multiple platforms and smaller team size. However, most of your time is allocated towards finding work arounds for strange browser bugs. Mostly glitches in the UI. With native, things work the right way most of the time, so you can quickly create exciting new features, which excites the team. The down side of native, is that you'll be implementing that exciting new features N number of times for each platform.
Now that I am doing a lean startup, the reality is that the first app will be re-written completely. My bet is to focus short-term on one platform and write using native code for speed and lack of bugs (higher moral). For longer-term multi-platform play and if you plan to stay small and lean, I would recommend HTML5 or a hybrid.
Now that I am doing a lean startup, the reality is that the first app will be re-written completely. My bet is to focus short-term on one platform and write using native code for speed and lack of bugs (higher moral). For longer-term multi-platform play and if you plan to stay small and lean, I would recommend HTML5 or a hybrid.
I think it was mostly the design of FB's mobile web app that was bad, not that it was made in HTML5. It was too heavy and didn't optimize well to the iPhone screen size.
Context always matters. People always forget that a rush too quickly into things (kind of like Facebook and an emerging technology).
However in the case of Facebook, the error was still made.
However in the case of Facebook, the error was still made.
That's a tautology: users prefer a Web interface over sucky apps. Which says fairly little about what user might prefer when the apps don't suck.
I think HTML5 at the moment is great for making prototype mobile apps. Getting traction before investing in a native app hedges a lot of risk. The approach (native vs. web) also depends on the type of app and the customers you are trying to reach. There is a time and place for both and i think the times and places for HTML5 will only increase in the future.
I think he could have phrased it better; Did anyone else think what he said is rather redundant? I don't think context is that important, it's all in the choice of words, and the relations in the discourse. If he failed, it was with making himself clear, not on the matter of HTML5 vs Native.
Maybe everyone doesn't have a constent quotable filter on thinking "is this quotable?" :P
People talk poorly in normal conversation. It takes time to craft a good quote.
People talk poorly in normal conversation. It takes time to craft a good quote.
"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."
Yes, a lot of people used the FB mobile web app because Mobile Safari ran their web pages better than the web views of the old native FB app.
Yes, a lot of people used the FB mobile web app because Mobile Safari ran their web pages better than the web views of the old native FB app.
Stole the words right outta my keyboard. There's a reason people are going back to the web site after trying the apps.
I guess what he really meant is hybrid apps (native apps with HTML 5 rendering inside them) are not ideal..
who cares what zuckerberg said tbh, i doubt he wrote the html5 port and i doubt he was the one who convinced people to go back to native. he's just repeating what some engineer told him.
fact is html5 is slow, even more so on none apple phones/tablets. everyone who's worked with it knows it.
fact is html5 is slow, even more so on none apple phones/tablets. everyone who's worked with it knows it.
The main issue I had with the Android Facebook app wasn't that it was particularly bad in itself, it was just that it depended on a perfect, always on mobile data connection.
These things need to work on an asynchronous basis, more like email, to get status updates, post to walls etc.
These things need to work on an asynchronous basis, more like email, to get status updates, post to walls etc.
No, the context is irrelevant here because Techcrunch got it right. It's a direct quote.
All the context that is needed is said in the first sentence.
To claim this was facebook's biggest mistake is surely one of the most ridiculous things i've ever seen or heard the guy say.
edit: Mark Zuckerberg has his head up his arse :-)
To claim this was facebook's biggest mistake is surely one of the most ridiculous things i've ever seen or heard the guy say.
edit: Mark Zuckerberg has his head up his arse :-)
HTML5 makes sense for what it is meant for. Web development. It is not a desktop or mobile app replacement technology. As long as one is clear about that, everything is fine.
Part of HTML5's origin is a draft standard called Web Applications 1.0. HTML5 is meant to be a desktop and mobile app replacement technology.
http://en.wikipedia.org/wiki/HTML5#Standardization_process
http://en.wikipedia.org/wiki/HTML5#Standardization_process
Intent do not always translate to reality. HTML5 does not deliver for mobile/desktop. End of story.
Plenty of products are successfully using HTML5 for applications where it makes sense and are succeeding with it. Blanket generalizations are usually wrong.
I think you simply refuse to understand - a nail may be pinned using a pickaxe, but when you have a hammer available, which does the job neat , why would you go for the pickaxe? HTML5 is the pick axe which does the job ugly. Mobile developers have little reason to adopt it.
Ha yeah context is not needed. HTML5 is nice but betting a billion dollar business on it does not seem like a great idea.
I am one of those people that had the native app installed and opted for using the web version instead. Why? We all know why!
Issues I have with HTML5:
- Javascript
- Javascript
- Javascript
- Fragmentation like no other
- Lack of APIs
- Sandboxed environment
- A bunch of morons writing "frameworks" without a clue of computer science (same thing as many popular Wordpress PHP plugins written by people who have no clue of even how memory allocation is supposed to work)
- A bunch of other morons copying and pasting the work of other morons.
- No real memory management
- No real anything or poor support at anything (no sockets, no primitive types, no threads, cross domain BS)
- Internet Explorer
- Javascript
- Internet Explorer
- Javascript
...
It's just not what the foundation was meant for.
It only took Steve Jobs talking about how bad flash was and closing the endless array of development options that we have outside Objective-C and HTML5 to make the world try to reinvent the wheel in javascript, all the while ignoring the fact we have more powerful desktop computers than ever, all the while putting more money in the pockets of those that run cloud infrastructure.
I hope more guys like Zuck come out on the record and let the world know this is ludacris, that all these decades working on out of this world compiler optimizations and technology that's light years away from the browser can't be forgotten.
Yes, we need to be in the browser, but give me a break, Javascript?
It's just sad seeing the turn of events of our industry going in this direction, I'm glad of this whole "App" revolution and Zuckerberg saying this at his first appearance after the IPO, I hope it sobers up a bunch of decision makers.
- Javascript
- Javascript
- Javascript
- Fragmentation like no other
- Lack of APIs
- Sandboxed environment
- A bunch of morons writing "frameworks" without a clue of computer science (same thing as many popular Wordpress PHP plugins written by people who have no clue of even how memory allocation is supposed to work)
- A bunch of other morons copying and pasting the work of other morons.
- No real memory management
- No real anything or poor support at anything (no sockets, no primitive types, no threads, cross domain BS)
- Internet Explorer
- Javascript
- Internet Explorer
- Javascript
...
It's just not what the foundation was meant for.
It only took Steve Jobs talking about how bad flash was and closing the endless array of development options that we have outside Objective-C and HTML5 to make the world try to reinvent the wheel in javascript, all the while ignoring the fact we have more powerful desktop computers than ever, all the while putting more money in the pockets of those that run cloud infrastructure.
I hope more guys like Zuck come out on the record and let the world know this is ludacris, that all these decades working on out of this world compiler optimizations and technology that's light years away from the browser can't be forgotten.
Yes, we need to be in the browser, but give me a break, Javascript?
It's just sad seeing the turn of events of our industry going in this direction, I'm glad of this whole "App" revolution and Zuckerberg saying this at his first appearance after the IPO, I hope it sobers up a bunch of decision makers.
I can't believe this biased and unintelligent rant is being upvoted. HTML5 does not suck because of JavaScript, or because of using greedy algorithms, or because people allocate too much memory. It sucks because browser support isn't there and Apple/Google/MS does not give a damn about HTML5. And if you think about it, it makes sense, it's much better for Apple/Google/MS that developers develop exclusively for their platforms and not for HTML5 (a platform that could be run on any OS).
What we need is an independent browser vendor (Opera, Mozilla) to do an amazing HTML5 experience.
What we need is an independent browser vendor (Opera, Mozilla) to do an amazing HTML5 experience.
The story of the web up until now:
It sucks because browser X doesn't support technology Y correctly.
The thing about HTML5 is that it does not enforce any real design patterns, so if you are not very careful with the design of your application, it will quickly become a horrible mess. I expect that is where the parent's disdain is coming from.
Interestingly, when you do introduce design patterns in your HTML5 app, it starts to very closely resemble a native application. At that point, there is little advantage to using HTML5 over native environments from a developer's perspective. The only real win from HTML5 being its ubiquity.
Interestingly, when you do introduce design patterns in your HTML5 app, it starts to very closely resemble a native application. At that point, there is little advantage to using HTML5 over native environments from a developer's perspective. The only real win from HTML5 being its ubiquity.
JavaScript:
There's nothing wrong with JavaScript. It's a beautiful, powerful language if you know it.
Fragmentation:
Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps. Just because n is currently 2 does not make it scaleable.
Lack of APIs:
I don't know what you mean by this.
Sandboxes:
That's a feature not a bug
Morons:
You get that everywhere.
Memory management:
Ditto.
Poor support:
That's really just a rant against JS again isn't it? Cross domain "BS" is easily solved with allow-origin, and if you don't own the 3rd party server then you really shouldn't be programatically accessing it.
IE:
Meh, it's not as bad as it was. Nor is it popular enough to make it worth worrying about for lots of people.
There's nothing wrong with JavaScript. It's a beautiful, powerful language if you know it.
Fragmentation:
Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps. Just because n is currently 2 does not make it scaleable.
Lack of APIs:
I don't know what you mean by this.
Sandboxes:
That's a feature not a bug
Morons:
You get that everywhere.
Memory management:
Ditto.
Poor support:
That's really just a rant against JS again isn't it? Cross domain "BS" is easily solved with allow-origin, and if you don't own the 3rd party server then you really shouldn't be programatically accessing it.
IE:
Meh, it's not as bad as it was. Nor is it popular enough to make it worth worrying about for lots of people.
There's nothing wrong with JavaScript. It's a beautiful, powerful language if you know it.
All numbers are 64-bit double-precision floating-point. Interacting with binary protocols or cryptographic libraries is painful.
All strings are UCS-2, not true UTF-16. Characters outside the BMP are second-class citizens.
Those are two issues that I can think of in JavaScript-the-language. The most common use of JavaScript-the-stack, providing interactive functionality in a web browser, is riddled with gotchas like bizarre inconsistencies and arcane corner cases.
That's not to say that you can't do great things with JavaScript (plenty of evidence for that), or that the situation isn't changing (Mozilla added arrays of all the various integral types, but the individual elements still get treated as floating-point when extracted). But you have to be very careful (or use a framework made by someone who was careful), which IMHO makes it anything but "beautiful".
All numbers are 64-bit double-precision floating-point. Interacting with binary protocols or cryptographic libraries is painful.
All strings are UCS-2, not true UTF-16. Characters outside the BMP are second-class citizens.
Those are two issues that I can think of in JavaScript-the-language. The most common use of JavaScript-the-stack, providing interactive functionality in a web browser, is riddled with gotchas like bizarre inconsistencies and arcane corner cases.
That's not to say that you can't do great things with JavaScript (plenty of evidence for that), or that the situation isn't changing (Mozilla added arrays of all the various integral types, but the individual elements still get treated as floating-point when extracted). But you have to be very careful (or use a framework made by someone who was careful), which IMHO makes it anything but "beautiful".
> There's nothing wrong with JavaScript.
"Beautiful if you it" know also means "this is the only thing I know and the only thing that is viable so I might as well like it".
Was it hailed as a beautiful language when it came out? Why not? I don't remember accolades written about it. Oh because it is the only thing that runs on the browser. Those two things are orthogonal and one doesn't follow from the other no matter how much we try to make it that way.
> Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps.
Users don't care how many languages or how many tweaks your product code has. If it is slow to render, it flickers, if it takes forever to do its job, it is shit and it gets thrown away, regardless if it is written in Backbone.js or Ember.js, Haskell, or COBOL. It doesn't matter. That was the point.
"Beautiful if you it" know also means "this is the only thing I know and the only thing that is viable so I might as well like it".
Was it hailed as a beautiful language when it came out? Why not? I don't remember accolades written about it. Oh because it is the only thing that runs on the browser. Those two things are orthogonal and one doesn't follow from the other no matter how much we try to make it that way.
> Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps.
Users don't care how many languages or how many tweaks your product code has. If it is slow to render, it flickers, if it takes forever to do its job, it is shit and it gets thrown away, regardless if it is written in Backbone.js or Ember.js, Haskell, or COBOL. It doesn't matter. That was the point.
> Was it hailed as a beautiful language when it came out? Why not?
Short-sightedness? Confusion between JS and the DOM API? I don't see why you're bringing up "when it came out" either.
> "Beautiful if you know it" know also means "this is the only thing I know"
I don't see how that follows either.
I said that because many developers have a prejudiced impression of JS from the ie/netscape/image rollover days when it was hastily dismissed as a toy. If you spend some time looking at it seriously you can appreciate just how good "the good parts" are.
Short-sightedness? Confusion between JS and the DOM API? I don't see why you're bringing up "when it came out" either.
> "Beautiful if you know it" know also means "this is the only thing I know"
I don't see how that follows either.
I said that because many developers have a prejudiced impression of JS from the ie/netscape/image rollover days when it was hastily dismissed as a toy. If you spend some time looking at it seriously you can appreciate just how good "the good parts" are.
To be fair it wasn't hated "when it came out" because of it's ugliness. The part that made it unusable was browser fragmentation. But, you no longer have to write ridiculously complicated switch-riddled code because of better browser support, standardization and libraries that do it for you.
True browser fragmentation was a big problem and however I still don't remember (maybe I was just not aware) of anyone praising the language itself. That is sort of the argument -- it is a beautiful and great language. So regardless of implementation those qualities should have been there.
I'm confused about the no sockets (WebSockets) and no threads (Web workers) points. These standards may be immature, but they do exist.
There is a world of interesting opportunities available in an ecosystem where code is pushed, interpreted, and executed on the client.
For example, when I'm working with audio software I frequently use VST audio plugins in my projects. Unfortunately, my projects aren't very portable because they require the same plugins to be installed on another machine in order to open that project. When you can't control the dependencies that may or may not exist on someone's machine, you have a really annoying ecosystem. Most professional software environments suffer from this.
If instead, my DAW software was running based completely on sandboxed code executed locally but being served up remotely, then I can move from machine to machine effortlessly and collaborate incredibly easily with other producers and musicians. Of course, this is not the only use case.
Also, the browser and JavaScript don't HAVE to be the way forward, but there is a massive amount of momentum and very few competitors with any sort of traction.
Also, read up, son: Websockets, Web Workers, CORS, WebGL, Web Audio API, WebRTC, MediaStream API, DataStream API.
The approach is to maintain the sandbox and therefore allow arbitrary code to be run while increasing the number of hardware accelerated interfaces to the machine.
For example, when I'm working with audio software I frequently use VST audio plugins in my projects. Unfortunately, my projects aren't very portable because they require the same plugins to be installed on another machine in order to open that project. When you can't control the dependencies that may or may not exist on someone's machine, you have a really annoying ecosystem. Most professional software environments suffer from this.
If instead, my DAW software was running based completely on sandboxed code executed locally but being served up remotely, then I can move from machine to machine effortlessly and collaborate incredibly easily with other producers and musicians. Of course, this is not the only use case.
Also, the browser and JavaScript don't HAVE to be the way forward, but there is a massive amount of momentum and very few competitors with any sort of traction.
Also, read up, son: Websockets, Web Workers, CORS, WebGL, Web Audio API, WebRTC, MediaStream API, DataStream API.
The approach is to maintain the sandbox and therefore allow arbitrary code to be run while increasing the number of hardware accelerated interfaces to the machine.
If instead, my DAW software was running based completely on sandboxed code executed locally but being served up remotely, then I can move from machine to machine effortlessly and collaborate incredibly easily with other producers and musicians. Of course, this is not the only use case.
But isn't that really licensing requirements, rather than technical requirements? Or the 20+GB sample libraries that things like Superior Drummer haul around? I don't see how you could remote-serve that kind of content, any more than you could, say, Skyrim. Now, remote rendering MIDI data and streaming back the audio might work, but I use many VST plugins as real-time processors (amp sims etc.) Knowing how much effort I've sunk into optimising everything on this computer for real-time playable latencies without glitching, I'm having a hard time believing that the Web Audio API is going to cut it for my use case, unless it's basically just ASIO. There simply isn't much opportunity for any buffering at 5ms latency, so that "sandbox" might end up sharing memory rather a lot...
But isn't that really licensing requirements, rather than technical requirements? Or the 20+GB sample libraries that things like Superior Drummer haul around? I don't see how you could remote-serve that kind of content, any more than you could, say, Skyrim. Now, remote rendering MIDI data and streaming back the audio might work, but I use many VST plugins as real-time processors (amp sims etc.) Knowing how much effort I've sunk into optimising everything on this computer for real-time playable latencies without glitching, I'm having a hard time believing that the Web Audio API is going to cut it for my use case, unless it's basically just ASIO. There simply isn't much opportunity for any buffering at 5ms latency, so that "sandbox" might end up sharing memory rather a lot...
Sockets exist, work, and are used by lots of people.
And work on all browser for all people.
Or wait.. they don't for most
http://caniuse.com/websockets
Or wait.. they don't for most
http://caniuse.com/websockets
Pretty much every modern websockets Javascript library you use these days will provide fallback mechanisms to flash or long polling to provide the same features. Take a look at the supported browsers for Socket.io and its a much larger list then the one you've provided.
http://socket.io/#browser-support
http://socket.io/#browser-support
They're not sockets, they're WebSockets, and they require a custom HTTP server setup just to open a socket connection to a service.
This means that I can't do something that should be really simple -- like open a VNC connection to a remote server -- without first configuring an HTTP WebSocket proxy.
This means that I can't do something that should be really simple -- like open a VNC connection to a remote server -- without first configuring an HTTP WebSocket proxy.
HTML5 is fine, but it's for developing web UI's not mobile apps. Sure it would be nice if all the main mobile OS's used the same language and frameworks but they don't, people need to get over that and start developing natively.
It's the glittering lure of write-once run-everywhere.
Devs still fall for it, even though we should know better.
Devs still fall for it, even though we should know better.
This is what HTML is capable of: http://ro.me
> We are sorry, but it appears that your browser does not support WebGL. Please download Google Chrome and try launching this site again.
Using google chrome 21.0.1180.89 on ubuntu 12.04
Using google chrome 21.0.1180.89 on ubuntu 12.04
Which doesn't work on any mobile device, which is what this quote is talking about.
His statement is calculated so he does not receive too much criticism from over-hyped HTML5 cool aid drinkers (which abound in great numbers).
I see the wind starting to turn finally, it had been fairly steady since Steve Jobs hot air concerning HTML5.
I see the wind starting to turn finally, it had been fairly steady since Steve Jobs hot air concerning HTML5.
[deleted]