Web Developer Admits: Objective-C Beats HTML5(engblog.polyvore.com) |
Web Developer Admits: Objective-C Beats HTML5(engblog.polyvore.com) |
We don't need more flamebait like the OP.
We went this route too and hoped we could re-use lots of code we already had but, as you say, the right tool for an iOS app is Objective-C. Un-JITed JS inside a wrapped app with a zillion Objective-C stubs using the DOM in a view-like manner its not meant to represent just doesn't do it.
In fact, "Fastbook" is proof that an HTML5 app can be FASTER than it's iOS counterpart. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
Check out their video. They literally duplicated the iOS functionality, and made it faster, with HTML5.
Also, I don't agree that the Fastbook app is HTML5 "done properly." From their article:
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...events, positioning, styling, and JavaScript code have to be proxied between the parent window and the child sandboxes.
I would characterize this as "heroics."
They are both pulling the same data from Facebook, and just displaying it to the user. One is native, one is HTML5.
I'm not sure we can mark this as a win for HTML5, but what Sencha did is impressive. HTML5 will certainly continue to grow, and this is a fantastic step forward.
You are also correct that HTML5 is cross platform, and Sencha has proven that HTML5 can be taken into serious consideration when starting a new project.
This is far from true. Example: Given the amount of resources Microsoft has and all the effort they put in UX it seems reasonable they have made the best UX decisions
No, that's provably not true.
It seems logical that the large resources of big companies would work that way but that's not how the real world works. It always comes down to just a few people and their taste. Rarely are these kinds of decisions made based on anything more than a few people's opinions whether it's Microsoft, Google, Apple or Facebook. Whoever is the lead programmer for a particular project or lead UX designer for another or one of the 2 or 3 people around them decide this stuff based on nothing more than their professional opinion. That opinion might be more informed than your average joe but it has nothing to do with the size of the company and their "considerable resources".
I've seen Gmail.app on a friend's iPhone 4S (with dual-core A5) and it's slower than Apple's Mail.app on my sister's iPhone 3G (with a 300MHz ARMv6, which I think is under clocked to 230MHz or something like that).
When Google (king of the Internet and HTML5) fails to "do HTML5 properly", then the rest of us really don't have much chance.
(and, no, it's not (entirely) UIWebView's fault. If Google were allowed to use Nitro or V8, Gmail.app would be 40% faster. But that iPhone 5's CPU is like 20 times faster than that crummy old iPhone 3G)
The 40% faster boost takes us into the range of not-really-noticeable. If there were a dev tool to make efficient HTML5 apps just like there is to make native, and this speed difference was in miliseconds, not seconds, developers will flock to HTML5.
I think the biggest problem with HTML5 is development obstacles, and mobile browsers being under-powered.
Think of it this way: creating a fluid GUI can require AJAX, and a number of other tricks to streamline loading. But a native app can load the whole GUI at once instantly. To make a fast and responsive native app is hard NOT to do, while doing the same in HTML5 is HARD to do.
That being said, the example such as Microsoft does ring true, and perhaps Facebook didn't give HTML5 a fair try. I still think that overall evidence has been pretty clear that native can still provide better performance.
And as I said, even if HTML5 rendering gets 40% faster, it's still extremely slow compared to native UIKit stuff. HTML5 is like 3 times slower than UIKit if you have any animation (and by animation, I don't mean really fancy stuff even - even moving a rounded rectangle from point A to point B).
It's not this drastic on Android, but iOS's graphics stack has been heavily optimized so a lot of stuff happens in layers in GPU. UIWebView, because of its implementation, does (almost) all its renderings in CPU and almost by definition, is much, much slower than anything that's GPU-accelerated (and takes at least 50% more memory and power).
The difference is like night and day. Open Gmail.app in iPhone 4S or 5 (the new Gmail.app that was released a few weeks ago is faster than previous versions though), and open Mail.app in an iPhone 3G. You'll see the difference clearly.
In fact, I use the built-in Mail app all the time. Loading gmail via IMAP in this Mail app is actually slower than the Gmail.com web app. For example, if I enter a subfolder I've created (labels), and haven't entered it in a long time, there's a considerable lag on the Mail app, and 1 second wait in the Gmail.com web app.
(iPhone 5 BTW)
Well, some is a little bit misleading. More like most (60-70%) :) - the old app was like 95% web-stuff. The new one (released a few weeks ago) does things more "natively"
Just as there is lag and jittery scrolling when loading older posts in the Android native Facebook app, it's not a result of the platform, but a result of poor design, or not putting the effort into that one area of optimization.