When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.
So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.
We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. 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. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.
“So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.”
We had our suspicions about why Facebook’s mobile application team had problems, because it matched a common pattern. At Sencha, we build frameworks and tools for application developers, so we have pretty deep experience with development teams taking on HTML5 app projects. When a team has problems with HTML5, it usually stems from the fact that they take a “website” development approach to building an app, and often don’t use the right tools and architectures for application development. This is what we suspected about the Facebook HTML5 app. The way that app performed — slow loading, choppy user experience in the News Feed, low framerate — exhibited the usual symptoms.
In any event, we knew HTML5 was, in fact, ready, and we wanted to prove it. So we took it upon ourselves to rebuild the challenging parts of the Facebook mobile application in HTML5 in our spare time. Today, we’d like to introduce you to Sencha Fastbook, a technology proof of concept that shows how fast HTML5 can be, and demonstrates how readily HTML5 can be used to handle the toughest app challenges.
Learn the latest about Fastbook and the tech behind it at SenchaCon 2013. Register today!
This four-minute video gives you a quick overview of Sencha Fastbook, and shows you a side-by-side comparison of how well our HTML5 app performs against both the native iOS and the native Android Facebook apps (versions 5.2 and 1.9.12 respectively, the latest available when we made this video on December 10th). The rest of this post gets into the technical details of how we built Fastbook.
A Closer Look at the “Native” Facebook Application
We started the process of what became Fastbook by trying to understand the Zuckerberg claim that HTML5 “just wasn’t there”, and the best place to do that was to take a deep look into the latest native Facebook app on iOS. We connected an iPhone to a web debugging proxy, and started to look at the HTTP traffic the application pushed over the network. Our biggest shock: much of the application was still raw HTML pages. The News Feed had moved to native as had the profile page, but many of the other application UIs were simply HTTP GET requests to m.facebook.com. Today’s “native” Facebook application is a hybrid web / native application: there is content rendered on m.facebook.com and displayed in a UIWebView and native Objective C components mixed together.
Re-Implementing the News Feed
After we looked at how the native Facebook application worked, it was clear to us that the hardest part of the experience to build was the News Feed. Dealing with a billion content creators posting an unlimited amount of content in a completely unpredictable manner is a tough problem to solve even for the most seasoned developers, regardless of what technology they use.
We really wanted to ensure we had that smooth experience the News Feed should deliver when we re-implemented it in HTML5. To make that possible we added some new features and enhancements into the core of the current Sencha Touch framework.
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.
Our experience with building frameworks has taught us that while a small demo component might work well on its own, it often then performs poorly when put into a much larger app. As an app grows, the DOM tree grows; and as the DOM tree grows it takes longer for the browser to calculate the layout, and the performance degrades. Moreover, as the number of visible layers increase, compositing performance for each layer also degrades dramatically. We needed a solution to make web apps more robust under large numbers of DOM nodes.
So the Fastbook app is the first to make use of a brand new “Sandbox Container” which programmatically detaches complex views and renders them into their own iframes, and thus partitioning the DOM tree. This special container doesn’t need any extra handling at the application level, so it’s seamless to developers (i.e., any component added to this container will be sandboxed automatically). But it does come at a cost: events, positioning, styling, and JavaScript code have to be proxied between the parent window and the child sandboxes. This is complicated, so without a robust and properly architected framework, it is very difficult to implement. Sandboxing allows layouts to be isolated, and therefore keeps the primary DOM tree as light as possible. To bring balance to the Force, Sandbox Containers must be used wisely.
For Fastbook, the News Feed, Timeline and Story views are individually sandboxed. Since all DOM elements are re-used to render data on-demand at high frequency, reflows are inevitable. The key is to make that process as cheap as possible. Sandboxing enables the News Feed to perform as if it is standalone, while actually is still a part of the much bigger DOM tree.
“Sandboxing enables the News Feed to perform as if it is standalone, while actually is still a part of the much bigger DOM tree.”
Next, we added deeper integration to our TaskQueue, a feature we recently introduced into Sencha Touch. TaskQueue prevents the interleaving of read and write requests to the DOM, eliminating any unnecessary layouts. This, combined with the new sandboxing technique, significantly reduces costly layouts from complex views such as the Timeline and News Feed.
We then added the AnimationQueue, a new class that’s responsible for all animations and events, as well as scheduling heavy tasks for later execution during the CPU’s idle time. It acts as the framework’s traffic cop, prioritizing different operations and helps ensure the application stays responsive. When an app is animating, it suspends lower priority functions. When the app is idle, the AnimationQueue executes the suspended tasks. For example, while scrolling the News Feed at high speed, image loading and rendering is suspended until the app is idle in order to increase the scrolling performance. Additionally, heavy tasks are released gradually in a non-blocking manner with a high-speed timer. This ensures touch events always have a chance to be handled as soon as possible.
On the other hand, there are some classes of functionality that you don’t want to suspend, such as getting more data to feed the list. To help ensure this doesn’t slow down scrolling, we use Web Workers. These allow us to move XHR/RPC communications away from the UI thread. Saving network request cost and JSON encoding/decoding using Web Workers makes great use of today’s multi-core devices.
Those are the major points of what we did to bring Fastbook to life, and what allows it to perform well with pure open-standards based web technologies. It’s exciting for us to be able to show how you can leverage all the features of HTML5 to build an app like this.
Bonus Points
One of the interesting things we found while investigating network performance of the native iOS Facebook app was that the API calls returns huge amounts of raw data to the client. A typical example is API calls made to https://graph.facebook.com/graphql/ to render News Feed items. In average, 15KB to 20KB of gzipped JSON data is transferred for every 10 items, much of that is not needed to render the actual views.
To demonstrate what could be done to optimize network transfers, we put a proxy server in place to clean up and parse the raw data returned from the Facebook FQL API. As a result, Fastbook transfers far less data than the native app to render the same views: as little as 10% to render the same items on the News Feed. The proxy also allows us to offload some of the more mundane tasks such as content formatting and filtering to the server-side.
Also, you may notice a difference in the scrolling deceleration time between the native iOS app and Fastbook. In the native app, scrolling doesn’t stop for about 3s. We decided to increase friction and reduce the animation duration to 1.4s. This not only makes content ready to read faster, it also provides extra idle time for the app to buffer more items while the user is still reading existing content.
Try It Yourself
Fastbook isn’t a replacement for the Facebook application. It’s a technology demo that shows what developers can do with HTML5 if they take the right approach, and use the right frameworks and tools. If you’ve been wondering if HTML5 is ready, try Fastbook for yourself on a modern smartphone (we recommend at least iOS 5 or Android 4.1). You’ll see that when you treat the browser as an application platform and leverage the features of HTML5 that even the most sophisticated applications can be made with HTML5.
This is simply awesome! HTML5 was dealt a huge blow by Facebook’s CEO earlier this year. It’s kick-ass that you guys are helping the HTML5 community move BEYOND the comments that he made. This truly shows that mobile HTML5 *is ready* – if you know how to use it, that is! Keep kicking butt, Sencha!
A brilliant display of what HTML5 and Sencha Touch 2 are capable of. It’s just unbelievably fast.
This example just boosted my motivation for another ST2 project I’m currently working on :)
Couldn’t love this more. Incredible work guys!
This is fantastic stuff, nice work. I’m very much pro-HTML5 and have heard a lot of people recently try to counter any arguments I’ve made on the basis that if Facebook couldn’t get it to work, what hope has anyone else. This is just the kind of counterstrike the Web App dev community needed! Thanks Sencha.
I wanted to do this since Facebook released the native app.
Great work guys!
Added this to Hacker News: http://news.ycombinator.com/item?id=4932196
Also, for the record, here’s the under the hood story from Facebook rebuilding the iOS app:
http://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920
You’ll see that they had to do quite some optimizations with the native app as well.
I’m not entirely convinced. A lot of the “features” are functional design decisions rather than technological capabilities or differences. As far as my facebook app is concerned, that data does persist among states, and is extremely fast not showing the hesitation as demoed. Though they showed the Facebook app “that was available at the time”, they needed to upgrade to the latest Facebook version just before making the video. When making an app development decision, I’m not going to compare to obsolete implementation.
Also, they did not show the app as it loads, but after all data has downloaded already, so of course it’s going to be faster “load” time. How long does it take to load?
I could not regard this unless a third party does an independent evaluation.
The demo is really promising, but it is in MobileSafari. When you make an iOS app, you can only use WebView, which is a second-class and slower browser.
@hlb the issue is NOT JavaScript. It’s the DOM. The DOM engine is the *same* for both use cases.
Great job with the HTML5 App. FYI, the video has audio but blank video when viewing on the iPad.
Great work!
Is the “facebook drawer” code available somewhere? This is a must have addition to Sencha Mobile.
Guys, this is awesome. Just tested it on my iPhone, and works almost better than the native one. It’s an incredible great job.
@JayGarcia, I believe JavaScript engine performance will affect the rendering speed a lot, no? Really hope Sencha team can release a wrapped iOS app demo as a proof.
@hlb Simply save the app to your homescreen to force it to use a WebView.
Great but you dont have to handle +500 million requests ah hour on your servers, so that’s cheating. The app doesnt feel smoother on Android < 4 , though it is fast on iPhone
@Claymore, they are using the facebook API. how does your argument hold any water?
Leo – interesting perspective, but you need to understand how the Sencha framework works to see that HTML5 is going to be the winning standard. Anyways – this is a great demo of what can be done and highlights how Sencha keeps helping the developer community with adding new tools to our bags like TaskQueue and AnimationQueue. Next I need to dive into Sencha CMD :)
@JamieAvins thank you for answering my question! AFAIK, the homescreen web app does have Nitro JavaScript engine support since iOS5+. So it is still not the same vs. WebView in native app.
@hlb, Of course the JS engine is slower. You have to just get it into your head that what the sencha team tackled had little to do with JS performance and mostly to do with Layout Engine stuff.
I hope you will release your own Facebook HTML5 app on Google Play and App Store.
@hlb We’ll wrap it to verify. Try to keep an open mind that the GPU compositing is MUCH more important than the JS for this type of application.
Very nice effort, but Facebook has to run on the most crappy devices running android 2.x
Unless you can actually force all your users to upgrade to 4.x Zuckerburg’s statement that html5 is not ready is true.
SchizoDuckie, Those crappy devices present some of the same crappy UX issues on native applications. You can’t blame a technology for the device’s implementation.
Please make this available as a demo app so that everyone can learn from it!
Leo, they linked to the website, try it yourself instead of asking about load times etc. fb.html5isready.com.
Jay Garcia:
That is true, but it’s not the point I’m trying to make.
My point is that HTML5 is as ‘ready’ as the best device out there running it.
For instance: Chrome on Android 4.2 does not do Webgl, Firefox in beta does, quite accurately.
Does that mean HTML5 is shitty? No. It means that you’ll have to handle specific devices differently, do assesments of what is available and what not, and cannot guarantee the same user experience across all devices. Specific phones require specific implementations, which will lead you to a terrible code spaghetti, as if it were IE6.0 7.0 8.0 9.0 10.0 all over again.
I cannot blame Facebook for switching back to native apps, heck, I cannot even blame them for making the statement that HTML5 is not ready. The phone implementations are not ready.
I’m a sucker for a good HTML5 love story.
@JamieAvins I am totally agree with you on the GPU thing and heart HTML5, but need a fair test result to convince others ;-)
@SchizoDuckie
I’d say HTML5 is more than “ready”. The Android ecosystem just isn’t ready for it, not the inverse. All of the crapware Android 2.x handsets out there are the new IE6…
@SchizoDuckie: I tested this Touch app alongside the native Facebook app on an Android device running 2.3.2, and the performance was equally crappy on both. Native doesn’t mean jack if the hardware itself sucks.
I love you guys!
So after 6 minutes waiting for its initial load I gave up. The video show none of the page loading times nor the initial load times which I have notices to be pretty bad using Sencha and similar JS frameworks in the past.
The premise of this argument is wrong. It’s not a simple question of “slow” versus “fast.” Application performance is only one factor in building an HTML5 app. Device support, engineer productivity, testability, measurement, tooling/debugging, and native integration are all points that should be factored in. Anyone who has burnt the hours trying to debug a perf issue on a device that doesn’t support Webinspector knows this pain. As does anyone who has gotten the bug report about the keyboard not popping up correctly on. As does anyone who has gotten the layout performance awesome in one test environment only to test another and find it terrible. The argument that HTML is ready while the device landscape is not is pretty fraught.
As far as fast goes, even as well done as this demo is, the scrolling framerate is noticeably slower on the Nexus 4 compared against the native application. I feel like all the demo is proving is what we already knew — somethings can be done reasonably well in HTML while many other can’t. I’m a person who would rather have the web win. I’m pretty sure it will win in time. It’s a pretty clear fact that until the browsers/webviews get faster and/or the device’s have faster hardware, HTML is the second best option for smartphones.
Seems Windows Phone .5 also doesn’t support this page :(
If only it was actually written in HTML5 and not WebkitML
Jackson Gabbard: I couldn’t have put it into better words. Thanks for clarifying my thoughts.
@Wes Johnston What WebkitML parts are you referring to specifically?
In your Face Facebook. Actually studying the problem, really understanding the technology involved and addressing performance issues with smart ideas and optimized code will always win. Great job Team Sencha, inspiring to say the least.
Fantastic work guys :) Love seeing your pretty faces on screen once more
@hlb I doubt we’d get approved for the app store. But here’s a simple XCode and Android UIWebView wrapper you can use to show it doesn’t degrade without the JIT.
https://github.com/extjs/fastbook
Today, @Sencha proves that it’s not just the size of your HTML5, it’s how you use it!
@Jackson Gabbard @SchizoDuckie
Native isn’t a panacea either. It’s rather shocking to me the lengths some take to make these kinds of apps:
http://www.theverge.com/2012/11/21/3675324/tumblr-native-app-iphone
Jamie, if you’re setting up a Github repo for this, can you add the source code as well?
Jamie, Jacky, this is some truly amazing work!
Curious to know how long it took you to ship it.
@Brian Kotek There’s some new pieces that we need to integrate into the framework. If we release it now, we’re risk forking things pretty badly. A little patience, we’re working things in as fast as we can.
@Yuriy Dybskiy The app itself was done over the past several weeks. Time was pretty evenly split between us needing to dig up their API and creating the new features we needed.
A sticking point with iOS is that embedded WebKit (in Facebook’s old native app) performs horribly compared to Mobile Safari (what Sencha used here) due to Apple’s selfish hoarding of the Nitro JavaScript engine.
Awesome. Can’t wait to dig into it. Admire the efficiency of the app – 10x less data on the wire and three iframes for news feed, timeline and comments view. No unnecessary reloads. Beauty!
@Ron Waldon – works just as fast in Chrome on iOS which isn’t using Nitro
@Ron Waldon It doesn’t matter for such apps like this. Again as we mentioned the bottleneck is never JavaScript execution. We wrapped the app in native webviews for you to try it out yourself: github.com/extjs/fastbook
@Kyle – try turning off Private Browsing in mobile Safari. That fixed the ‘loading forever’ issue for me.
Jacky and Jamie – very impressive!!
@nguyen
What about initial load times when cache is not available? What is the performance impact of HTML5 on load times. I noticed in your video this test is skipped. This is a very important test since its the initial impression an end user faces.
Also from a design standpoint the browser window UI may want to be overridden due to the fact you don’t want the end user to navigate away from your app accidentally. This cannot be done with HTML5 from my limited understanding of it.
Finally if the native app kept state it would be just as fast or faster would it not?
Every experienced web developer knows the problem was with their implementation. Now we have proof. Way to go, guys!
@Dathan Pattishall
The whole app itself is just ~ 100KB gzipped on the wire. A fun fact the homescreen splash png is bigger than the app itself. This means the very first load time could just be a second or two from a 3G connection. Afterwards the browser already caches all JS / CSS assets. Facebook’s native apps are around 12MB+ binary each. Imaging users can immediately use your app in seconds by hitting a URL from a search engine as compared to downloading from the App Stores, provided that they can find your app in the first place.
Load time in this app is really about API calls, and we’re using nothing more than Facebook public API. The response time for each request is at the mercy of their servers. All we could do is reducing the amount of data transfer to the minimum (10% of what the native apps do as we mentioned). Also we could have stored the last data in Local Storage for subsequent refreshes, I just didn’t bother doing it for this demo since we have quite limited time for a side-project.
As for navigation to external pages, you could always open those URLs in a new window. I’m not sure if you noticed but states in this demo are managed with HTML5 History API. Try viewing a Story and refresh the page for example. You’ll be right where you left off.
It’s ideal to keep rendered content for instant switching back. However you could only do that if memory management is done optimally. There’s only so much you could keep until the app crashes running out of memory.
Funny, I tried it with my (absolutely shitty) Symbian phone. It doesn’t load in Opera Mobile, but it seems to work great on the builtin browser (though slow, of course), which is usually shit compared to Opera.
Awesome work. I can’t wait to get up to speed with TaskQueue and AnimationQueue. I’m having to display a list possibly containing hundreds of items and this might be what I’m looking for.
Frankly, I can’t see much difference between the two apps. Ok, animations are quicker but I don’t see the facebook app as laggy.
This test actually proves the point that phones are quite fast to handle HTML5. My 2 years old android phone does still lag in the browser and totally sucks when compared to a native application.
But that’s not the point, technology is always moving on.
The real problem is: would you really want to develop an app using HTML5?
IMHO the only advantage is in it being crossplatform. We are talking about personal tastes of course, but I don’t think HTML5 + CSS is the way to go to design an app
(Disclaimer: I’m not a seasoned designer who hate this “new” HTML5 stuff, actually I’m in my twenties and I’ve spent the last 8 years developing and designing mainly on the web – even though I did some desktop applications)
HTML is not made for defining UX and this is still clear. Everytime I ask myself why am I choosing a div instead of a span to create a container, something inside me dies.
Why can’t we just use something application oriented?
@nguyen I agree measuring from app download from the app store to usage the HTML5 app would be faster, but that’s not a use case a user looks at.
Its the time when the user clicks the app button to app load.
So for HTML5 the time delta would be the 100K download from at most two mobile threads + Javascript overhead + Render + API call overhead + Storage Sets (cache fill) verses Native Render (Multi-threaded CPU bound) + API call overhead.
Also from a developers standpoint, the developer only has to build for OS releases using a native app, while for HTML5 they have to build for each browser and browser version. For example: Windows Phones, Safari, Chrome, Opera, FireFox, different web-kit versions, etc.
Seems to me that both methods have their pros and cons-yet purely basing the argument that HTML5 can outperform or is equal in performance to native; I’m still not sold on this-especially when you look at the developer overhead needed to get the same performance/capability from every top browser out there.
Good job in your demo though.
Doesn’t work on Windows Phone 8.
@Dathan Pattishall
You could bookmark the URL / add it to homescreen, kill all processes, then compare the startup time from scratch for Fastbook and the native one. I’m pretty certain you won’t see much a difference.
We built the app once and it works on both iOS and Android, as compared to 2 completely different platforms / SDKs if you write native apps. There are adjustment in styling to make it look good on each platform, but it’s very minor.
There are always choices. The point of this is to not saying which choice is better, it’s all yours to decide. We were just trying to prove you can achieve the same goal with web technologies if the implementation is right, and stop people from blindly blaming on the technology itself.
https://graph.facebook.com/graphql/ is a 404, just saying.
@ahmet alp balkan
That’s the actual URL to use when you have a token. For more information, please go to:
http://developers.facebook.com/docs/reference/api/
I believe that the strength of the team sencha touch
Anyone have any thoughts on why the Android native app was really so poor in performance?
Took a while to load first news feed but was quite fast after that.
Great work, great HTML5. I like it.
A profound “Thank you” to team Sencha. I had wanted someone to call bullshit on fb. This is just really great investigation. Long live the web.
It doesn’t work so well on my Galaxy Nexus running Chrome. Linked in posts don’t work and comments don’t work. Perhaps a little more work or testing is needed if the purpose is true cross-platform app development.
Great to see someone like you taking this challenge and putting a great effort to build a great web app. Interested in seeing some engineering details and how you attacked some of the challenges and learning about your best practices.
So facebook with gobs of money can’t manage to pull off what 2 developers from Sencha can do in their spare time? I’m putting my investments somewhere else or maybe just waiting to hear Sencha’s been gobbled up.
Any chance on peeking in on a public git repo?
There’s some pretty important UI code running here that a lot of people are going to want. That left/right draggable FB-drawer thing should be named and wrapped into a framework component.
I’m using ux.slideNavigation which is quite nice.
https://github.com/wnielson/sencha-SlideNavigation
I login and granted permission but it stay in that page that it says: ( fastbook pulling your profile, one moment…) and dont pass from there. I am using Iphone 5, IOS 6.0.1. Any help on this?
great app.
what about sharing the extensions? sliding side menu and most importantly the pinch zoom images. are they home brewed by sencha or the ones on the sencha market?
Yes please share the code. This will be very interesting to take a look at! Great job!
Doesn’t seem to work at all on Windows Phone 7.5 (IE Mobile 9), even if it has (some) support for HTML5 (http://html5test.com/compare/browser/wp75.html)..
It would be really good to be able to use these components you’ve talked about !
Doesn’t work at all here… (Samsung Galaxy S2). Not able to scroll, doesn’t update stream.
If only it actually was HTML5 and not just -webkit- prefixes and apple propietary non standard tags all over the place. Use standard html5 next time and it will work great in standards supporting browsers such as IE10 and FF too. Like someone said above: Use HTML5 and not WebkitML. That is as bad as coding a site for IE6 specifically.
Actually, if you remove the prefixes and go with standard W3C HTML5/CSS3 it will probably work better in IE10 than webkit. Atleast the gradients will, since webkit uses non-standard gradients.
However, it is a great demo and I congratulate you on your achievement.
The fact that NOT A SINGLE LINK on this page is underlined should give a huge amount of cancer to anyone who designed it.
I am very interested in the image viewer with pinch-zoom and pan capabilities. I haven’t seen one as smooth as this demo. Can you please share it or give us some pointers on how to create one?
I experience the same loading when browsing downward on the “wall” quickly on the fastbook app. Am not impressed by it.
If you’re seeing loading delays, it’s not the app. It’s Facebook’s content service or your network connection. Probably the latter, since the wall history loads seamlessly for me.
Great HTML5 app, especially for pushing the performance at a very high level ! Congratulations for this. As you proved, the best learning is that Website & App architecture must be different, so please continue to share this idea.
I would just love to see these new HTML5 components outside the Sencha framework so everyone can use it (with ou without using Sensha framework).
Awesome work. I love a good web app over native any day. But it would have been nice to see the standard CSS attributes instead of all webkit specific (or at least in addition to)
@Fredrik @Brad We use the CSS attributes available and when required. We do believe that layouts require something like a flex to work well. We have a dependency on flexbox that currently Webkit, IE10, and Firefox nightlies support. Many other attributes still require you to prefix them in Webkit. IE10 actually has less requirements there so you will see less prefixes when you use IE10.
Our reliance on webkit masks for things like icons is being transitioned over to font-face.
As far as IE10’s capabilities, we really like what they have done to support standards.
Some folks here seem to be forgetting that if you package up a Touch app as a native app, it’s going to run natively using the Webkit-specific extensions. That’s just how the native wrapper works and how the packaged native apps run.
To me, the whole point of this demo is to address Zuckerberg’s claim that the performance of an HTML-based NATIVE APP was unacceptable, and that the only option is to drop to platform-specific code. Sencha has shown that this isn’t true.
Would it be nice if the app ran nicely in non-Webkit browsers? Sure, and I hope they keep updating the demo so that this is the case. But I think some people are focusing on the wrong things here. The real point is that you can build an HTML-based NATIVE APP that performs on par with an Objective-C-based NATIVE APP.
Building high-performance BROWSER-BASED apps that are optimized for mobile is an important related topic. But I don’t think that’s the main point Sencha was was trying to make here. The only reason they’re demoing it as a browser-based app is because demoing it as an installable native app would require going through all the iTunes App Store hoops.
@Jamie Avins
Where do you use display:flexbox ?
I am looking at the sencha-touch.css (2.1) and didn’t find any.
@Alexpo Look for “display: -webkit-box;”. Webkit uses an older syntax.
Some more details about the syntax and changes can be found here: http://css-tricks.com/old-flexbox-and-new-flexbox/
My install is just stuck in pulling profile forever. I also see a message saying some about authorizing code expired. Running the latest 601 iOS on 4gs
I have tried uninstalled the app from Facebook severely times, restarted – but no luck . Where can I get help with this ?
I’m sorry but i’m I the only person who can see the lag between the user touching the screen and the scrolling happening in the video at the start on the HTML version?
Anyway all of this is probably irrelevant when it comes to memory usage which i’m willing to bet is vastly higher with the HTML5 version, but who cares about memory usage? It’s not bothered the web industry for years as they just stick more markup, more CSS and more JS into a page with zero consideration for the memory usage of the browser. Chances are this is news to a lot of web developers.
In addition the HTML5 version will most likely use more CPU and more GPU to render the content, which has a detrimental effect on battery life, something which again nobody seems to care about, if it’s smooth who gives a stuff if it flattens your battery in 30 minutes right?
The current ‘native’ facebook app is rubbish so i’m not trying to defend it at all, but when done properly though native will win out over HTML as there really is more to consider with mobile app development then pure smoothness.
HTML though is good as a layout template, and with some improvements even CSS might be useful, but in mobile app development with all it’s constraints it’s not the wisest choice right now.
@Skaneby, @Frankie – Try turning off private browsing in Safari. That fixed the loading issue for me.
@Piraxian Of course native should and will outperform html, you’ll never see Need for Speed in the browser. But frankly I’m more tempted to make something that works on all devices and screens in html/js than to learn all kinds of rubbish and fight with app store administrators.
Also you have no data to back up your claim about CPU and GPU. If you read the post they actually made a proxy to reduce data-traffic which came as severely bloated from the facebook api.
Point is; they proved it can be done. They proved it is an option. They never said it was better than native. But I for one am glad that there is a crossplatform solution which is NOT Java.
is there any chance to get the raw source of this project. i am really impressed about the performance and would love to see how you handle all your stuff.
Sadly you’ll still end up fighting with the app store administrators as most rejections I find are due to bugs.
For some apps HTML can do a decent enough job, but for something as vital and critical (for the developer) as the facebook app i’d say HTML isn’t the best choice as it’s just too high profile and there are performance implications (performance being speed, memory, battery life, etc).
Now don’t get me wrong i’ve written HTML/JS apps that ran in a webview, writing it was easy, ensuring iOS and Android apps behaved as expected on the platform was more difficult but trying to squeeze every last ounce of performance however to get it as close to native as possible was rather painful specifically tuning to minimise reflow in the browser and reducing the cost of JS calls.
To answer your question I do have data to back up the CPU/GPU and memory usage, sadly I won’t be able to publish it under my NDA, if I get time over the next few weeks i’ll try to generate some data for you which won’t cost me my job :)
Doesn’t work with Opera Mobile. This is crap.
@Piraxian: the Sensha team proved that HTML5 could outperform native apps if these ones are not well architectured. Native apps run “by nature” faster ; but this mockup also proved that with HTML5 is faster and faster.
Memory consummation & CPU usage are now analysed by web developers, which wasn’t true only one year ago. (please refer to all the work and presentations made by people Paul Irish, Addy Osmani and others).
GPU usage use less battery then computing the animations from the CPU. (via CSS3 3D animations) so web devs are also aware about battery saving.
Sorry to tell you that good web devs really pay attention to performance and so don’t include the more libraries and more code possible. Less is more.
Certainly Its a great. Hope this fastbook will be more reliable for the new devices
Best blog post of the year guys. I have been an HTML5 believer since ExtJS day-1 but your Fastbook app exceeded my expectation of what can be done today.
One tiny criticism which applies if this blog post goes viral as it should. While presenting a complex technical debate in the video you forgot to mention Sencha Touch. This can be rectified with a minor text edit at the top of the blog post to make sure visitors outside of the Sencha dev sphere get the message that the talking heads in the video work for the company that provides the world’s best mobile JavaScript framework.
2 things:
1. Why are you using an iframe for your sandbox? Why not Document Fragments? That seems to be all that’s needed for your purpose.
2. Your demo is from Mobile Safari. I would like to see your same video done against an app with WebView that is notoriously slower than the mobile browser.
Hi there, this weekend is pleasant in favor of me, since this time i am reading this enormous informative piece of writing here at my residence.
@Curious
1) Once fragments hit the DOM tree they become part of the layout. Adding them and removing them from the DOM tree can be slow. We avoid both issues using the sandbox.
2) Apple isn’t going to approve a demo like this, we made a very quick wrapper at https://github.com/extjs/fastbook for people want to see for themselves that there is no issues with a WebView.
@Jamie Avins
Can you state any timeframe on these new features (e.g. sandbox) being implemented in the framework?
Wow… that is quite a lot of work, especially the word listing. Thank you for sharing. Very nice job.
Does the offloading of XHR + JSON decoding to Web Workers really help? Have you made some measurements, and if so, could you share some results?
You guys are hired!
I translated it into Japanese.
http://www.xenophy.com/extjsblog/5245
Provision: Japan Sencha User Group
http://www.meetup.com/Japan-Sencha-User-Group/about/
Hi guys. Yes. I’m agree, you made big work. But:
*) >We saw the latest generation of mobile devices
Are all web developers make sites and web applications only for last browsers?
Yes, I agree that iPhone 5 and Samsung S III is excellent but I hope that you not forget to check this URL: http://developer.android.com/about/dashboards/index.html
*) HTC Desire S, Android 2.3 – slow GUI (at least for my perception), scrolling of page is incorrect.
*) What about to add, at least, “slide” transition between pages/screens which will work and look good at Android 2.3 + good content scrolling? And to get sometimes strange and slow behavior? Or you think that only I have phone with Android 2.3? :)
I tried this, but the issue I’m having is that I have 3 facebook pages and it picked one on it’s own to log in. I already had a different one open on my phone, but fastbook opened a different facebook account without me inputting a log in.
HTML5 is only ready on modern browsers, still too many people using older ones which require hacks or just wont work all together without Javascript. So depends on the context.
Laurence I have the Galaxy S3
I want to update my comment… obviously a mobile HTML5 app is ready. Smartphones will have HTML5 supported browsers. I guess my comment came from another article that led me here which was whether HTML5 in general was ready and I dont think it is for desktop computers due to older browsers, but it is for smartphones. A dedicated app would likely always be more powerful though, in the near future.
Source code?
I didn’t like the privacy waivers. For a demo it was creepy especially for Sencha. Didn’t get past that part.
Any privacy confirmations you see are from Facebook, not the app. The same way every other application that uses Facebook’s API does.
Hi guys we are developing mobile apps for iphone and android .HTML5 is only ready on modern browsers, still too many people using older ones which require hacks or just wont work all together without Javascript. So depends on the context. http://www.pikesol.com
I just tried this in Chrome on my laptop. Looks great and fast. But I found a weird bug in the comments and likes view for a post. If you view comments/likes for a post and then do the same for another post, the comments/likes from previous post are shown in the second post as well along with some from the new post. What’s more, they are repeated once you scroll down a little bit. Not a very good idea to mix up people’s comments and likes from different posts. ;)
Excellent. Good work by Sencha Team. Thumbs up to HTML5.
Mark Zuckerberg “HTML5 wasn’t ready” comment interview
http://senchadevelopers.blogspot.in/2012/12/mark-zuckerberg-our-biggest-mistake-was.html
This sounds amazing and looks like Facebook guys are fools for leaving HTML5 at first, but it’s far from it.
Just to show news feeds, Facebook’s own mobile web is quite fast, almost same as demoed here. No difference at all.
The Facebook mobile app has to support lot more than that – ability to give permission to other apps, list, install and run apps (device specific), run games/apps inside it’s own app itself, perform sync on various levels, have a payment mechanism, are just a few.
In light of those, this is just other Facebook *news feed* fork which is redundant. We must appreciate Facebook’s real effort to go native here.
I think you’re missing the point. Zuckerberg claimed that HTML5 was too slow and that the only option is to write native code. This demo shows that is obviously a false assertion.
Not me. Just put all those features on one HTML5 app and see. The whole desktop browser will crawl, let alone the mobile one.
And mind it, I’m saying this but still am a full blown HTML5 based mobile app developer :)
Hey, very inspiring points you made here.
Few questions –
1. What is the benefit of using ‘object’ element instead of ‘iframe’ in the sandbox feature?
2. Can you elaborate on how interleaving of read and write requests to the DOM hurt performance?
3. It will be great to have the source code :)
Thank you!
Although the HTML5 implementation is very nice, most of the issues outlined with the native App aren’t because of shortfalls of native App development but rather Facebook’s implementation. Rotation, storing of data and background loading are all very basic concepts in native development if done correctly.
I’ve tried FastBook on both an iPhone 5 and a Sony Xperia S and while it’s pretty smooth and fast on the iPhone 5, it isn’t on the Xperia S, particularly compared to native version of Facebook.
And even on Google Chrome, which has a faster and better rendering engine, it’s still not as smooth as native version.
So by this example you did the exact contrary of what you meant to do with this post, that’s to say you convinced me , after trying FastBook that HTML5 is NOT ready yet and so that Mark Zuckerberg is right on that.
Because an app like FaceBook is used by millions if not billions of users around the world on various smartphone models from very low end smart phones to cutting edge ultra fast smartphones. Having an app that works great only on iPhone 4S or better or Galaxy Nexus or better but is slow and painful to use on Galaxy Ace, iPhone 3GS, Xperia S or U, etc. is not acceptable.
So yes your FastBook implementation is nice and smooth on iPhone 4S and Galaxy Nexus or better but it’s not on lower end smartphone and is significant slower than native app in those cases.
Also you point out that in your implementation loading of next items on news feed is realtime, not in native app, it’s true but it’s not because it’s not possible to do it this way in a native app, but only because Facebook team didn’t implemented it this way, but they could have done it the same realtime loading in the native app without problem.
Same goes for the fact that you keep sections in memory once loaded so they don’t reload when you switch from one section to another it doesn’t reload, this can be perfectly done also in a native app. But this is a bad practice in mobile development to keep too much screens in memory because on a large number of smartphone memory is a very limited resource, for example an iPhone 3GS has only 256MB of RAM. So it’s a bad idea to keep screen loaded like you do for an app that target billions of users and so a large scale of smart phones models.
So I’m sorry to tell you that by letting me trying FastBook that is, according to you, a state of the art of what HTML5 is capable and should convince me that HTML5 is a good alternative to native app, you did the exact contrary and convinced me that HTML5 is NOT ready to be used as native replacement particularly for apps that targets a large scale of smartphone models and particularly if you target middle end or low end smart phones as it’s significant slower than native version in those cases.
So mission failed.
@Bertrand:
1) The Facebook native app also runs slowly on older devices. The irony is that their own “native app” actually loads large blocks of raw HTML for portions of the interface and displays them with a UIWebView. So anything that would make Fastbook run slowly is even more true for large portions of the poorly optimized native app.
2) Your statements about the real-time news feed loading “too many screens” reveals a fundamental lack of understanding of how the infinite list actually renders items. (Hint: it recycles the visible rows and only renders a handful of DOM elements, not the whole list).
3) The demo itself shows the app running on an iPhone 4S and a Galaxy SII. And a Galaxy SII has the same (exactly the same) dual-core processor and RAM as an Xperia S. So not sure if you’re trying to say the video is fake, if you’re saying there’s just something wrong with your test device, or if this is actually just a troll post?
I am still not convinced that this model is going to work. You had to make tons of hacks just to make it run as fast as native apps, and for native apps that may be just few API calls with fewer than 100 lines of codes. That means the time you need to develop the app is much longer than a native one.
Another problem is that this requires deep skill in web technology, and few people can do that. However, to achieve same result with native apps, it only requires average skill level, and those developers are much easier to find. This will most likely result in a maintenance nightmare after few versions, several major new functions added, and several team members come and go. For small scale demos, you can make it great. However, real business apps developments will last for years and go through many versions. To keep it as high quality as it was originally a small demo is never an easy thing.
It’s not a “ton of hacks”, it was modifying or adding a handful of components. A few Sencha developers did this is a couple of weeks! And they’re building this into Sencha Touch, meaning you don’t have to do anything to leverage the new features.
Even if it takes a similar amount of time to create a native vs. HTML 5 app (which is itself an unlikely claim), it conveniently ignores the real problem with native development: you have to build and maintain AT LEAST THREE platform-specific versions of the same application! That is the very definition of a maintenance nightmare and it dwarfs any issues with building a single HTML5 app.
Good read about html 5 even am also in love with html 5.
thanks
http://read-book-online-free.blogspot.com/
Jamie and Jacky,
Great job! What you shown is very promising. I do have some questions about mobile HTML5 based on my experience in the last 9 years in enterprise mobility. It would be really interesting to know your views / approach on these topics.
Premise: Mobile applications are for enterprises to mobilize enterprise processes and data like ERP, CRM, etc. providing complete offline capability along with online capability. Most often the focus is only on the UI in most frameworks. In enterprise mobile applications UI is one major part of the application and not the whole.
1. Database: Enterprise mobile applications required offline data. So data has to be stored on the device. Ideally in a database. The tables in an enterprise app are not 1 or 2. They can be 10s of them with relations. The simple requirement is a relational database in a secure manner. How can HTML5 deal efficiently with offline data and the requirement of offline database? Do you recommend Sencha Touch to be used for offline mobile applications? Or should it be used with PhoneGap?
2. Device Components Access: Access to components like camera, GPS, etc. across all mobile devices (iOS and Android to start with). Should this be based on PhoneGap or does Sencha plan to add support to all such components? Sencha Touch 2.1 supports some native components like camera. But what about others?
3. Push Notifications: Push notification access even when the application is not running is a very important requirement. How does Sencha Touch support push notifications across multiple devices?
the information you offer on this site has helped me greatly. Also it has excellent and very informative. After going through this great content i came to know lots of things which will help me to enrich my knowledge.
@Brian
I’m not talking about the current native Facebook app specifically but about native compared to HTML5 in general supposing both are correctly designed and optimized.
As for your point 2), I’m not talking about realtime news feed loading when saying that keeping too many screens in memory is not a good practice when you want to target a large range of smartphone including ones with very low amount of memory available. I’m talking about keeping sections loaded (like profile and near feed). This is OK in your demo because you just implemented 2 sections (profile and news feed), but it wouldn’t be OK if you had implemented all the sections.
As for native apps running slower on old smartphone, of course they are because the CPU and GPU performances are worse and they have less memory. But the impact will be less important than with HTML5 as native code is compiled and so doesn’t need to be translated to machine language before being executed (except for Android that used a JIT compiler for non NDK apps, but it does it from highly optimized Dalvik bytecode and not directly from the source code like with JS) . On a slow hardware the impact of HTML/JS interpretation (or JIT compilation for modern JS engine) is a lot more visible than on fast hardware. That impact is null on fully native apps (iPhone native app or NDK app on Android) and significantly less visible (thanks to the highly optimized Dalvik byte code) on java based native Android apps.
As for the Xperia S and your iPhone 4S/Galaxy SII demo on your video, yes they are similar and on your video we can easily see numerous of slower performances compared to native Facebook app, particularly on the iPhone 4S. And the performance of FastBook on the Galaxy SII in yiur video is indeed similar to the one I experienced in the Xperia S in similar usage.
So performances of FastBook are good but not as good as native, but still this is a viable solution for smartphone in middle to high end like Galaxy SII, Xperia S, Galaxy Nexus, iPhone 4S, iPhone 5 or Galaxy SIII. But as I can already see performances limits both on your video with the Galaxy SII and the iPhone 4S and with my own Xperia S (in which I conducted more aggressive tests than yours (I.e: using the app a lot faster than you do in your video)) compared to native version, I can’t imagine on an iPhone 3G, a Nexus One or similar phones, in fact I can, I tried on an iPhone 3G and it’s very slow compared to native version that’s still usable (even if it’s slow too).
Technically speaking that’s obvious that a technology that needs a translation step (either interpreted or JITed) like HTML5 will never be as good as fully native (I.e: binary compiled) technology like what is done in iOS, it may become close to Dalvik apps on Android if HTML technology evolve to byte code precompilation like it’s done for Dalvik apps on Android.
But in its current stage it can’t fully compete with native app. It’s a good alternative when you seek cost reduction and can offer an acceptable user experience if you target middle to high end smartphone, but it’ll always be behind in term of performances.
But I agree that in the future as the smartphone installed park evolves to more and more powerful smartphone, HTML5 will probably be a good solution even for large target apps like Facebook. But in the current smartphkne installed park which still counts numerous iPhone 3G(S), Nexus One or similar smartphones, this is not viable for a large target app like Facebook and this is why Mark said that HTML5 is not ready in the case of the Facebook app.
Awesome work guys. The app really feels responsive and beautiful. I do see that you are working with an alpha release of Sencha Touch 3. Is that already available for us developers? I would also love to make the apps we are working on as responsive as this one, but honestly can’t see that happening in Sencha Touch 2.1.0. Second question: Is there a roadmap planning for Sencha Touch 3?
Nice work!!
It would be nicer if we can use it also on the laptop (I know this is not the point of the app). There is no possibility to scroll down using the keyboard or the touchpad.
Great job! What you shown is very promising. I do have some questions about mobile HTML5 based on my experience in the last 9 years in enterprise mobility. I would be really interested in knowing your views / approach on these topics:
Premise: Mobile applications are for enterprises to mobilize enterprise processes and data like ERP, CRM, etc. providing complete offline capability along with online capability.
1. Database: Enterprise mobile applications required offline data. So data has to be stored on the device. Ideally in a database. The tables in an enterprise app are not 1 or 2. They can be 10s of them with relations. The simple requirement is a relational database in a secure manner. How can HTML5 deal efficiently with offline data and the requirement of offline database? Do you recommend Sencha Touch to be used for offline mobile applications? Or should it be used with PhoneGap?
2. Device Components Access: Access to components like camera, GPS, etc. across all mobile devices (iOS and Android to start with). Should this be based on PhoneGap or does Sencha plan to add support to all such components? Sencha Touch 2.1 supports some native components like camera. But what about others?
3. Push Notifications: Push notification access even when the application is not running is a very important requirement. How does Sencha Touch support push notifications across mulltiple devices?
Great, thank you for showing off the power of HTML5!
D
@Jamie Avins and @Jacky Nguyen
Could you guys take it to the next level and speak to some of the hotpoints presented by fb/zynga to the w3 webperf group?
see: http://lists.w3.org/Archives/Public/public-web-perf/2012Sep/0016.html and http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html
@Karsten McMinnn We certainly continue to provide our feedback to the WC3 to have standards move forward. I believe Tobie Langel’s notes on scrolling issues are something we constantly harp on when it comes to the current scrolling APIs as their real world usefulness (they are not well thought out which is why we do all our scrolling in JS). Right now Jacky and I are both trying to get the browser makers to get that GPU “black-box” as Tobie refers to it, working better with dynamic web apps.
Thanks for that great job. I have only a question. You say that you use Web Workers for make some process and funcionalities. How do you make that in Android Browser? Do that browser have now support for Web Workers?
Thanks.
I want to try your solution but I get “An error has occured” when trying on iPhone and on my PC.
I am getting “An error has occured”
Facebook sent us a notice that we need to have a separate policy document. So we are working on putting that in and we should have the demo back up shortly.
Html5 is a cpu HOG, sav your battery don’t use html5.
And btw I am still waiting for a native facebook app for Android.
On wp8 ie10 the scrolling is lagging, i believe it to be a problem with properly registering ms pointer events…
Better story , amazing
Amazing!
I would love to see its code, please tell me how to get it.
Hail Open-source!
@Jamie & @Jacky, awesome work!
I just noticed that it performs well on iOS Safari, but it is a bit laggy on Android browsers, why is that?
Also the text on the page is not selectable, I think some users might expect selectable content.
Anyway, it is really great, and thanks for sharing.
I like demo video, and this might be what I’m looking for.
Hi,
will the modifications that were made to your framework get added to the distributed sencha framework soon?
regards
Jamie
Good job, guys. Please provide the code as a sencha touch example.
Great! HTML5 rocks!
But:
https://www.sencha.com/forum/showthread.php?271281-text-field-inside-iframe-focus-problem&s=81151e90eadafa688dd262446a8b436e
and:
https://www.sencha.com/forum/showthread.php?282681-IOS-5-Touch-events-doesn-t-work-when-app-is-loaded-in-iframe
Both says Sencha Touch does not support iframe?
It’s amazing what you guys have been able to do using HTML5, this made me very happy today.
Excellent write-up. I absolutely love this website.
Keep writing!
What’s up mates, how is everything, and what you desire to say on the topic of this article, in my view its in fact remarkable for me.
I read this article completely about the comparison of latest and earlier technologies,
it’s remarkable article.
Thanks For Your valuable posting,this is for wonderful sharing,i would like to see more information from your side.i am working in Erp Company In Dubai