Even with the native app, the same poor design decisions are being repeated once again. For example, not caching data locally between screens - an especially egregious oversight in the context of mobile networking.

I think the broader issue however, is just how out of touch Mark Zuckerberg was with regards to mobile and perhaps even emerging web technology in general.

He eventually admitted to screwing up (great!), but then got it so wrong again, by declaring HTML5 as the culprit. The problem was almost certainly more attributable to people and management issues, rather than a technological misstep, irrespective of whether that resulted in a more palatable conclusion for Mr Zuckerberg's ego.

As for the Sencha demo, after installing it on my iPhone 4s it works really well, and installing it as app on the home screen makes it virtually indistinguishable from native. I think it's fair to say this is a rather significant achievement by Sencha, indeed considering it's a part time effort.

Which makes one wonder what a full time team, with the right leadership and resources, could have achieved at Facebook.

On android that's another game and you can forget about all those cozy animations and only devices with android 4.0+ will perform well, or at all (in my case anyway).

Also I'm really not sure why people currently associate html5 apps with bad battery life, personally I did not see any noticeable differences in usage from a native one, hell native use a lot more the gpu so it should be worse.

However the same code did run on iOS blackberry and Android. However the experience was sub-native on most devices. And we really needed to do a lot of tweaking and work to get the native look and feel on iOS.

So if you want to be the best, no matter the costs, go native. Otherwise Sencha is not a bad choice to make. It really depends on your requirements.

Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text.

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

I would say the opposite is true. Native doesn't protect you from quirks. On the contrary, it makes them worse. If you use HTML5, you're (eventually) dealing with standards that you can rely on so that you know your app will still work years down the road. Point your modern browser at the website for the movie Space Jam, and it works exactly the same today as it did in 1996.

But with native frameworks, you have no such security as a developer. The "standard" is defined as "whatever the documentation currently says". Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature without deprecating it first? Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself.

And that's to say nothing of the power that you lose when you write native apps in today's world of walled garden app stores. Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like blue today"? Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell your iOS app outside of the App Store, and it won't run on any other platform.

  > For 75% of its development, HTML has been taregeted at
  > greater things than hyperlinked text.

  > If you use HTML5, you're (eventually) dealing with standards that you
  > can rely on so that you know your app will still work years down the
  > road.

  > The "standard" is defined as "whatever the documentation currently says".

  > Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature
  > without deprecating it first?

  > Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself.

 I guess your up to date web app has better luck with broken Android browser of the previous versions.

  > And that's to say nothing of the power that you lose when you write native apps in today's world of walled
  > garden app stores.

 I lose no power. Some people are scared by walled gardens because… well, because they are supposed to get scared.

  > Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like
  > blue today"?

 Oh, those scary stories of the days past. There is a name for them: FUD.

  > Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell
  > your iOS app outside of the App Store, and it won't run on any other platform.

HTML first showed up in 1990. It started its evolution away from "hyperlinked text" with the introduction of elements like forms in 1995. It has been around for 22 years, and for 17 of those it has been for far more than hyperlinked text.

> Oh, those scary stories of the days past. There is a name for them: FUD.

I'm glad to hear that you haven't yet been bitten by placing your eggs in a basket held by a single company. Please do some research before assuming that your experience can be relied upon.

Personally, I've been bitten repeatedly. Forgive me if your screams of "FUD!" elicit a chuckle.

While the form element was probably a great improvement (I wasn't there, not until '98 until my first steps in HTML), think about literal meaning of the word "form" for a bit. It's still a document. HTML was normal documents with hyperlinks in it, add form elements and now you also got fill-in document with hyperlinks.

Yes you could potentially make web apps that way, but everything (everything) required a server-roundtrip. It may be a hard to imagine what a far cry that was from what we now consider a "web app". Every single UI change had to go through a form submission request and a response from the server that contained the entire page regardless of what was updated. "... but .. frames!", I can hear you wonder, well IMO frames weren't all that. They didn't really make selective updating possible in pretty much the same way as forms didn't really make web-apps possible either. Plus, I can't remember if there's been any time people weren't hating on frames (it broke navigation and bookmarking--sound familiar?).

I say this, because I remember discussing the idea of web-applications in 2002/03 or thereabouts with a friend in college. I had just discovered the SCRIPT SRC trick so you could actually load data from the server without reloading which was paradigm-shattering magic, at the time (the technique is still in use as part of JSONP, btw). I had already written a chat-client and it was beautiful, I wanted to pick his brain for more ideas of what to do with this new ability.

(please remember, this discussion occurred during the height of the Browser Wars, 1-2 years before the tide started turning. if you weren't there, or doing webdev at the time, imagine it 10 times worse. digital trenches, man)

My friend told me pretty much the exact sentiment I see pop up in this thread here, that HTML was intended as a document markup language, not for application building, and that while we could hack all these cool interactive features on top of a markup language, and surely these were some quite impressive feats of creative thinking, it would always remain on shaky grounds because you should build an application framework from the ground up with application framework foundations, not by bolting things onto a markup language. Back then, I knew this to be true (one picks up a few things about software design, studying CS) even though I didn't want it to be, because the tech was so cool and the possibilities so enormous (hackers should be able to relate to that feeling :) ).

Now, many years later, I got what I wished for, and my friend got to be right.

(at some point CSS and JS incompatibilities started to slowly disappear and the Browser Wars came to a sort of uneasy peace--this was a slow realization I can't really say when it happened, but I don't have to resort to black magic anymore to write a basic webpage that works in FF,IE,Chrome and Opera--particularly if I write it in Opera first)

Looking at the state of web-apps today, we are using that technology ("AJAX") to build things beyond my (I won't say "wildest") imaginations back then. But it's still clunky here and there. Javascript is still a pretty crummy language (though I love coding for that weird prototypal beast), and as soon as you write more than 5 lines of DOM-manipulation, you're going to want a framework like jQuery. And for some mysterious reason, people still manage to write JS code that works in one or two, but breaks in the latest versions of other major browsers. Minefields are hard to clean up I guess. There is more, but you get the idea--and IMO a lot of the problems can be traced back to bolting application-behaviour capabilities on top of a document markup language.

Still, I do believe we're heading in the right direction. Things can be made much cleaner than say 5 years ago, and there's new standards looming on the horizon that may make things even better. Sure, a from-the-ground-up design would have been so great and so clean. But the industry would have probably found a way to crud it up regardless. And given the global scale and heterogeneity of the Internet as a communications medium, the immense market forces that come with such an environment, personal computing capabilities over time, maybe this was the only way it could've been pulled off, who knows?

  > HTML/CSS/JS is exceptionally good at building user
  > interfaces. 

Why is the idea to craft an app for each platform using native tools so scary? Were all those desktop apps using cross-platform toolkits successful? Or do they look alien everywhere?

I do like web. I love web. And that's why I don't like to see it turning into frankenweb.

Something about the premature roots of something evil something.

Only if your background is HTML/CSS/JS. If you have no web background, figuring out the idiosyncrasies of CSS and JS, while very doable, is still very time-consuming. I can't imagine it being any faster than someone going the native route assuming they do not have an existing web skillset to leverage.

That's true for anything. Objective-C is not exactly intuitive.

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

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.

"Holding users firmly by the balls in the cloud"? If your service already resides in the cloud, the technology you implement your client software in, hardly matters, no? Facebook app, whether is HTML5 or native, is largely unusable without a persistent internet connection. Yes, I am interested in doing less work. I do care about standards, thanks. I certainly wouldn't stand in the way of anyone wanting to learn whatever they want. If you want to build an app to learn Objective-C, all the power to you.

1. Use industry standard libraries (jQuery or a lightweight alternative.

2. Can ignore pathologically broken browsers (<=IE7 mainly)

How is that a fair comparison to native apps? A native app can run on one platform. Making native apps pixel-for-pixel identical on multiple platforms is way more of a pain than doing so with HTML5.

A few points:

1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with.

2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given version of a modern browser behaves under different OSes. And if a page works correctly in an old version of a browser, it is very unusual for it to start working incorrectly in a newer version of that browser.

3. Maintaining a single code base with special cases for different platforms is way easier than maintaining multiple disparate code bases. It's the old DRY principle.

The fact is this: writing an app and supporting multiple OSes (even multiple versions of the same OS) is hard. Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless. But the idea that it would be somehow easier when maintaining entirely separate code bases is ludicrous.

2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.

3. No different than methodologies for writing portable native code with the added benefit of control and performance.

> Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless

Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.

Ideally, HTML5 apps would automatically be completely portable everywhere, but that ideal isn't realistic. HTML5 is still great for simplifying porting (which is not to say that it is without disadvantages) because it gives you a single code base that behaves nearly identically everywhere, and then you have to tweak it. Constrain your problem to a couple of mobile browsers, and the number of tweaks drops dramatically.

Now I understand the draw of simply maintaining separate code bases. It's the same draw as the urge developers have to rewrite a project from scratch. It feels like starting with a clean slate will be more efficient than hunting down and eliminating every blemish. But that's an illusion. Working from a clean slate, you'll still be tweaking out blemish — it'll just take longer before you even have the privilege of thinking about them.

>2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.

Oh, they're there. But in aggregate, they aren't as bad as working across different native platforms.

>Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.

Yes, I realize that some clients require it even though it's usually pointless. Some companies have more money than sense, after all. My point was that it's hard no matter how you develop the app.

I can't believe you just said that. -- every seasoned web developer.

It seems like JavaScript is the new ActionScript.

Not even close.

The browser itself used to be too slow for many use cases which led to Flash filling in the gap, but thankfully that's rapidly changing with improved JIT VMs and HTML5 standardization efforts (WebRTC e.a.) all leading to the eventual demise of Flash.

Hence; JavaScript is the new ActionScript.

P.S. They're both just ECMAScript flavors so in that sense I would say they're very close ;)

Not really. That just happens to be the most common use of it.

You make it sound like learning the native will magically lead to create better working apps. This is just not true.

I'm not saying going native doesn't have to potential to help developers create faster apps, but when making something like this feed, HTML5 would not seriously be a bottleneck.

And you're claiming to be a "very experienced web developer"? Dunning-Kruger much?

This requires special permission to add execute permission to memory that the app had allocated and used for data, which is pretty dangerous. So Safari gets it and 3rd party apps do not.