
Making Facebook's native mobile app faster using HTML5 - steffenhiller
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
======
brianchu
I ran the HTML5 app on my iTouch 4G running iOS 6 (roughly equivalent to
iPhone 3GS) and compared it to the native FB app. The HTML5 app had noticeable
lag in the swipe transitions. It also crashed once when loading a photo (only
once though). Not to mention that they implement almost everything differently
and leave out 90% of FB's features.

That being said, it was really smooth on my iTouch 5G.

The demo HTML5 app also runs in Safari. The problem is that Safari's Nitro JS
engine is much faster than the older JS engine used in a UIWebView (I think
the restriction is supposedly due to security).

For the moment, native is still the way to go, IMO. But I've always believed
that at a certain point iPhones/Androids and their browsers will be powerful
and efficient enough to negate any performance drawbacks to HTML 5. I think
that point might arrive by the iPhone 6 or so, when developers might feel
comfortable dropping support for the iPhone 3GS and equivalent. In fact, many
devs are already dropping support for the iPhone 3GS.

~~~
rimantas
Even when browsers are powerfull enough the mess what is trying to shoehorn
technologies created for hyperlinked text into apps development will still be
a mess. It may appeal for those who know only the said technologies, but
frankly, they would be better of by just learning the native instead of
spending time traying to fight quirks. As for the appeal "run
everythere"—that's just some more quirks. Good luck with that. I am very
experienced web developer and probably know html, css, js and all that jazz
better than I do know Objective-C and Cocoa Touch, but building mobile apps
with web technologies is the last thing I want to do.

~~~
macspoofing
What mess? HTML/CSS/JS is exceptionally good at building user interfaces. And
you're on the right side of technology by attaching yourself to the HTML
bandwagon. I would go as far as to say that if you're starting development on
a new ("form-based") native app, your first choice should be HTML. You only go
native if you have a very good reason to do so.

~~~
pjmlp
Because each single browser out there has a different understanding of what
HTML/CSS/JS means.

Making web sites that comply to customer requirements down to pixel level,
across all required target browsers is a major pain.

~~~
macspoofing
Even with multi-browser support, it isn't _that bad_. But we're not talking
about websites here, are we? We're talking about using HTML/CSS/JS to build
native apps for mobile devices - which are by and large webkit-based. This
greatly simplifies everything.

~~~
blub
Oh really? Let's take my webkit-based mobile browser then and look at an
instagram picture. Hm, it's cut in half and I can't scroll. Mobile web apps
are actually iOS webapps that most of the time work on Android. Stop
pretending you actually care about standards and cross-platform, you're only
interested in doing less work, learning fewer things and holding users firmly
by the balls in the cloud.

~~~
yareally
My issue with HTML apps (like your issue) is many developers think it's
perfectly okay to use that iOS interface on Android because Android does not
force you to change it. The Android ecosystem is so polluted with apps like
this that it almost makes me long for Google to put their foot down and start
forcing UI compliance like Apple does.

It's bad enough Android users have to deal with legacy apps on their own OS
that still use pre Android 3.0/4.0 UI conventions (or worse, poorly slap them
on top of their old interface without consideration). The only apps that
should be allowed to get away with rolling their own UI are games.

------
micampe
Why do we see plenty of articles saying that HTML5 can be as good or better
than native code and no actual applications doing it?

Facebook and Google tried and miserably failed, LinkedIn and Twitter are
probably the ones closest to actually doing it, but users still prefer the
native version, why?

One I think is a big reason is clearly visible in the video: scrolling physics
are different. It's annoying and feels wrong and I think people notice even if
they probably don't know how to describe it.

Maybe with this Sencha contest we'll see some good ones.

~~~
Joeri
We've yet to see a web app that meets or exceeds the experience offered by
native desktop apps.

Natively built apps are almost always "better" because they're closer to the
OS and implement the native UI conventions. At the same time, web apps are
almost always cheaper, because you don't have to develop for each platform
from scratch (or suffer a lowest common denominator experience by using a
cross-platform non-web dev framework.)

Mobile has the same dynamic. Mobile web apps can get away with being worse, as
long as they are "good enough" and available on all platforms. The app store's
ease-of-shipping bonus has delayed this, but the shift to mobile web apps is
pretty much inevitable because of the cost of development and the ease of
deployment.

~~~
Lennie
Why would a HTML5 app need to exceed the experience of a native app ?

It needs to meet the needs of the user, that's all.

And if that can be done with X-platform HTML5 then that might be the advantage
the developer is looking for.

------
ttt_
I'll be saying this as a user.

I wish most developers would turn to HTML5 today, like right now, and avoid
native apps at all cost unless there is really no alternative.

Why?

Because I remember the browser wars and how much it was a terrible idea and
the terrible experience it made for users who simply could not experience the
internet from a single starting point. This time it's not simply a matter of
downloading another browser, if there's content I want to consume and there's
not a native app for my phone, what do I do? I buy a different one? What about
the content that I already consume and that's not over there? Should I have
multiple phones?

I could not care less if it's optimize to integrated well with the native
environment or some whatnot, let the browser handle that with default
behavior. I want the content, the feature, and not wait for companies to port
over apps from one place to the next.

This platform cult is pretty meaningless to me, in fact I don't even want to
buy any device right now because I'm pretty sure I'll get burned as a user
either way. The only platform I'm betting my money on as a user is the
upcoming Firefox OS. Hopefuly Mozilla will be able to undo the damage done in
this fragmented mess, again.

~~~
javajosh
I was with you until you said "This platform cult is pretty meaningless to
me." Actually the platform wars are quite meaningful insofar as they represent
large-scale manipulation of consumers. Both Apple and Google are playing the
following game: hey consumer, here's a shiny device, it's pretty cheap and
then we lock you into a 2-year contract, meanwhile you acquire apps that can
only be run an iPhone, and now even if you wanted to go to Android, you are
faced with the prospect of ditching your entire software library (or vice-
versa). It's called lock-in and it's a long-term manipulation of a market. I'm
sure that both Apple and Google rationalize that it's a way to recoup R&D
costs, and that's true enough, but it's a _sneaky_ way to do it.

There's also the not insignificant problem of app security. Not so long ago
there was a news item about the FB native app accessing contacts and uploading
them to FB servers. The web app cannot do that, and that's a Good Thing.

There's also another reason why HTML5 apps are better than native: they are
composable. There isn't much out there other than search engines that takes
advantage of this fact, but webapps can be composed, parsed, and otherwise
uniformly manipulated in useful and interesting ways. Android and iOS do
indeed offer some integration points for their native apps, but nowhere near
at the level that the web allows today.

~~~
blub
The web app already has all my data on a server somewhere. And that web app is
99% of the time closed source. And the company can cut me off, change the TOS
or sell my info to advertisers. Now THAT's a lockin.

While you identified the problem, the solution is a truly open mobile OS, not
webapps.

~~~
javajosh
How does a truly open mobile OS (and applications, presumably) solve the
problem of vendor-specific data lock-in? Data lock-in is a totally separate,
and far more difficult, problem. Part of the reason is that our data a)
probably wouldn't exist, and b) probably doesn't make sense out of the context
of being mixed together with everyone else's data. There is a strong a priori
centralizing force for some important kinds of data.

------
marknutter
The future is bright for HTML5 apps, clearly. There will come a time when
everyone's phone is fast enough to run apps like the FB clone Sencha made and
the need for native apps will start to diminish. However, we're still in the
transition period where there are a sufficient number of older phones on the
market that _don't_ run HTML5 apps well, so until they are filtered out your
best option is still native.

I do hope this app silences the HTML5 critics out there who say you can't get
a good UX with HTML5, though. The proof is in the pudding.

~~~
technoslut
>The future is bright for HTML5 apps, clearly. There will come a time when
everyone's phone is fast enough to run apps like the FB clone Sencha made and
the need for native apps will start to diminish.

I believe you're wrong. The question isn't whether HTML can keep up with what
exists today but what is offered in the future natively.

We are already living in a world with data caps and it will be so for the
foreseeable future. That alone hinders the capabilities of the web. We're not
even including the distrust that consumers have for paying for something
unless it is through a system owned by Apple, Amazon, Google and MS. This is
even including Gen Y users.

I have no doubt that the web is the future but the future is a ways off. There
are just too many obstacles that are in the way currently.

~~~
marknutter
I'm not sure I understand the connection to data caps. HTML5 allows you to
cache apps and data locally, and wrappers like Trigger.io and Phonegap allow
you to run an HTML5 app completely on the client without any reliance on data
from an outside network.

~~~
rimantas

      > HTML5 allows you to cache apps and data locally
    

In theory, yes. In practice: after all that shamanic dance trying to get all
this to work you will wonder, what's the point.

Native is just much much simpler to develop and more performant to run. Yes,
you loose the cross-platorm appeal, but which will appeal more to your
potential user: an app crafted to run on a few platforms (and therefore alien
on all of them), or an app crafted with a specific platform in mind? Not many
predict that desktop apps will be replaced by web apps soon, but for some
reason this a popular view regarding mobile. But it is backwards: on desktop
you have much more room to manoeuvre.

I think it is more likely we will see the web going a bit back to its roots
with a more pronounced cloud-web gaining prominence, basically backend servers
talking to apps (and browsers) API calls and JSON exchange.

~~~
marknutter
> after all that shamanic dance trying to get all this to work you will
> wonder, what's the point.

Shamantic dance? It's trivial to the point of being a non-factor. You wrap
your app in Phonegap, and make json requests to the web if you need data from
there. Otherwise, it is stored and runs on the client.

> Not many predict that desktop apps will be replaced by web apps soon, but
> for some reason this a popular view regarding mobile.

For most things, desktop apps _were_ replaced by web apps. Which is why
Facebook doesn't maintain a desktop app (or Hacker News for that matter).
HTML5 proponents have never made the claim that it will replace all native
apps. Instead, it will replace data/list style apps like Facebook or
productivity apps, which frankly, make up the vast majority of apps in the app
store.

~~~
rimantas

      > You wrap your app in Phonegap, and make json requests to
      > the web if you need data from there.
    

You know what? I think you should try to do all those things you deem so easy,
and then we can talk. Or you can google for phonegap success stories.

    
    
      > For most things, desktop apps were replaced by web apps
    

Can you name a few? I was impressed with GMail in 2004, in 2012 I am using
Sparrow to read and write my email.

    
    
      > Instead, it will replace data/list style apps
    

In Cocoa Touch I have highly optimised UITableView for that. In HTML I have
what, UL, OL and LI? And If I need to handle selection, edition, caching,
cells with different layouts: HTML5 is still superior? Should I send markup
over the web too? Or should I go mad trying to make offline cache work
properly? If I am doing native I have CoreData. If I am going web route what
do I have, IndexedDB? Or do I?

~~~
indiecore
>And If I need to handle selection, edition, caching, cells with different
layouts

I'm not going to touch the rest of your comments but mutability of
presentation is really not the place to wage your battle against HTML/CSS/JS
from. Dynamic presentation is really web tech's strong point.

------
umsm
I was tasked with creating the phone app for the company I work for. Here are
the key points:

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

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

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

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

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

~~~
marknutter
Yes, but it _will_ be ready, and the question is will devs and firms that have
invested all their time into native development be ready too? It would be
prudent to be ahead of the curve when the horizon is so clearly visible.

~~~
spydum
The problem with being a platform that serves such a large audience (indeed,
one that gets paid based on the eyeballs it can sustain) is that you need to
cater to the largest range of devices and their performance. It's the same
reason enterprises still support such obscure browsers and OS's (XP/IE6). They
just aren't willing to sacrifice the overall experience of those who are slow
to upgrade in favor of pushing the technology forward.

~~~
marknutter
You don't have to support obscure markets if you don't want to. I'd say
covering iOs 5+ and Android 2.3+ is going to cover an area most companies
would be pretty happy with.

And let's not forget that OS fragmentation affects Native developers just like
it does HTML5 developers (especially on Android).

------
eatsleepdrink
Nitro Javascript engine? It could be an important difference between this test
and FB's app. Safari gets it. It seems ambiguous still whether UIWebView users
get it.

A more apples-to-apples comparison would be to put it in a iOS app running
UIWebView and see if the performance is maintained. I'd certainly be
interested in the results.

~~~
loumf
It's not ambiguous. On iOS, only Safari can JIT JavaScript. This is because
Apple doesn't trust your app enough to let you made code pages. It also
doesn't trust the app it makes when you install a web app to your home page
(and it's not just a Safari bookmark).

I suspect the latter may change, but I wouldn't count on the former.

------
TeeWEE
Good work. But they are cheating in one main spot:

\- they use a proxy to cut down data transfer

Good choice, but comparing it with the orignal app is not valid anymore (its
not really html5 that is making it faster)

Anyway its still a very fast mobile app, and html5 is sometimes the best
choice to make.

Because it is very expensive to write a different app for all platforms
currently. However, currently, it is also very time consuming to have a html5
app that is on-par with native, and works well in both android and iphone.

So its a tradeoff really, html5 is not better than native, or vice versa.

Like so many things in life, it depends :-)

~~~
joshtynjala
> comparing it with the orignal app is not valid anymore

Facebook could have done the same thing with their app too, so I don't see how
this affects validity.

~~~
TeeWEE
If I am comparing the speed of two cars, but one car contains 5 persons while
the other one only contains 1, then it's an unfair comparison right?

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

~~~
Joeri
You're supposed to use the build tools to generate a file with only the subset
you need for your project.

By the way, the download time for the native app is also non-zero. With
appcache you pay the framework's download cost only once. Admittedly it still
needs parsing to load, but i haven't had this seconds-long parsing experience
myself in my sencha touch app.

~~~
city41
> You're supposed to use the build tools to generate a file with only the
> subset you need for your project.

Both Ext and Sencha Touch are very monolithic. When you use Sencha Command to
pair your app down to just what it uses, it still pulls in well over 90% of
the framework.

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

------
programminggeek
HTML5 is cool and you can do a lot with it, but it has some very real
drawbacks - like Android.

Also, if you are doing a bunch of optimizations to make it fast on HTML5, then
you're basically doing the same work as writing a native app, so what are you
gaining by doing a HTML5?

Seriously, at some point you can get a better user experience, have better
access to native API's and can really leverage the full abilities of the
device by going native. So, you know, go native.

Disclaimer: I have wrote HTML5 mobile apps and I think it's a great developer
experience, but it feels worse as a user.

~~~
marknutter
But this argument makes no sense. When you go native, you have to write N
number of apps for N number of platforms you want to support. The point is
that making a great mobile app is _hard_ no matter what stack you choose to
use.

It's also a bit disingenuous to say you are forced to optimize every HTML5
app. The whole point of Sencha's blog post is to advertise the fact that
they've abstracted away all those optimizations you need to do so that
developers can focus on building cross platform HTML5 mobile apps.

~~~
NinjaWarrior
HTML5 is not the only way to achieve cross-platform. In native world, HTML5 is
just "one of them". There are many cross-platform frameworks and you can
choose any one you like. Look this report.

Cross-Platform Developer Tools 2012 | VisionMobile
[http://www.visionmobile.com/product/cross-platform-
developer...](http://www.visionmobile.com/product/cross-platform-developer-
tools-2012/) > the landscape of 100+ cross-platform developer tools

Actually this is a big reason I dislike HTML5 (or _I think HTML5 is wrong_ ).
Developers don't have freedom on languages and APIs. There are no healthy
competition.

And don't forget that web browser itself is a multi-platform application. You
can use Chrome and Firefox on Windows/Mac/iOS/Android. These are written in a
"cross-platform language" C++.

In addition, most video games are written in C++ so many games are released on
multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers
don't even know this...

~~~
marknutter
> HTML5 is not the only way to achieve cross-platform.

Nobody here, as far as I could tell, was suggesting that.

> In addition, most video games are written in C++ so many games are released
> on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web
> developers don't even know this...

But wait, aren't iOS apps written in Objective-C using Cocoa Touch and Android
apps written in Java? I don't think you can simply write your app in C++ and
call it cross platform.

> Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong).
> Developers don't have freedom on languages and APIs. There are no healthy
> competition.

I've honestly never heard lack of freedom as an argument _against_ HTML5. This
argument is strange. How is iOS any more "free" than the web?

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

~~~
marknutter
You're forgetting one small point: you have to write two (or more) native apps
once you go that route. Hence the reason Facebook's Android native app came
out roughly 6 months after their iOS native app did.

~~~
tterrace
That's true but wouldn't you (as of today) still be much more comfortable
going that route with a non-trivial project? Less time spent on the cutting
edge battling the idiosyncrasies of the platform and more time building your
app.

~~~
marknutter
It depends on the resources available. If I were a CEO and the company was
flush with cash, I'd just brute force it by hiring native developers across
all platforms or farm it out to specialized native dev shops. If was a CEO of
a smaller company tight on cash with a bunch of web developers, however, I'd
go the HTML5 or hybrid route because it'd be the best utilization of my
company's time and resources. This isn't a black and white issue.

~~~
suprfresh
Definitely agree. I'm not sure why many people think its just so cut and dry.
The tradeoffs between html5 vs native are pretty much known at this point.
Take those and rationalize along with the resources you have available, the
cost, and time you can afford. Just ship something.

------
u2sonderzug
Looking at this from a different point of view maybe altogether, one of the
big issues I think concerning HTML5 mobile web apps (not used in a native app
wrapper to get included in the appstore) is __discovery __.

Where do I actually find compelling mobile web app user experience when I am
trying to solve a problem in my web browser as a user when I search using a
search engine?

I noticed a few years ago that Google cut out their mobile only results option
- and now when you search for anything on a smart phone you get a mish mash of
mobile friendly and conventional web optimised results. For a little while
there Google would put a little mobile icon next to mobile optimized results -
but that has gone too. I know perhaps the point of mobile is moot now - since
we have a sizeable amount of tablets accessing websites too. But just in my
own personal research all my friends who aren't techy say they much prefer
sites that look right on their 'touch' (be it mobile or tablet). For instance,
is there even such a thing as a 'mobile web app store' out there?

If consumers had an easier way of finding great mobile web apps perhaps this
would grow this channel? I'd be interested in perspectives on this - maybe I'm
looking at it the wrong way.

I'd also like to make the case that I think HTML5 will continue to make a very
important contribution moving forward - why? Because as we get more devices,
it's really starting to get silly how many apps I constantly need updated and
feel like I need syncing. I think as prices come down we will find ourselves
with several devices for home, out and about and at work - using the 'fat
client' model of installing all these apps just gets annoying.

------
kaolinite
A lot of the points that they make in the video are just flaws with Facebook's
implementation of the app, rather than being a point for HTML5 or a point
against native.

Truth is - HTML5 apps can be made to perform well but there are limits.
Battery life suffers and you may find in future that the cool
animation/whatever you wanted to add in is too laggy (especially on older
devices).

~~~
marknutter
Older devices will slowly dissipate from the market because of the ubiquitous
two-year contracts, though, and eventually everyone's phones will be capable
of delivering native-like performance on HTML5 apps. It's only a matter of
time.

~~~
alifaziz
The moment older devices slowly fade out from the market, and new high end
devices started to fade in, native app speed now doubled.

~~~
marknutter
Doubled from awesome to... awesome? Native performance is the goal. I don't
see how much better a data heavy native app like FB can get, but I do see how
HTML5 apps can get better.

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

I wished jQuery Mobile has _Infinite List Component_ that handles the list
item recycling the last time I used it. It is the equivalent of
UITableViewCell's dequeueReusableCellWithIdentifier.

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

~~~
kamjam
_we recommend at least iOS 5 or Android 4.1_

I agree with you. I was going to ask this same questoin. From TFA, they stated
above. Well, that _really_ sounds like Mark Zuckerberg didn't know what he was
talking about at the beginning of this year!

A lot of people are still on Android 2.X as you have stated, and a lot of
people are on slow Android devices. I know several people on ZTE Blades
running 2.3 which were available over a year ago for less than £100. Sure, not
the snappiest of devices, but usable. What is the HTML5 version going to be
like for these users?

Blah blah blah, hardware limitations, you can't limit yourself to lowest
denominator etc. But Facebook _HAS_ to support all these users. And it's not
just users in the western world. There are millions of users in third world
countries who pretty much exclusively access Facebook from mobile phones,
usually not the latest spec (or even close) or most up to date s/w version (I
doubt many would even know how to update it).

I agree that web apps are the way to go. But it is VERY much going to depend
on your target audience.

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

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

~~~
speg
This. It's a lot harder to screw up when using native SDKs vs. the plethora of
HTML5 frameworks, some which are more mature than others but none really seem
to have a "standardized" way to easily make a performant app in the same way
that the native SDKs do.

------
matwood
_We saw the latest generation of mobile devices — running at least iOS 5 or
Android 4.1 — push ever increasing performance and HTML5 implementation
scores._

Do the new native FB apps only run on iOS5+ and Android 4.1+? HTML5 may be
ready on those platforms, but Android still has a lot of 2.x phones floating
around. How do the HTML 5 benchmarks for iOS 5 run on the original iPhone 4?

------
rodion_89
A couple of months ago I mentioned these same notions about the Facebook app.

<http://jairaj.org/2012/08/27/facebook-for-ios.html>

Although I have to admit that Sencha's implementation isn't all that great. If
you're going to offer an alternative, at least make it better than the other
option.

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

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

~~~
jbail
_"HTML5 will never be as capabable as native..."_

I think its very possible to imagine a world where HTML5 can be just as good
as native. It comes down to two things:

1) HTML5 needs more JavaScript APIs to access hardware like camera, contacts,
etc. It's is not very difficult to imagine HTML6 (if you will) supporting this
in much the same way that it supports geolocation today.

2) Improved JavaScript performance. It's common knowledge that the embedded
web views on iOS are much less capable than Safari. There's no reason to think
this would continue forever. Furthermore, better JavaScript performance makes
things like image progressing, music recognition possible.

Right now, you are absolutely correct that HTML5 is not as capable as native.
No argument there. But, this gap narrows as time goes on. I firmly believe the
opposite of you; we will eventually see a time when web-based applications
rival native apps in terms of power and functionality. You can already do some
awesome image processing stuff using canvas and JavaScript.

This is only the beginning...

~~~
dotborg
The idea of HTML5 is to avoid using JS in your app.

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

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

~~~
Joeri
Sencha's wp8 support is in beta, it doesn't ship until next year.

~~~
smrtinsert
so then its not ready.

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

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

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

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

------
tagliala
IMHO if in 2013 a HTML5 application needs iframe + js proxies hacks to perform
faster, there is something deeply wrong.

Sorry for my English

------
drivebyacct2
All the HTML haters (I jest, but that's not a totally unfair characterization
of some here) should check out the Chrome team's efforts for Web Components
(although I think the name just changed) for Dart/W3C spec, and AngularJS.

They make building HTML apps much, much, much more similar to building native
applications.

