15 ms·

Making Facebook's native mobile app faster using HTML5

313 points by steffenhiller 14y ago

nathanpc 14y ago
HTML5 can be fast just like Native applications, but you need to know how to make it faster. Hopefully we are going to get more awesome libraries and frameworks like Sencha Touch to make our life easier.
- speg 14y ago
  This. It's a lot harder to screw up when using native SDKs vs. the plethora of HTML5 frameworks, some which are more mature than others but none really seem to have a "standardized" way to easily make a performant app in the same way that the native SDKs do.
- camus 14y ago
  You mean commercial products with suscpicious licensing ?
kaolinite 14y ago
A lot of the points that they make in the video are just flaws with Facebook's implementation of the app, rather than being a point for HTML5 or a point against native. Truth is - HTML5 apps can be made to perform well but there are limits. Battery life suffers and you may find in future that the cool animation/whatever you wanted to add in is too laggy (especially on older devices).
- untog 14y ago
  Battery life suffers Really? If anything I would have thought that HTML5 was more battery efficient- there's only so much you can do with it, after all. I spent a long time optimising a mobile webapp I was working on and while it was 95% there, that last 5% bugged me to no end. So I investigated native options. But I learnt to avoid mixing CSS3 box-shadows with transition animations and that sort of thing- you definitely suffer in FPS.
  - kaolinite 14y ago
    Of course native is more efficient - it takes fewer CPU cycles to get what you want done. Now you're right that as a result you might be more likely to include animations and effects etc which will drain more power, but that's a choice you can make.
- marknutter 14y ago
  Older devices will slowly dissipate from the market because of the ubiquitous two-year contracts, though, and eventually everyone's phones will be capable of delivering native-like performance on HTML5 apps. It's only a matter of time.
  - alifaziz 14y ago
    The moment older devices slowly fade out from the market, and new high end devices started to fade in, native app speed now doubled.
    - marknutter 14y ago
      Doubled from awesome to... awesome? Native performance is the goal. I don't see how much better a data heavy native app like FB can get, but I do see how HTML5 apps can get better.
matwood 14y ago
We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. Do the new native FB apps only run on iOS5+ and Android 4.1+? HTML5 may be ready on those platforms, but Android still has a lot of 2.x phones floating around. How do the HTML 5 benchmarks for iOS 5 run on the original iPhone 4?
realrocker 14y ago
Where are the benchmark reports on phone's from 1.5 to 4.1? 64% of android phone's are still pre-honeycomb(3.0). HTML5 on Android is good now but it sucks on those earlier phones. I am sure Facebook has to take care of everyone.
- dmarble 14y ago
  For those who need a source for segmentation of android versions in use: http://developer.android.com/about/dashboards/index.html http://developer.android.com/about/dashboards/index.html
marknutter 14y ago
The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. However, we're still in the transition period where there are a sufficient number of older phones on the market that don't run HTML5 apps well, so until they are filtered out your best option is still native. I do hope this app silences the HTML5 critics out there who say you can't get a good UX with HTML5, though. The proof is in the pudding.
- technoslut 14y ago
  >The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. I believe you're wrong. The question isn't whether HTML can keep up with what exists today but what is offered in the future natively. We are already living in a world with data caps and it will be so for the foreseeable future. That alone hinders the capabilities of the web. We're not even including the distrust that consumers have for paying for something unless it is through a system owned by Apple, Amazon, Google and MS. This is even including Gen Y users. I have no doubt that the web is the future but the future is a ways off. There are just too many obstacles that are in the way currently.
  - marknutter 14y ago
    I'm not sure I understand the connection to data caps. HTML5 allows you to cache apps and data locally, and wrappers like Trigger.io and Phonegap allow you to run an HTML5 app completely on the client without any reliance on data from an outside network.
    - technoslut 14y ago
      Maybe I'm wrong but, when I consider apps, I also consider gaming a part of the equation as well, since they are the most popular apps. We've already seen OnLive fail because the web is simply not ready to handle the tasks of real-time gaming for enthusiasts.
micampe 14y ago
Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it? Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why? One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wrong and I think people notice even if they probably don't know how to describe it. Maybe with this Sencha contest we'll see some good ones.
- marknutter 14y ago
  I think it's a mix of FUD and reality. It's true that for most older devices HTML5 apps just don't perform very well, but they are slowly disappearing from the market. Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them.
  - technoslut 14y ago
    >Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them. Maybe I'm mistaken but Google released an official Gmail app on iOS that was basically HTML. Everyone hated it. The same goes for the situation with GMaps. Virtually no one used the web app and now Google Maps is the top ranked free app.
    - marknutter 14y ago
      I've never actually been able to get a confirmation one way or the other oh which of Google's native apps are "hybrid" apps and just how much of those apps is done in HTML5. The previous version of their gmail app seemed to employ a lot of HTML5 because you could see the main inbox list re-render occasionally. That app performed perfectly well for me. Unless we hear from Google officially about the new app we'll never know. It could be that it's full native, or it could be that they've perfected the HTML5 code to make it feel completely native. Who knows.
brianchu 14y ago
I ran the HTML5 app on my iTouch 4G running iOS 6 (roughly equivalent to iPhone 3GS) and compared it to the native FB app. The HTML5 app had noticeable lag in the swipe transitions. It also crashed once when loading a photo (only once though). Not to mention that they implement almost everything differently and leave out 90% of FB's features. That being said, it was really smooth on my iTouch 5G. The demo HTML5 app also runs in Safari. The problem is that Safari's Nitro JS engine is much faster than the older JS engine used in a UIWebView (I think the restriction is supposedly due to security). For the moment, native is still the way to go, IMO. But I've always believed that at a certain point iPhones/Androids and their browsers will be powerful and efficient enough to negate any performance drawbacks to HTML 5. I think that point might arrive by the iPhone 6 or so, when developers might feel comfortable dropping support for the iPhone 3GS and equivalent. In fact, many devs are already dropping support for the iPhone 3GS.
- posabsolute 14y ago
  I am currently developing a vanilla (no mobile frameworks like sencha) mobile web app I can attest that on IOS you can pretty much get native performance if you do some trade off and optimize your app rendering. On android that's another game and you can forget about all those cozy animations and only devices with android 4.0+ will perform well, or at all (in my case anyway). Also I'm really not sure why people currently associate html5 apps with bad battery life, personally I did not see any noticeable differences in usage from a native one, hell native use a lot more the gpu so it should be worse.
  - TeeWEE 14y ago
    I have the same experiences. We wrote http://hyves.nl/hybrid http://hyves.nl/hybrid which works wonderfully on iOS. But didnt really deliver the HTML promise on Android. Maybe because of the browser which was not as good as the safari a year ago. And maybe also because of slower phones. However the same code did run on iOS blackberry and Android. However the experience was sub-native on most devices. And we really needed to do a lot of tweaking and work to get the native look and feel on iOS. So if you want to be the best, no matter the costs, go native. Otherwise Sencha is not a bad choice to make. It really depends on your requirements.
eatsleepdrink 14y ago
Nitro Javascript engine? It could be an important difference between this test and FB's app. Safari gets it. It seems ambiguous still whether UIWebView users get it. A more apples-to-apples comparison would be to put it in a iOS app running UIWebView and see if the performance is maintained. I'd certainly be interested in the results.
- hnmullany 14y ago
  Performance is also great in a wrapped version. The bottleneck we had to solve was in event management, the GPU & compositor not in the JavaScript execution.
- loumf 14y ago
  It's not ambiguous. On iOS, only Safari can JIT JavaScript. This is because Apple doesn't trust your app enough to let you made code pages. It also doesn't trust the app it makes when you install a web app to your home page (and it's not just a Safari bookmark). I suspect the latter may change, but I wouldn't count on the former.
spydum 14y ago
I suspect they misunderstood the "HTML5 is not ready" statement. Indeed, HTML5 can perform, and the future is bright. However, as plenty of people in the comments here have mentioned, for mainstream devices.. it's not ready. The frameworks are still coming up a learning curve, the hardware devices out there are still struggling to adopt proper HTML5 support and decent performance. Those points alone lend credit to the fact that it's just not ready.
- marknutter 14y ago
  Yes, but it will be ready, and the question is will devs and firms that have invested all their time into native development be ready too? It would be prudent to be ahead of the curve when the horizon is so clearly visible.
  - mattmanser 14y ago
    It was also clearly visible 3 years ago. It's nice to be an HTML5 advocate, but lets be realistic, it's 3-4 years before HTML5 will be coming even close to native in performance or tooling. In the meantime all those native developers will be kicking your ass in earnings and functionality.
    - marknutter 14y ago
      > In the meantime all those native developers will be kicking your ass in earnings and functionality. There's no need to get testy. There's no reason why HTML5 proponents can't implement some or even all of their apps in Native code (as I do). Without getting into a religious war, though, it's important to understand where the puck is going in addition to where it is currently.
  - spydum 14y ago
    The problem with being a platform that serves such a large audience (indeed, one that gets paid based on the eyeballs it can sustain) is that you need to cater to the largest range of devices and their performance. It's the same reason enterprises still support such obscure browsers and OS's (XP/IE6). They just aren't willing to sacrifice the overall experience of those who are slow to upgrade in favor of pushing the technology forward.
tterrace 14y ago
They take offense to Zuckerburg's "HTML5 isn't quite there yet" comment but in order to keep their implementation quick they had to build a custom iframe framework in addition to their TaskQueue and AnimationQueue implementations to replicate the fb timeline. It seems like that was part of Zuck's point - why would a company with a deadline take on all that technical debt to replicate things that you essentially get for free on a native platform?
- marknutter 14y ago
  You're forgetting one small point: you have to write two (or more) native apps once you go that route. Hence the reason Facebook's Android native app came out roughly 6 months after their iOS native app did.
  - tterrace 14y ago
    That's true but wouldn't you (as of today) still be much more comfortable going that route with a non-trivial project? Less time spent on the cutting edge battling the idiosyncrasies of the platform and more time building your app.
    - marknutter 14y ago
      It depends on the resources available. If I were a CEO and the company was flush with cash, I'd just brute force it by hiring native developers across all platforms or farm it out to specialized native dev shops. If was a CEO of a smaller company tight on cash with a bunch of web developers, however, I'd go the HTML5 or hybrid route because it'd be the best utilization of my company's time and resources. This isn't a black and white issue.
      - suprfresh 14y ago
        Definitely agree. I'm not sure why many people think its just so cut and dry. The tradeoffs between html5 vs native are pretty much known at this point. Take those and rationalize along with the resources you have available, the cost, and time you can afford. Just ship something.
level09 14y ago
This is cool, however, I'd say HTML5 has a bright future regarding web-based apps, or apps with a specific use case where you pull some data and display it in a list/table view etc .. HTML5 will never be as capable as native if you have many other use cases (ex: image/video processing, music recognition ) ..
- jbail 14y ago
  "HTML5 will never be as capabable as native..." I think its very possible to imagine a world where HTML5 can be just as good as native. It comes down to two things: 1) HTML5 needs more JavaScript APIs to access hardware like camera, contacts, etc. It's is not very difficult to imagine HTML6 (if you will) supporting this in much the same way that it supports geolocation today. 2) Improved JavaScript performance. It's common knowledge that the embedded web views on iOS are much less capable than Safari. There's no reason to think this would continue forever. Furthermore, better JavaScript performance makes things like image progressing, music recognition possible. Right now, you are absolutely correct that HTML5 is not as capable as native. No argument there. But, this gap narrows as time goes on. I firmly believe the opposite of you; we will eventually see a time when web-based applications rival native apps in terms of power and functionality. You can already do some awesome image processing stuff using canvas and JavaScript. This is only the beginning...
  - camus 14y ago
    3) ditch javascript and replace it with a better language...
  - drivebyacct2 14y ago
    1 is more or less already here. Both Chrome and Mozilla are working on it and collaborating on specifications: WebRTC, Mouse lock, Fullscreen, low level Audio creation, MediaSource API for appendByte() style free-for-all video. It's already becoming easier to build interactive rich applications with web technologies. Frankly, most people aren't paying enough attention.
  - dotborg 14y ago
    The idea of HTML5 is to avoid using JS in your app.
programminggeek 14y ago
HTML5 is cool and you can do a lot with it, but it has some very real drawbacks - like Android. Also, if you are doing a bunch of optimizations to make it fast on HTML5, then you're basically doing the same work as writing a native app, so what are you gaining by doing a HTML5? Seriously, at some point you can get a better user experience, have better access to native API's and can really leverage the full abilities of the device by going native. So, you know, go native. Disclaimer: I have wrote HTML5 mobile apps and I think it's a great developer experience, but it feels worse as a user.
- marknutter 14y ago
  But this argument makes no sense. When you go native, you have to write N number of apps for N number of platforms you want to support. The point is that making a great mobile app is hard no matter what stack you choose to use. It's also a bit disingenuous to say you are forced to optimize every HTML5 app. The whole point of Sencha's blog post is to advertise the fact that they've abstracted away all those optimizations you need to do so that developers can focus on building cross platform HTML5 mobile apps.
  - tehwebguy 14y ago
    Maybe people that make this argument only care about supporting one (or two) platforms.
    - marknutter 14y ago
      IMO as soon as you want to support two platforms natively you've nearly doubled your work.
      - rimantas 14y ago
        And if you try to support them by doing web based app you quadrupled your work, only it is on the same code base.
        14y ago
steffenhiller 14y ago
Here's an interview Robert Scoble did with the guys from Sencha about their Facebook app: https://plus.google.com/+Scobleizer/posts/ZtnZNrCfWv6 https://plus.google.com/+Scobleizer/posts/ZtnZNrCfWv6
andrewmunn 14y ago
I'd like to clarify one thing. The "native" Android app that was tested, isn't actually native. Native newsfeed shipped in Facebook for Android 2.0, but 1.9.2 was used in the comparison. Thus, the comparison was between two html5 implementations of newsfeed. That said, I'd love to see a side by side video with Facebook for Android 2.0.
- paulkopacki 14y ago
  give the comparison a try. fastbook (the sencha html5 facebook app) is here fb.html5isready.com.
drivebyacct2 14y ago
All the HTML haters (I jest, but that's not a totally unfair characterization of some here) should check out the Chrome team's efforts for Web Components (although I think the name just changed) for Dart/W3C spec, and AngularJS. They make building HTML apps much, much, much more similar to building native applications.
cmelbye 14y ago
Looks and functions terribly in Internet Explorer 10 on Windows Phone 8 unfortunately.
- Joeri 14y ago
  Sencha's wp8 support is in beta, it doesn't ship until next year.
  - smrtinsert 14y ago
    so then its not ready.
umsm 14y ago
I was tasked with creating the phone app for the company I work for. Here are the key points: - The project took 2 months for me to learn the sencha framework AND to build the app from scratch (it's live in the app store). - The app performs well on the iphone 4, but the best performance is on the iphone 4S and later. - The Android version is not as smooth. It's significantly slower. This means it's not truly cross-platform. - People with the iphone 4S / 5 don't know it's not a native app until I tell them.
- marknutter 14y ago
  Similar experience here. We actually decided to scrap our Sencha app and go with a hybrid app where some UI components were done using native code and most of the app was done in vanilla HTML5/CSS3/Javascript. It's working out very well so far.
dexcs 14y ago
The problem with HTML5 are the different vendors with their different opinions. And that problem will make native apps faster and easier to maintain than html5 for the next few years....
sil3ntmac 14y ago
To me the most impressive thing is that Sencha Touch can run at any reasonable performance level. Has anyone used the framework? iirc there's >1mb debug JS, randomly-generated element IDs, a mess in general. The thing would hang my chrome for a couple moments just to parse the js. Obviously this is solved with minification/dynamic script loading, but Sencha's kitchen-sink approach really doesn't seem to help much in the area of performance.
- Joeri 14y ago
  You're supposed to use the build tools to generate a file with only the subset you need for your project. By the way, the download time for the native app is also non-zero. With appcache you pay the framework's download cost only once. Admittedly it still needs parsing to load, but i haven't had this seconds-long parsing experience myself in my sencha touch app.
  - city41 14y ago
    > You're supposed to use the build tools to generate a file with only the subset you need for your project. Both Ext and Sencha Touch are very monolithic. When you use Sencha Command to pair your app down to just what it uses, it still pulls in well over 90% of the framework.
jacek 14y ago
I have just finished a mobile app in HTML5. Although it works fine on iOS and Android 4.x, it caused many problems on Android 2.x. As Android 2.x still has more than 50% of Android market share it is a platform we cannot ignore. I am sticking to native development for now.
- kamjam 14y ago
  we recommend at least iOS 5 or Android 4.1 I agree with you. I was going to ask this same questoin. From TFA, they stated above. Well, that really sounds like Mark Zuckerberg didn't know what he was talking about at the beginning of this year! A lot of people are still on Android 2.X as you have stated, and a lot of people are on slow Android devices. I know several people on ZTE Blades running 2.3 which were available over a year ago for less than £100. Sure, not the snappiest of devices, but usable. What is the HTML5 version going to be like for these users? Blah blah blah, hardware limitations, you can't limit yourself to lowest denominator etc. But Facebook HAS to support all these users. And it's not just users in the western world. There are millions of users in third world countries who pretty much exclusively access Facebook from mobile phones, usually not the latest spec (or even close) or most up to date s/w version (I doubt many would even know how to update it). I agree that web apps are the way to go. But it is VERY much going to depend on your target audience.
ttt_ 14y ago
I'll be saying this as a user. I wish most developers would turn to HTML5 today, like right now, and avoid native apps at all cost unless there is really no alternative. Why? Because I remember the browser wars and how much it was a terrible idea and the terrible experience it made for users who simply could not experience the internet from a single starting point. This time it's not simply a matter of downloading another browser, if there's content I want to consume and there's not a native app for my phone, what do I do? I buy a different one? What about the content that I already consume and that's not over there? Should I have multiple phones? I could not care less if it's optimize to integrated well with the native environment or some whatnot, let the browser handle that with default behavior. I want the content, the feature, and not wait for companies to port over apps from one place to the next. This platform cult is pretty meaningless to me, in fact I don't even want to buy any device right now because I'm pretty sure I'll get burned as a user either way. The only platform I'm betting my money on as a user is the upcoming Firefox OS. Hopefuly Mozilla will be able to undo the damage done in this fragmented mess, again.
- marknutter 14y ago
  Well put. The worst usability problem an app can have is simply not existing.
  - millstone 14y ago
    Is an app that you have to fight with really better than no app at all? If it didn't exist, at least you wouldn't have gotten in a fight! There's many sites that I consciously avoid on my phone because they work so poorly that I don't even want to bother. These sites do mobile users no service by existing. An app or website has to at least meet the "user will tolerate it" bar.
- javajosh 14y ago
  I was with you until you said "This platform cult is pretty meaningless to me." Actually the platform wars are quite meaningful insofar as they represent large-scale manipulation of consumers. Both Apple and Google are playing the following game: hey consumer, here's a shiny device, it's pretty cheap and then we lock you into a 2-year contract, meanwhile you acquire apps that can only be run an iPhone, and now even if you wanted to go to Android, you are faced with the prospect of ditching your entire software library (or vice-versa). It's called lock-in and it's a long-term manipulation of a market. I'm sure that both Apple and Google rationalize that it's a way to recoup R&D costs, and that's true enough, but it's a sneaky way to do it. There's also the not insignificant problem of app security. Not so long ago there was a news item about the FB native app accessing contacts and uploading them to FB servers. The web app cannot do that, and that's a Good Thing. There's also another reason why HTML5 apps are better than native: they are composable. There isn't much out there other than search engines that takes advantage of this fact, but webapps can be composed, parsed, and otherwise uniformly manipulated in useful and interesting ways. Android and iOS do indeed offer some integration points for their native apps, but nowhere near at the level that the web allows today.
rodion_89 14y ago
A couple of months ago I mentioned these same notions about the Facebook app. http://jairaj.org/2012/08/27/facebook-for-ios.html http://jairaj.org/2012/08/27/facebook-for-ios.html Although I have to admit that Sencha's implementation isn't all that great. If you're going to offer an alternative, at least make it better than the other option.
herf 14y ago
If you insert a big image into the DOM, MobileSafari locks up for quite a few frames (whether or not it's preloaded.) Sencha's implementation just swaps pictures when you're not doing anything else! But most native apps can update photos while you're actually scrolling around.
TeeWEE 14y ago
Good work. But they are cheating in one main spot: - they use a proxy to cut down data transfer Good choice, but comparing it with the orignal app is not valid anymore (its not really html5 that is making it faster) Anyway its still a very fast mobile app, and html5 is sometimes the best choice to make. Because it is very expensive to write a different app for all platforms currently. However, currently, it is also very time consuming to have a html5 app that is on-par with native, and works well in both android and iphone. So its a tradeoff really, html5 is not better than native, or vice versa. Like so many things in life, it depends :-)
- joshtynjala 14y ago
  > comparing it with the orignal app is not valid anymore Facebook could have done the same thing with their app too, so I don't see how this affects validity.
  - TeeWEE 14y ago
    If I am comparing the speed of two cars, but one car contains 5 persons while the other one only contains 1, then it's an unfair comparison right?
eblade 14y ago
It started with the implementation of an Infinite List Component that handles items with unknown sizes. Only a very small set of DOM nodes is actually created to fill in the actual visible screen area. They will then be constantly recycled to render next / previous data on-demand. As a result, memory footprint is kept minimal, regardless of the amount of data in the Store. Making this work is the easy part. Making it fast with the complexity and variety of items such as News Feed stories is the real challenge. The bottleneck lies within the core processes that a browser has to perform: layout and compositing. I wished jQuery Mobile has Infinite List Component that handles the list item recycling the last time I used it. It is the equivalent of UITableViewCell's dequeueReusableCellWithIdentifier.
u2sonderzug 14y ago
Looking at this from a different point of view maybe altogether, one of the big issues I think concerning HTML5 mobile web apps (not used in a native app wrapper to get included in the appstore) is discovery. Where do I actually find compelling mobile web app user experience when I am trying to solve a problem in my web browser as a user when I search using a search engine? I noticed a few years ago that Google cut out their mobile only results option - and now when you search for anything on a smart phone you get a mish mash of mobile friendly and conventional web optimised results. For a little while there Google would put a little mobile icon next to mobile optimized results - but that has gone too. I know perhaps the point of mobile is moot now - since we have a sizeable amount of tablets accessing websites too. But just in my own personal research all my friends who aren't techy say they much prefer sites that look right on their 'touch' (be it mobile or tablet). For instance, is there even such a thing as a 'mobile web app store' out there? If consumers had an easier way of finding great mobile web apps perhaps this would grow this channel? I'd be interested in perspectives on this - maybe I'm looking at it the wrong way. I'd also like to make the case that I think HTML5 will continue to make a very important contribution moving forward - why? Because as we get more devices, it's really starting to get silly how many apps I constantly need updated and feel like I need syncing. I think as prices come down we will find ourselves with several devices for home, out and about and at work - using the 'fat client' model of installing all these apps just gets annoying.
deleted 14y ago
[deleted]
iiid 14y ago
I agreed that writing app in HTML5/CSS/JS is easy to mantain. But why not get access to those native features too? Hybrid apps seem to be very logical way to build apps now. Take a look at many emerging services like http://trigger.io http://trigger.io and get the best of both world.
tagliala 14y ago
IMHO if in 2013 a HTML5 application needs iframe + js proxies hacks to perform faster, there is something deeply wrong. Sorry for my English
madoublet 14y ago
I think the problem with HTML5 is that Android and iOS treat it like a second class citizen. For all its faults, the one thing Windows 8 got right was that it allows developers to build native apps using HTML5.
chrisringrose 14y ago
I'd say the problems the Facebook team ran into were related to the universal difficulties of HTML5 development. The tools are nothing compared to native app development. In making native apps, developers can visually create the GUI, double-click an element and immediately program its response. But with HTML5, everything is done programmatically, with great pains. When you run into problems you have to debug JavaScript, CSS, HTML, and any client libraries, possibly written in yet another language. The tools just aren't there, so continuing to maintain an HTML5 app that performs quickly and nicely like "Fastbook" does is far too costly, considering how much more easily a native app can be created and maintained.

313 points by steffenhiller 14y ago

HTML5 can be fast just like Native applications, but you need to know how to make it faster. Hopefully we are going to get more awesome libraries and frameworks like Sencha Touch to make our life easier.

speg 14y ago
This. It's a lot harder to screw up when using native SDKs vs. the plethora of HTML5 frameworks, some which are more mature than others but none really seem to have a "standardized" way to easily make a performant app in the same way that the native SDKs do.
camus 14y ago
You mean commercial products with suscpicious licensing ?

kaolinite 14y ago

A lot of the points that they make in the video are just flaws with Facebook's implementation of the app, rather than being a point for HTML5 or a point against native. Truth is - HTML5 apps can be made to perform well but there are limits. Battery life suffers and you may find in future that the cool animation/whatever you wanted to add in is too laggy (especially on older devices).

untog 14y ago
Battery life suffers Really? If anything I would have thought that HTML5 was more battery efficient- there's only so much you can do with it, after all. I spent a long time optimising a mobile webapp I was working on and while it was 95% there, that last 5% bugged me to no end. So I investigated native options. But I learnt to avoid mixing CSS3 box-shadows with transition animations and that sort of thing- you definitely suffer in FPS.
- kaolinite 14y ago
  Of course native is more efficient - it takes fewer CPU cycles to get what you want done. Now you're right that as a result you might be more likely to include animations and effects etc which will drain more power, but that's a choice you can make.
marknutter 14y ago
Older devices will slowly dissipate from the market because of the ubiquitous two-year contracts, though, and eventually everyone's phones will be capable of delivering native-like performance on HTML5 apps. It's only a matter of time.
- alifaziz 14y ago
  The moment older devices slowly fade out from the market, and new high end devices started to fade in, native app speed now doubled.
  - marknutter 14y ago
    Doubled from awesome to... awesome? Native performance is the goal. I don't see how much better a data heavy native app like FB can get, but I do see how HTML5 apps can get better.

matwood 14y ago

We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. Do the new native FB apps only run on iOS5+ and Android 4.1+? HTML5 may be ready on those platforms, but Android still has a lot of 2.x phones floating around. How do the HTML 5 benchmarks for iOS 5 run on the original iPhone 4?

realrocker 14y ago

Where are the benchmark reports on phone's from 1.5 to 4.1? 64% of android phone's are still pre-honeycomb(3.0). HTML5 on Android is good now but it sucks on those earlier phones. I am sure Facebook has to take care of everyone.

dmarble 14y ago
For those who need a source for segmentation of android versions in use: http://developer.android.com/about/dashboards/index.html http://developer.android.com/about/dashboards/index.html

marknutter 14y ago

The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. However, we're still in the transition period where there are a sufficient number of older phones on the market that don't run HTML5 apps well, so until they are filtered out your best option is still native. I do hope this app silences the HTML5 critics out there who say you can't get a good UX with HTML5, though. The proof is in the pudding.

technoslut 14y ago
>The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. I believe you're wrong. The question isn't whether HTML can keep up with what exists today but what is offered in the future natively. We are already living in a world with data caps and it will be so for the foreseeable future. That alone hinders the capabilities of the web. We're not even including the distrust that consumers have for paying for something unless it is through a system owned by Apple, Amazon, Google and MS. This is even including Gen Y users. I have no doubt that the web is the future but the future is a ways off. There are just too many obstacles that are in the way currently.
- marknutter 14y ago
  I'm not sure I understand the connection to data caps. HTML5 allows you to cache apps and data locally, and wrappers like Trigger.io and Phonegap allow you to run an HTML5 app completely on the client without any reliance on data from an outside network.
  - technoslut 14y ago
    Maybe I'm wrong but, when I consider apps, I also consider gaming a part of the equation as well, since they are the most popular apps. We've already seen OnLive fail because the web is simply not ready to handle the tasks of real-time gaming for enthusiasts.

micampe 14y ago

Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it? Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why? One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wrong and I think people notice even if they probably don't know how to describe it. Maybe with this Sencha contest we'll see some good ones.

marknutter 14y ago
I think it's a mix of FUD and reality. It's true that for most older devices HTML5 apps just don't perform very well, but they are slowly disappearing from the market. Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them.
- technoslut 14y ago
  >Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them. Maybe I'm mistaken but Google released an official Gmail app on iOS that was basically HTML. Everyone hated it. The same goes for the situation with GMaps. Virtually no one used the web app and now Google Maps is the top ranked free app.
  - marknutter 14y ago
    I've never actually been able to get a confirmation one way or the other oh which of Google's native apps are "hybrid" apps and just how much of those apps is done in HTML5. The previous version of their gmail app seemed to employ a lot of HTML5 because you could see the main inbox list re-render occasionally. That app performed perfectly well for me. Unless we hear from Google officially about the new app we'll never know. It could be that it's full native, or it could be that they've perfected the HTML5 code to make it feel completely native. Who knows.

brianchu 14y ago

I ran the HTML5 app on my iTouch 4G running iOS 6 (roughly equivalent to iPhone 3GS) and compared it to the native FB app. The HTML5 app had noticeable lag in the swipe transitions. It also crashed once when loading a photo (only once though). Not to mention that they implement almost everything differently and leave out 90% of FB's features. That being said, it was really smooth on my iTouch 5G. The demo HTML5 app also runs in Safari. The problem is that Safari's Nitro JS engine is much faster than the older JS engine used in a UIWebView (I think the restriction is supposedly due to security). For the moment, native is still the way to go, IMO. But I've always believed that at a certain point iPhones/Androids and their browsers will be powerful and efficient enough to negate any performance drawbacks to HTML 5. I think that point might arrive by the iPhone 6 or so, when developers might feel comfortable dropping support for the iPhone 3GS and equivalent. In fact, many devs are already dropping support for the iPhone 3GS.

posabsolute 14y ago
I am currently developing a vanilla (no mobile frameworks like sencha) mobile web app I can attest that on IOS you can pretty much get native performance if you do some trade off and optimize your app rendering. On android that's another game and you can forget about all those cozy animations and only devices with android 4.0+ will perform well, or at all (in my case anyway). Also I'm really not sure why people currently associate html5 apps with bad battery life, personally I did not see any noticeable differences in usage from a native one, hell native use a lot more the gpu so it should be worse.
- TeeWEE 14y ago
  I have the same experiences. We wrote http://hyves.nl/hybrid http://hyves.nl/hybrid which works wonderfully on iOS. But didnt really deliver the HTML promise on Android. Maybe because of the browser which was not as good as the safari a year ago. And maybe also because of slower phones. However the same code did run on iOS blackberry and Android. However the experience was sub-native on most devices. And we really needed to do a lot of tweaking and work to get the native look and feel on iOS. So if you want to be the best, no matter the costs, go native. Otherwise Sencha is not a bad choice to make. It really depends on your requirements.

eatsleepdrink 14y ago

Nitro Javascript engine? It could be an important difference between this test and FB's app. Safari gets it. It seems ambiguous still whether UIWebView users get it. A more apples-to-apples comparison would be to put it in a iOS app running UIWebView and see if the performance is maintained. I'd certainly be interested in the results.

hnmullany 14y ago
Performance is also great in a wrapped version. The bottleneck we had to solve was in event management, the GPU & compositor not in the JavaScript execution.
loumf 14y ago
It's not ambiguous. On iOS, only Safari can JIT JavaScript. This is because Apple doesn't trust your app enough to let you made code pages. It also doesn't trust the app it makes when you install a web app to your home page (and it's not just a Safari bookmark). I suspect the latter may change, but I wouldn't count on the former.

spydum 14y ago

I suspect they misunderstood the "HTML5 is not ready" statement. Indeed, HTML5 can perform, and the future is bright. However, as plenty of people in the comments here have mentioned, for mainstream devices.. it's not ready. The frameworks are still coming up a learning curve, the hardware devices out there are still struggling to adopt proper HTML5 support and decent performance. Those points alone lend credit to the fact that it's just not ready.

marknutter 14y ago
Yes, but it will be ready, and the question is will devs and firms that have invested all their time into native development be ready too? It would be prudent to be ahead of the curve when the horizon is so clearly visible.
- mattmanser 14y ago
  It was also clearly visible 3 years ago. It's nice to be an HTML5 advocate, but lets be realistic, it's 3-4 years before HTML5 will be coming even close to native in performance or tooling. In the meantime all those native developers will be kicking your ass in earnings and functionality.
  - marknutter 14y ago
    > In the meantime all those native developers will be kicking your ass in earnings and functionality. There's no need to get testy. There's no reason why HTML5 proponents can't implement some or even all of their apps in Native code (as I do). Without getting into a religious war, though, it's important to understand where the puck is going in addition to where it is currently.
- spydum 14y ago
  The problem with being a platform that serves such a large audience (indeed, one that gets paid based on the eyeballs it can sustain) is that you need to cater to the largest range of devices and their performance. It's the same reason enterprises still support such obscure browsers and OS's (XP/IE6). They just aren't willing to sacrifice the overall experience of those who are slow to upgrade in favor of pushing the technology forward.

tterrace 14y ago

They take offense to Zuckerburg's "HTML5 isn't quite there yet" comment but in order to keep their implementation quick they had to build a custom iframe framework in addition to their TaskQueue and AnimationQueue implementations to replicate the fb timeline. It seems like that was part of Zuck's point - why would a company with a deadline take on all that technical debt to replicate things that you essentially get for free on a native platform?

marknutter 14y ago
You're forgetting one small point: you have to write two (or more) native apps once you go that route. Hence the reason Facebook's Android native app came out roughly 6 months after their iOS native app did.
- tterrace 14y ago
  That's true but wouldn't you (as of today) still be much more comfortable going that route with a non-trivial project? Less time spent on the cutting edge battling the idiosyncrasies of the platform and more time building your app.
  - marknutter 14y ago
    It depends on the resources available. If I were a CEO and the company was flush with cash, I'd just brute force it by hiring native developers across all platforms or farm it out to specialized native dev shops. If was a CEO of a smaller company tight on cash with a bunch of web developers, however, I'd go the HTML5 or hybrid route because it'd be the best utilization of my company's time and resources. This isn't a black and white issue.
    - suprfresh 14y ago
      Definitely agree. I'm not sure why many people think its just so cut and dry. The tradeoffs between html5 vs native are pretty much known at this point. Take those and rationalize along with the resources you have available, the cost, and time you can afford. Just ship something.

level09 14y ago

This is cool, however, I'd say HTML5 has a bright future regarding web-based apps, or apps with a specific use case where you pull some data and display it in a list/table view etc .. HTML5 will never be as capable as native if you have many other use cases (ex: image/video processing, music recognition ) ..

jbail 14y ago
"HTML5 will never be as capabable as native..." I think its very possible to imagine a world where HTML5 can be just as good as native. It comes down to two things: 1) HTML5 needs more JavaScript APIs to access hardware like camera, contacts, etc. It's is not very difficult to imagine HTML6 (if you will) supporting this in much the same way that it supports geolocation today. 2) Improved JavaScript performance. It's common knowledge that the embedded web views on iOS are much less capable than Safari. There's no reason to think this would continue forever. Furthermore, better JavaScript performance makes things like image progressing, music recognition possible. Right now, you are absolutely correct that HTML5 is not as capable as native. No argument there. But, this gap narrows as time goes on. I firmly believe the opposite of you; we will eventually see a time when web-based applications rival native apps in terms of power and functionality. You can already do some awesome image processing stuff using canvas and JavaScript. This is only the beginning...
- camus 14y ago
  3) ditch javascript and replace it with a better language...
- drivebyacct2 14y ago
  1 is more or less already here. Both Chrome and Mozilla are working on it and collaborating on specifications: WebRTC, Mouse lock, Fullscreen, low level Audio creation, MediaSource API for appendByte() style free-for-all video. It's already becoming easier to build interactive rich applications with web technologies. Frankly, most people aren't paying enough attention.
- dotborg 14y ago
  The idea of HTML5 is to avoid using JS in your app.

programminggeek 14y ago

HTML5 is cool and you can do a lot with it, but it has some very real drawbacks - like Android. Also, if you are doing a bunch of optimizations to make it fast on HTML5, then you're basically doing the same work as writing a native app, so what are you gaining by doing a HTML5? Seriously, at some point you can get a better user experience, have better access to native API's and can really leverage the full abilities of the device by going native. So, you know, go native. Disclaimer: I have wrote HTML5 mobile apps and I think it's a great developer experience, but it feels worse as a user.

marknutter 14y ago
But this argument makes no sense. When you go native, you have to write N number of apps for N number of platforms you want to support. The point is that making a great mobile app is hard no matter what stack you choose to use. It's also a bit disingenuous to say you are forced to optimize every HTML5 app. The whole point of Sencha's blog post is to advertise the fact that they've abstracted away all those optimizations you need to do so that developers can focus on building cross platform HTML5 mobile apps.
- tehwebguy 14y ago
  Maybe people that make this argument only care about supporting one (or two) platforms.
  - marknutter 14y ago
    IMO as soon as you want to support two platforms natively you've nearly doubled your work.
    - rimantas 14y ago
      And if you try to support them by doing web based app you quadrupled your work, only it is on the same code base.
      - 14y ago

steffenhiller 14y ago

Here's an interview Robert Scoble did with the guys from Sencha about their Facebook app: https://plus.google.com/+Scobleizer/posts/ZtnZNrCfWv6 https://plus.google.com/+Scobleizer/posts/ZtnZNrCfWv6

andrewmunn 14y ago

I'd like to clarify one thing. The "native" Android app that was tested, isn't actually native. Native newsfeed shipped in Facebook for Android 2.0, but 1.9.2 was used in the comparison. Thus, the comparison was between two html5 implementations of newsfeed. That said, I'd love to see a side by side video with Facebook for Android 2.0.

paulkopacki 14y ago
give the comparison a try. fastbook (the sencha html5 facebook app) is here fb.html5isready.com.

drivebyacct2 14y ago

All the HTML haters (I jest, but that's not a totally unfair characterization of some here) should check out the Chrome team's efforts for Web Components (although I think the name just changed) for Dart/W3C spec, and AngularJS. They make building HTML apps much, much, much more similar to building native applications.

cmelbye 14y ago

Looks and functions terribly in Internet Explorer 10 on Windows Phone 8 unfortunately.

Joeri 14y ago
Sencha's wp8 support is in beta, it doesn't ship until next year.
- smrtinsert 14y ago
  so then its not ready.

umsm 14y ago

I was tasked with creating the phone app for the company I work for. Here are the key points: - The project took 2 months for me to learn the sencha framework AND to build the app from scratch (it's live in the app store). - The app performs well on the iphone 4, but the best performance is on the iphone 4S and later. - The Android version is not as smooth. It's significantly slower. This means it's not truly cross-platform. - People with the iphone 4S / 5 don't know it's not a native app until I tell them.

marknutter 14y ago
Similar experience here. We actually decided to scrap our Sencha app and go with a hybrid app where some UI components were done using native code and most of the app was done in vanilla HTML5/CSS3/Javascript. It's working out very well so far.

dexcs 14y ago

The problem with HTML5 are the different vendors with their different opinions. And that problem will make native apps faster and easier to maintain than html5 for the next few years....

sil3ntmac 14y ago

To me the most impressive thing is that Sencha Touch can run at any reasonable performance level. Has anyone used the framework? iirc there's >1mb debug JS, randomly-generated element IDs, a mess in general. The thing would hang my chrome for a couple moments just to parse the js. Obviously this is solved with minification/dynamic script loading, but Sencha's kitchen-sink approach really doesn't seem to help much in the area of performance.

Joeri 14y ago
You're supposed to use the build tools to generate a file with only the subset you need for your project. By the way, the download time for the native app is also non-zero. With appcache you pay the framework's download cost only once. Admittedly it still needs parsing to load, but i haven't had this seconds-long parsing experience myself in my sencha touch app.
- city41 14y ago
  > You're supposed to use the build tools to generate a file with only the subset you need for your project. Both Ext and Sencha Touch are very monolithic. When you use Sencha Command to pair your app down to just what it uses, it still pulls in well over 90% of the framework.

jacek 14y ago

I have just finished a mobile app in HTML5. Although it works fine on iOS and Android 4.x, it caused many problems on Android 2.x. As Android 2.x still has more than 50% of Android market share it is a platform we cannot ignore. I am sticking to native development for now.

kamjam 14y ago
we recommend at least iOS 5 or Android 4.1 I agree with you. I was going to ask this same questoin. From TFA, they stated above. Well, that really sounds like Mark Zuckerberg didn't know what he was talking about at the beginning of this year! A lot of people are still on Android 2.X as you have stated, and a lot of people are on slow Android devices. I know several people on ZTE Blades running 2.3 which were available over a year ago for less than £100. Sure, not the snappiest of devices, but usable. What is the HTML5 version going to be like for these users? Blah blah blah, hardware limitations, you can't limit yourself to lowest denominator etc. But Facebook HAS to support all these users. And it's not just users in the western world. There are millions of users in third world countries who pretty much exclusively access Facebook from mobile phones, usually not the latest spec (or even close) or most up to date s/w version (I doubt many would even know how to update it). I agree that web apps are the way to go. But it is VERY much going to depend on your target audience.

ttt_ 14y ago

I'll be saying this as a user. I wish most developers would turn to HTML5 today, like right now, and avoid native apps at all cost unless there is really no alternative. Why? Because I remember the browser wars and how much it was a terrible idea and the terrible experience it made for users who simply could not experience the internet from a single starting point. This time it's not simply a matter of downloading another browser, if there's content I want to consume and there's not a native app for my phone, what do I do? I buy a different one? What about the content that I already consume and that's not over there? Should I have multiple phones? I could not care less if it's optimize to integrated well with the native environment or some whatnot, let the browser handle that with default behavior. I want the content, the feature, and not wait for companies to port over apps from one place to the next. This platform cult is pretty meaningless to me, in fact I don't even want to buy any device right now because I'm pretty sure I'll get burned as a user either way. The only platform I'm betting my money on as a user is the upcoming Firefox OS. Hopefuly Mozilla will be able to undo the damage done in this fragmented mess, again.

marknutter 14y ago
Well put. The worst usability problem an app can have is simply not existing.
- millstone 14y ago
  Is an app that you have to fight with really better than no app at all? If it didn't exist, at least you wouldn't have gotten in a fight! There's many sites that I consciously avoid on my phone because they work so poorly that I don't even want to bother. These sites do mobile users no service by existing. An app or website has to at least meet the "user will tolerate it" bar.
javajosh 14y ago
I was with you until you said "This platform cult is pretty meaningless to me." Actually the platform wars are quite meaningful insofar as they represent large-scale manipulation of consumers. Both Apple and Google are playing the following game: hey consumer, here's a shiny device, it's pretty cheap and then we lock you into a 2-year contract, meanwhile you acquire apps that can only be run an iPhone, and now even if you wanted to go to Android, you are faced with the prospect of ditching your entire software library (or vice-versa). It's called lock-in and it's a long-term manipulation of a market. I'm sure that both Apple and Google rationalize that it's a way to recoup R&D costs, and that's true enough, but it's a sneaky way to do it. There's also the not insignificant problem of app security. Not so long ago there was a news item about the FB native app accessing contacts and uploading them to FB servers. The web app cannot do that, and that's a Good Thing. There's also another reason why HTML5 apps are better than native: they are composable. There isn't much out there other than search engines that takes advantage of this fact, but webapps can be composed, parsed, and otherwise uniformly manipulated in useful and interesting ways. Android and iOS do indeed offer some integration points for their native apps, but nowhere near at the level that the web allows today.

rodion_89 14y ago

A couple of months ago I mentioned these same notions about the Facebook app. http://jairaj.org/2012/08/27/facebook-for-ios.html http://jairaj.org/2012/08/27/facebook-for-ios.html Although I have to admit that Sencha's implementation isn't all that great. If you're going to offer an alternative, at least make it better than the other option.

herf 14y ago

If you insert a big image into the DOM, MobileSafari locks up for quite a few frames (whether or not it's preloaded.) Sencha's implementation just swaps pictures when you're not doing anything else! But most native apps can update photos while you're actually scrolling around.

TeeWEE 14y ago

Good work. But they are cheating in one main spot: - they use a proxy to cut down data transfer Good choice, but comparing it with the orignal app is not valid anymore (its not really html5 that is making it faster) Anyway its still a very fast mobile app, and html5 is sometimes the best choice to make. Because it is very expensive to write a different app for all platforms currently. However, currently, it is also very time consuming to have a html5 app that is on-par with native, and works well in both android and iphone. So its a tradeoff really, html5 is not better than native, or vice versa. Like so many things in life, it depends :-)

joshtynjala 14y ago
> comparing it with the orignal app is not valid anymore Facebook could have done the same thing with their app too, so I don't see how this affects validity.
- TeeWEE 14y ago
  If I am comparing the speed of two cars, but one car contains 5 persons while the other one only contains 1, then it's an unfair comparison right?

eblade 14y ago

It started with the implementation of an Infinite List Component that handles items with unknown sizes. Only a very small set of DOM nodes is actually created to fill in the actual visible screen area. They will then be constantly recycled to render next / previous data on-demand. As a result, memory footprint is kept minimal, regardless of the amount of data in the Store. Making this work is the easy part. Making it fast with the complexity and variety of items such as News Feed stories is the real challenge. The bottleneck lies within the core processes that a browser has to perform: layout and compositing. I wished jQuery Mobile has Infinite List Component that handles the list item recycling the last time I used it. It is the equivalent of UITableViewCell's dequeueReusableCellWithIdentifier.

u2sonderzug 14y ago

Looking at this from a different point of view maybe altogether, one of the big issues I think concerning HTML5 mobile web apps (not used in a native app wrapper to get included in the appstore) is discovery. Where do I actually find compelling mobile web app user experience when I am trying to solve a problem in my web browser as a user when I search using a search engine? I noticed a few years ago that Google cut out their mobile only results option - and now when you search for anything on a smart phone you get a mish mash of mobile friendly and conventional web optimised results. For a little while there Google would put a little mobile icon next to mobile optimized results - but that has gone too. I know perhaps the point of mobile is moot now - since we have a sizeable amount of tablets accessing websites too. But just in my own personal research all my friends who aren't techy say they much prefer sites that look right on their 'touch' (be it mobile or tablet). For instance, is there even such a thing as a 'mobile web app store' out there? If consumers had an easier way of finding great mobile web apps perhaps this would grow this channel? I'd be interested in perspectives on this - maybe I'm looking at it the wrong way. I'd also like to make the case that I think HTML5 will continue to make a very important contribution moving forward - why? Because as we get more devices, it's really starting to get silly how many apps I constantly need updated and feel like I need syncing. I think as prices come down we will find ourselves with several devices for home, out and about and at work - using the 'fat client' model of installing all these apps just gets annoying.

deleted 14y ago

[deleted]

iiid 14y ago

I agreed that writing app in HTML5/CSS/JS is easy to mantain. But why not get access to those native features too? Hybrid apps seem to be very logical way to build apps now. Take a look at many emerging services like http://trigger.io http://trigger.io and get the best of both world.

tagliala 14y ago

IMHO if in 2013 a HTML5 application needs iframe + js proxies hacks to perform faster, there is something deeply wrong. Sorry for my English

madoublet 14y ago

I think the problem with HTML5 is that Android and iOS treat it like a second class citizen. For all its faults, the one thing Windows 8 got right was that it allows developers to build native apps using HTML5.

chrisringrose 14y ago

I'd say the problems the Facebook team ran into were related to the universal difficulties of HTML5 development. The tools are nothing compared to native app development. In making native apps, developers can visually create the GUI, double-click an element and immediately program its response. But with HTML5, everything is done programmatically, with great pains. When you run into problems you have to debug JavaScript, CSS, HTML, and any client libraries, possibly written in yet another language. The tools just aren't there, so continuing to maintain an HTML5 app that performs quickly and nicely like "Fastbook" does is far too costly, considering how much more easily a native app can be created and maintained.