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.
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.
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 believe webkit (either in safari or UIWebView) should be able to run JIT, while your custom engine can't.
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.
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".
Apps get notifications.
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.
My simple question is, "Are you really a SOFTWARE engineer?"
HARDWARE engineers will solve the problem. Hah!
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.
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?
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.
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.
You can verify that this is correct by looking at any benchmark.
There are people working on changing that, for what it's worth.
Disclaimer: I wrote Blossom.
Blossom sounds pretty neat!
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.
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.
Could you explain why?
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)
You seem to think Twitter has a strong reliability record.
this is testament to just how bad the app was.
That's definitely a contributing factor, in my opinion.
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)
Edit: http://www.readwriteweb.com/archives/free_mobile_facebook_wi... there we go, Facebook Zero.
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.
LocalStorage quotas cannot be made bigger than 5MB.
I remember trying this Mozilla-built webapp out in Google Chrome, it just didn't work.
The mobile app experience is that bad.
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.
However in the case of Facebook, the error was still made.
People talk poorly in normal conversation. It takes time to craft a good quote.
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.
fact is html5 is slow, even more so on none apple phones/tablets. everyone who's worked with it knows it.
These things need to work on an asynchronous basis, more like email, to get status updates, post to walls etc.
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 :-)
- 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
It's just not what the foundation was meant for.
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.
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.
What we need is an independent browser vendor (Opera, Mozilla) to do an amazing HTML5 experience.
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.
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.
That's a feature not a bug
You get that everywhere.
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.
Meh, it's not as bad as it was. Nor is it popular enough to make it worth worrying about for lots of people.
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.
"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.
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.
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, 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.
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...
Or wait.. they don't for most
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.
Devs still fall for it, even though we should know better.
Using google chrome 21.0.1180.89 on ubuntu 12.04
Using Google Chrome
I see the wind starting to turn finally, it had been fairly steady since Steve Jobs hot air concerning HTML5.