regards
Jamie

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.

Hail Open-source!

Thanks.

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

D

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?

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.

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.

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?

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.

Thank you!

Mark Zuckerberg “HTML5 wasn’t ready” comment interview
http://senchadevelopers.blogspot.in/2012/12/mark-zuckerberg-our-biggest-mistake-was.html

http://www.xenophy.com/extjsblog/5245

Provision: Japan Sencha User Group
http://www.meetup.com/Japan-Sencha-User-Group/about/

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.

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.

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.

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

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.

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.

I have tried uninstalled the app from Facebook severely times, restarted - but no luck . Where can I get help with this ?

Some more details about the syntax and changes can be found here: http://css-tricks.com/old-flexbox-and-new-flexbox/

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.

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.

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.

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

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/

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.

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.

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?

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.

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?

Jacky and Jamie - very impressive!!