Shared publicly  - 
Sencha demonstrates HTML 5 can be faster than native iOS or Android apps (Facebook example)

You've heard that Facebook switched from HTML 5 to "native" apps on iOS and Android recently to "speed them up." That pissed off the developers from Sencha

So they built a Facebook app completely in HTML 5 that's even faster than the native Android and iOS apps that Facebook released last week. 

Sencha builds HTML 5 programming tools and here we discuss the market for app developers and the choices they have to make. Later today I'll be at Facebook and will ask them more about why they can't match the speed Sencha displays here.

This blew away many of my assumptions of native vs. HTML 5 and proved that I was wrong when I said that the reason Facebook's app was faster was because it was native. 

Did it change your assumptions?

Attached here is the video I shot at my house on Friday. 

More from Sencha: 

- Sencha's own Video:
- Fastbook App:
- HTML5 Is Ready App Contest:
- Blog post on tech details:
pawan dadhich's profile photoMikkel Johansen's profile photoZAchary Indy's profile photoChance Roth's profile photo
+Robert Scoble Isn't it still possible though that Facebook might also be able to do a better job at making its native apps more efficient and faster.  It seems intuitive that there should be an advantage for a native app. I look forward to hearing how Facebook answers your questions. 
Bad developers can make a good technology look bad.  HTML5 is a primary example of bad devs making a good tech look bad.
Great demo, but please note that Sencha's terms allow for only 5000 packaged app installs (e.g. using PhoneGap) before fees kick in, and those fees are on a "call us" basis. There's no explicit sliding scale. This negotiation-based sales model is prohibitive for small startups.

Sencha is welcome to correct me if I'm wrong about that.
Looking at using Sencha myself, anybody got dev feedback on these guys? Ease of use? Features?
+Euro Maestro eventually, you reach one of two points:

1) You've optimized so much that any further optimizations are imperceptible to the end-user.
2) Something which cannot be optimized by the programmer, such as network access times, become the primary bottleneck.

If Sencha can keep up with Facebook in terms of both raw speed and perceived speed (ie, how fast it feels to the user -- this is a lot less tangible) up and including to whichever of those points arise first, they're effectively on-par. Beyond that point Facebook would be "overengineering," as it'd offer no noticeable change.
Let's not steer this discussion away from how performant HTML5 can be when used right. This is great for all the web as a platform group. Nice work Sencha.
 +Michael Mahemoff 
+Michael Mullany Yes, I remember reading the fine print in a contract about embedded apps. I really couldn't find any detail about their definition of that and whether it includes PhoneGap style, and since I couldn't find any info anywhere else about PhoneGap style, I assumed that's what it meant. (As opposed to running as regular web apps for browsers.)
Wasn't the issue with iOS apps - HTML5 cloud VS Local Apps - created when Apple themselves said almost a year ago said that iPhones are built to give preference to local apps rather than cloud based data that just uses an app wrapper to create the app and shortcut +Robert Scoble?
+Joe McCann True it's a great demo of HTML5's potential and also a great demo of Sencha's capabilities. Indeed, my main point was that Sencha's library is so much better than any liberal open-source library, that it's pertinent to be aware of who in fact can realistically take advantage of it. (And I made this point mainly because I know +Robert Scoble pays close attention to startup development practices.)
Hm, i get the feeling HTML5/native code has nothing to do with the facebook app's speed. Their infrastructure sucks and their queries are slow, that is what makes their apps lock up and be slow as molasses, the UI code i would think makes little difference in this other than image optimization. My two cents anyway
+Robert Scoble Your comment above is the perfect example of an app that would take advantages of the handset local features and then, bring the data in from the cloud.

Good example is Android local data that when changing phones can be lost. I prefer to keep the data and content in my apps on my server as much as possible.
+Ramsez Stamper I would say that has more to do with Facebook always being low on server resources since the rent most of their datacenters and costs are high for a top site with that much traffic.

Scoble will tell me if I am wrong but does FB not spend 30% of it's income on datacenters?
+Robert Scoble My point though is how much of this improvement is due to the advantages of html5 and how much is due to the crack programming of Sencha.  If they developed a native app would they have a similar improvement.  Generally I tend to prefer the native experience, don't you ? 
+Robert Scoble we developed both our Android app & iPhone app using Phonegap. We invested quite a bit of time improving the performance just like we would have on native apps I believe. 

An important note is that our HTML5 apps feel native on the iPhone 5 and just fine on lower models. So I'm not sure the debate will stay much longer as phones are getting more powerful and the 4G coming out. Soon apps will be great because the idea behind them are brillant rather than our how good the performance are.. As it should be.
I remember meeting someone from Sencha (not sure who) at the WIP "Muther of all Hackathons" last year at the Computer History Museum. Loved the way he talked so passionately about HTML5 and mobile. While I have personally gone back to native, I think its only a matter of time before HTML5 becomes adopted widely enough by developers.
+Euro Maestro HTML5 has nothing to do with speed, in fact Phones run HTML 5 better than any browser. Most apps that are embedded take advantage of that as well. So you are running HTML5 be it locally or from the cloud.

So yes, it is Sencha's clean code, fast executing AJAX JavaScript and lack of memory leaks + stout server resources that create the speed.
The problem is not that native vs html5 is necessarily faster or slower, it's that their html5 app was crap, and didn't consist of much more than just reflowing the (already terribly coded) touch.facebook page.
+Robert Scoble But no matter how much code runs locally I don't see the UI being faster no matter how the app is written since you are still pulling the data from Facebook's distributed data center model.

Local code or not, 99% of the app still comes from FB server.
Keith H
Politics and Bull$hit. Just an example of good use of a framework vs possibly poor optimized native code use. The scale can turn either way...Really don't matter to me a long as the end user is happy with the software used. Facebook ha!
It's ridiculous. How can anyone claim HTML 5 with it's wrappers can be more efficient than a native application?
It just means that the Facebook native app is crap.
+Robert Scoble totally agree ! Facebook was looking for an easy explanation about why they had an application that wasn't performing. 
Problems: 1, performance isn't the whole story. There are large numbers of interfaces not available to HTML 5 "apps". 2, Faster at what? Loading over a slow link? Probably not. 3, It's only Facebook, so really not worth throwing a lot of technology at...
HTML 5 is like any other technology. If the developer doesn't use it right, the result will suck. Glad these guys prove that Facebook is wrong about HTML 5.
+Robert Scoble are you sure? That sounds like a statistic that couldn't possibly be verified. I'm guessing that the mail client or Web browser are used more often. Of course, soon it will be #ingress  ... ;-)
I found sencha to be a steep learning curve and eventually tossed it. Couldn't get it to play nice with Spring MVC. 
WOW! it really is faster than FB's native android app. Amazing.
Doesn't seem to be a technology problem than a developers one! Those guys are gurus and know how things works, good job 8)
Maxx D
Just because they spent enough time hacking it doesn't mean it's a good platform. (iframe based DOM "sandboxes" just to get enough performance to not suck?) If I have to use ridiculously complex, webkit only frameworks to meet what I get with little time and effort for native performance, it's still a terrible application platform. Facebook, as an application, just isn't very complex. What they are describing as having to go into it just to achieve this is silly.
Maxx D
If anything, this proved to me that HTML/CSS/JS is a mess and it's time for change.
+Robert Scoble How long did it take them to make the app? Mind blowing. I have more confidence in HTML5 actually doing away with native apps in the future.
What many fail to understand, the cause of performance issues in code is rarely caused by the development language used, rather the coding standards of the developers. It is much more likely the the old Facebook Application adhered to poor coding standards.

I have seen countless HTML5 Applications that stress the boundaries of what a web page was designed to do, I would go as far as saying the HTML5 should be the death of most native applications in the future. 
HTML/CSS/JS is only a mess if you have to support IE.  Kill the Explorer!

other than that, I agree with you.
I can spot HTML 5 app on Android after first 3 seconds. You can accelerate it until you blue in the face the smoothness of animation will never match the native platform.
Native apps written by a competent developer will almost always be faster and smoother then HTML 5. The example in the video above is not a clean comparison of A vrs B.
HTML5 is a nice idea, but currently stands as not much more than a broken toy. The situation with audio is unbearable.
+Robert Scoble please get a boom mic or clip mics for your guests. Damn trying to hear your interviewees is painful
Seriously though, who wants to write a very complicated business application entirely in JS? What a maintenance nightmare. 
Maintenance cost is reduced dramatically using dependency injection and actually testing.
So, um. Tried out the app they've linked to in the article (on Android 4.2), and the response after a touch is slightly laggy (not bad, though). What's worse is that the scrolling stutters and sometimes jumps. Mind you, so does the FB app, but on the whole it was still a little better in my "test" (I use the word loosely, as owner of a QA company I feel I have to point that out).

But considering the effort described in the article, that is not exactly a convincing argument for HTML5 or Sencha.

[Still, it's one of many arguments that can be made. This one is just happens to feel a little forced and/or weak.]
Surely it depends on the connection speed to some extent!
Glad someone did this. It is about time people stop putting down HTML5 I've had no problems working with it. the only real issue facing HTML 5 is stupid stuff like Safari browser not supporting everything. I tend to have less issues with chrome, firefox, IE9 and Opera. 
+Angela Hey, actually, you'll find it doesn't rely on connection speed much more than the native app.  Connection speed only affects data downloads, the page rendering and construction is all handled on-phone, whether it's HTML5/JS or native.
+Alexei White - It is much easier to find JS developers then it is to find Java/C Sharp Developers
To me it was about the same. And this is not valid. Ones a app the others a web page
It needs a native browser so that statement makes little sense.
+Keith Myers Yes, but few of them would be able to pull off what these Sencha guys did. If you have a guru to offset that, you're golden. They're hard to find, though.
I've been a developer for 20 years professionally, and almost 30 years in total. I would never use JavaScript for any serious applications or for anything that is beyond 'small'.
As usual marketing guys don't know anyone at the company. 
Talented programmers never get the good jobs. Dure to the poor management in IT. Even if those guys worked at Facebook. They probally would not be able to implement the code they develop to speed up the Facebook app. #PoorManagement
+Keith Myers, as soon as you find some JS developers, could you point them my way?  We've been trying like crazy to hire more, but JS devs are hard to find here in Silicon Valley.
Am I the only one that doesn't like the way fastbook does the scrolling?
I thought the whole advantage of native (android at least) is that it's able to load the posts and pictures in the background? 
+Mike McElroy 

Are you using consulting/contracting companies to help you look for developers? If so thats your issue. 
Maxx D
To restate it another way: If a platform requires a team of top tier expert developers working around the limitations of the platform to match what a team of average developers can do with a stock platform, then that platform loses.

If I put top tier developers on a platform and unleash them, I expect amazing results, not status quo, and these guys had a personal mission from God to prove themselves.

Every ounce of expertise and skill used to work around the limitations of the application stack are lost to work on the business problem. I don't want developers spending time and creative energy working around the stack. I want them focused on the product. The fact that a team like Sencha manages to do so does not speak well for the platform, it speaks well for the skill of the team.

Imagine what they could do if they spent this much time and effort on a platform that didn't start them in the red.

iOS: +1
Android: +1
HTML5: 0
+Phillip Vinson, nope, trying to get word out through our in-house recruiter, going to meetups, networking, job site, etc.
Randy H
Native Facebook and google+ apps are both slow and stick....
Looking back, html is becoming what the X window system over tcp-ip always was. It just has a kludgy on-top layer.
To me, there are 3 considerations when choosing an application:

Does it do what I need?
Does it do it fast enough to be useful?
Does it do it under all the circumstances I need it to?

I've been writing and using software for 35 years. Virtually everything I've done has been native code, but I've seen enough to convince me that we've reached the point where native code should be used only after demonstrating that it's actually necessary. 
Surely when the Fast book page is loaded in an iOS UIWebView it will be slow again because it won't use the nitro JavaScript engine?
+Maxx Daymon I agree with your point completely.  And yet:

- There is value in standards.  Writing an app once for HTML5 conserves engineering resources when compared to writing it for iOS/Android/Windows.

- We've been down this path before with desktop computers: it takes a while for hardware to catch up with the latest and greatest software tools.  But it always comes around.
+Stefan Zager +Maxx Daymon, not to mention the benefit of being able to roll out updates to your app without dealing with the App Store's censorship process.
+Mark Stevens most of the performance that was worked around is due to rendering -- CSS and styling. The JavaScript side of it plays less of a part than most people realize. 
This is a great effort, and an excellent demonstration of what can be done in HTML5 but if you read into the time and effort it takes to achieve the performance they're showing, the argument is in favor of native. I've developed apps and games in HTML5 and yes you can get decent performance, and sometimes it can be comparable to native, but the amount of optimizations, and performance techniques you have to do to get there makes building native seem like a much better choice. On my Nexus 4 their demo FB app still has janky scrolling despite all the optimization. HTML5 still has loads of potential, but I believe the performance needs to be worked out in the browser, instead of trying to work around browser performance issues with hacks, development best practices, performance techniques, and other workarounds. After all the time and effort you sink into an HTML5 project of a decent scale, you always ask yourself, was it worth it to do it this way?
What does HTML5 offer in terms of audio buffering?  (This is still why we use native iOS code).  But if HTML5 drafted an audio buffering spec that worked for Firefox, Chrome, Opera, etc. that is not icecast-based and has the same capabilities of Flash, then we'd pay more attention to Sencha.
Woah, this is a incredibly misleading and a bit of an infomercial for Sencha. He's demoing an app running inside Chrome on Android. Yes, Chrome is awesome and fast. The problem is when you want to use a WebView because you need access to non-html5 android apis (like NFC for instance). This is what phone gap does for instance. Not only does the WebView not run chrome, and it's much slower and there's a different version running on each version of Android. This is the real problem. If Android's webview was using Chrome, things would run much better. I get the sense that the Android and Chrome teams share a different view of the world though.
+Mike McElroy Whats the pay look like out there. Last I looked it wasn't much any better than in Texas and well the cost of living is a lot more not to mention the nasty issue of state income tax. If I just looked at it from an economic stand point to have the same thing I got here I would need a lot more pay. Which is why I left California to start with. 
The fact is, Facebook for iOS became so much more pleasant to use after switching to native code.
+George Hayes, Can't speak for the industry as a whole, but six figures and very generous stock options are not uncommon for reasonably good web devs out here.  To say nothing of benefits.
Maxx D
+Stefan Zager Agreed, there is value in standards, and the web browser as a platform is necessary, important, and relevant. That does not mean that there isn't value in more power-efficient stacks from competing vendors. Also, we need a least-common-denominator platform to reach the broadest audiences possible, and one that allows us to deliver ephemeral applications to users who otherwise don't want a persistent footprint on their devices, or have low-power/low capability devices. That being said, I still find the web stack to be lacking even at doing that.

As to the resource question, if you have 10 million users (or even 100,000), the resources to write one app or three is irrelevant (even not considering shared server-side code). Still, there are plenty of cross platform frameworks for back-end and view logic, requiring only platform specific view customization. And if you can't afford a couple UI platform specific front end teams, how much is your product really worth? Apple users bought iOS for the iOS experience. Android users don't want the iOS experience. Writing generic UI for no platform in particular helps no user.

When the hardware catches up (but remember that battery technology isn't benefiting from anything like Moore's law), the web stack will finally be able to run 10 year old apps as well as they ran on 10 year old hardware. What will native apps be doing with all that new power, and where will the bar be for those? For example, by the time you can play Call of Duty 4 on the web, native games will be lifelike/ray-traced. (Case in point today: Quake finally runs at almost 60fps on the web stack while native apps are running Call of Duty 4 on a Core i7.)

Why don't we have an actual view language as part of the web technology stack? HTML is not (and should not be) comparable to XUL, XAML, MXML, Glade, etc. Why do we have to implement such things in terms of the broken underlying model?

Also, why hasn't JavaScript been replaced with a common LLVM/JVM/CLR type of intermediate language upon which languages can be built so that we can choose the best language for the job? We should be pulling jquery bytecode, not minified javascript. We should be able to type <script type="text/scala">.

I commend every web developer for doing the best they can (and sometimes amazing things) with a mediocre set of tools. Still, the web seems to have a special low bar, and celebrating things like this just perpetuate the problem of low expectations. We need to demand much more if we want the web to be what it could be. Maybe we're just too used to "giving everyone a gold star" to manage that.
Seems pretty slow to me still. Html5 has little to do with Facebook s performance. It was badly written full stop... Building the g plus app in HTML 5 then we'll talk
As someone who has built a data heavy enterprise application with Sencha Touch 2.1, I can say that this solution is by far the best HTML5 MVC architecture around. 
I think native apps still have an advantage over html, and it's purely from business reasons.

The video they have is very impressive but if you actually play with the app on Android it shows a lot of rough edges.

Some oddities that I noticed include:
1. The stream scrolls is not 1to1 with your finger like a normal scrollview in Chrome but it is in the default browser. Kinetic scrolling isn't as good implementations of native scrolling.
2. The HTML5 has an Android and iOS specific url. At least some of the code is platform specific so this isn't a holy grail "write once, run everywhere" solution.
3. Swiping left and right animation doesn't actually animate. It just switches between 2 states on Android.
4. Pinch-to-zoom doesn't block the panning action. You almost always end up doing both at the same time which is annoying.
5. ScrollView within a ScrollView doesn't work. Example is comments and Likes section of a status page.
6. The app doesn't and can't use the native FB app signin that doesn't require your to type.
Honestly, I think someone who really likes/works for Facebook made those claims and everyone jumped on because Facebook usage is going down. I almost updated to check it out and then I realized life was in front of me and it was more interesting than a Facebook app
HTML5 done right in a app is great - wrong - and it just becomes a webview.
+Phil Merrell 1st, Sencha is selling a product. They have an agenda just like native developers do. I think it's perfectly fair to point out their flaws.
2nd. Your comment about Android shows that you are ignorent and haven't used Android in the past year or longer. The G+ Android app is one of the best apps I have ever seen on any platform.
3rd. I can't respond to your last critique because we've already established that you are ignorent. ;)
+Akshay Pant You can "get your hands on it" at that url. Unless you meant the framework, in which case you can check that out at They have the best "cross platform development" tools that I have seen. But I'm still a native guy.
It's just me thinking that although the devs have very strong points, the marketing guy (don't even remember his name) is bs'ing each and every listener?
+David Shellabarger Not to defend the app but after wstching the video I believe the different urls are about making the app styled to look like a native app on both iOS and Android. 
Well you know that is kinda messed up to me to
Very impressive. Do you think that frameworks such as these (and the obvious power of HTML5 application development) may help Microsoft gain back significant market share in the mobile space? If they focus on producing applications for the desktop using an HTML5 framework that they can then port seamlessly to their mobile platforms? (Despite myself I was impressed with the Surface when I had a chance to play with it this weekend)
Yeah tried. The existings are still faster have have a nice polished look. It was quicker but not quite there. Imo
Kin Lee
If you've seen the number of complaints about the Android FB app, it is no surprise.  If I bothered to compare it, I can probably find it faster surfing FB on the buggy built-in browser.  At least all the functions appear to work on the web portal.
So, I use sencha daily and I've coded in both HTML5 and Native. There is a difference. Honestly, I've been able to build a responsive and beautiful app in about 3 days with objective c. With HTML5, get ready for weeks of frustration and inconsistency.  
nahh. just checked. the native still buttery faster. 
thanks to the sencha guys for making a stance for html5
Html5 is nice, but not native nice. It's closer on iOS, but input still lags on Android.
You lost me when I clicked and saw the video was 35 minutes long.
I want the sencha facebook app :) 
Ja nevolim da postim a u zadnje vreme sve vise postim :-(a postim uvek kad nemam;-)
Sencha rocks! We just upgraded to Sencha 2. Native dev implies vendor-locking. Cross-device means business flexibility. I vote for freedom of choice
+Robert Scoble But now can people monetize from web apps?  collecting 70% from the app store and the ability to promote it is still better than having no viable way to monetize.  This is the part where I'm confused about the incentives to write a web app.  Maybe someone can shed some light on this.
+Eric Lee developers can wrap their html5 app into a native app using phone-gap.
Thanks for reaching out +Andrew Chooah, added you to my coders circle, seems you may have the skills to answer my questions above.

+Robert Scoble You seem to have misunderstood my questions and points. But that's ok, looks like Andrew can help me from a programmers stand point.

Guest it would have helped if I had an iPad and used Facebook much so trying to understand this is maybe a little hard.

As far a HTML 5 goes, what problems besides audio are you having in "Apps" - Not the browser, but true Apps. I get such bad complaints on Web Apps just because it is in a browser that I build web apps from the server, then wrap them in a few lines of code to create an installable app.

I get the same "But it's not an App" complaints any time I suggest someone use a Google TV optimized Web App. Just the idea of using the browser somehow brings a lower perceived value. Even though the browser can deliver the same UI experience as a installed App.
+Robert Scoble Some of the slowness in the old Facebook app came from Facebook disabling web cache in their Three20 UIKit for iOS and their old SDK wasn't taking advantage of Grand Central Dispatch.

It looks like these guys are optimising the facebook's feed before it gets to the device, Facebook's graph API feed is quite bloated at times.  Less data faster feeds :-)
+Chris Lang You may be on to something.  I know that I definitely have a bias towards native apps but it might be because I have not yet experienced a well designed and high performing web app. 
A well designed native app will always be faster than a equally well  designed HTML5 app, but a badly designed native app will be slower than a well designed HTML5 app.
+Euro Maestro  One of the problems is that people assume how things work based on prior experiences but mainly on  what other people tell them.

Progress isn't made until people experiment, the more people that disagree with you the more likely your close to  discovering something new.
Just tried it on iPhone 5, two things:

1) Scrolling feels much better in native app. HTML5 has always struggled with scrolling and this app still feels like a HTML5 app.

2) Native app caches more. As you are scrolling native app shows more thumbnails and images whilst HTML5 are blank.

These are just two initial observations that are immediately apparent. Why would a billion dollar company like Facebook want anything less than the best user experience?

However, HTML5 is our only hope for true cross platform compatibility so I hope one day the standards, implementations, and frameworks get there. 
Just heard that LinkIn is also going from HTML5 app to native App. Maybe they should talk to +Sencha :-)
HTML5 cant do all the stuff that the native development do,.
Sencha can make a desktop application with HTML5/JS . But , can it access the Registry on Windows? Native Process? Doing Concurrency? 
Well the term "Cross Platform" development is a hard work that until now NO ONE of the big guy even Java based technology can achieve this goal.
"write once , runs anywhere" -buzzword will never be reached , especially if you want to access the lower level API on the specific platform. 

for hard tasks that consume low level API, native still will be the best,.. 

oh wait.. you talk about speed? HTML5 is faster ? you kidding me... :D
Seems like the demo is now broken...please fix. I wanna see this work on my iPhone for myself. THX