Web Developer Admits: Objective-C Beats HTML5 | Hacker News Reader

Web Developer Admits: Objective-C Beats HTML5

engblog.polyvore.com

25 pointsjesskah25 comments

Right tool for the right job and all that jazz.

We don't need more flamebait like the OP.

One of the points I was trying to get through, and perhaps didn't do a great job of, was that I keep seeing people/apps trying to use HTML and various wrapping frameworks / toolkits to create the look and feel of an iOS app. Even worse, many of these "apps" don't even need to be apps (end of the article).

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.

Beats it in how easy it is to create, yes. But HTML5 is cross platform, and if done properly, the speed differences are not noticeable to the human eye.

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.

They did not "literally duplicate the iOS functionality." After months of work, and modifying their own framework, they produced...a technology demo, which omits core functionality like searching.

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."

No, of course they didn't duplicate every bit of Facebook's functionality. You missed the point, I'm afraid. The very specific functionality they targeted performed as well as the native app, and in some cases, better.

They are both pulling the same data from Facebook, and just displaying it to the user. One is native, one is HTML5.

Given the considerable resources that Facebook has, and the amount of effort they put into an HTML5 application at first, it seems reasonable that native still gives a much superior experience. Sencha has done some great things, but one must consider the bias Sencha has for HTML5 to be great. It is in Facebook's best interest to deliver the best experience possible, but it is in Sencha's interest to deliver promising HTML5 results.

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.

> Given the considerable resources that ____ has ...

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".

Agreed. The resources Facebook put into HTML5 are irrelevant. 9 women can't have a baby in 1 month.

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.

I do agree that it comes down to a few people and their personal taste, but I still contend that those few people are often some of the brightest in the industry.

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.

Do you have any example of HTML5 "done properly"? I don't believe I've ever seen any. (Yes, saw the video link, but it would be nice to have something I can actually try.)

Sure. Gmail.com run on the iPhone. In some cases, such as opening a subfolder that I haven't been in, loads more quickly than Apple's Mail app. (This is provably because of IMAP lag.)

Scrolling has a noticeable and jarring pause when reaching the top or bottom of the list, and in general isn't smooth when the "pull to refresh" area is visible, at least on my 4S. It's really good overall, but definitely not quite in the realm of no noticeable difference from a native app.

This is a result of Google's decision to not "perfect" this on their web app - but it could be. It's just low priority.

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.

For more examples of HTML5 in use, check: http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-o...

> HTML5 done properly

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)

I wasn't aware the gmail ios app is HTML5. Do you have some link that claims that it is?

It's a hybrid app. Native with some features implemented with web views.

http://geeks.everything.me/2012/12/09/451/

> Native with some features implemented with web views

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"

An email app like Mail just download and keep offline copies of most of the mail. Opening the app and it instantly shows the pre-downloaded stuff. Yes, so in that sense, the mail app is faster. Bravo.

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 have to disagree. I didn't mean that Mail.app "shows stuff" faster because it's cached the data and there's no roundtrip to the server (BTW, Gmail.app does this too). I meant the animations, scrolling and general speed with which "things" happen after you touch something or swipe.

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.

But I don't. I just loaded up gmail.com on the iPhone, and its nearly flawless. If I click the "show all folders" button, it seamlessly swings over. No lag, no jittery animation.

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)

I loved this quote: "The best way of creating that awesome app is not to insulate yourself from the power of the operating system you are running on but to embrace it."

Personally I think "HTML5" is a misnomer even as a buzzword. Better to compare a specific browser instead.

Title should be renamed to "native code beats html5". I'd rather program in html5/js than obj-c anyday!

Its not really a question of what you'd prefer to code in (you'll always prefer something familiar) but what delivers the best result for what you're trying to do. In essence we created two real, not test, apps, one using HTML and one using Objective-C. The clear winner was Objective-C in our experience, at this time. Creating a great mobile interface using HTML5 is certainly worth doing and can be done - but I dont think it should be made to look and feel like an app (either in safari or wrapped) since the "not-quite-right" issues just keep piling up, and if you want the look and feel of iOS you should just go native in the first place.

Reply on news.ycombinator.com