But it's not really true, at least if you want a truly fluid UI... although I think it's possible to make UI written in HTML5 feel native, I have yet to use a single complex webapp that truly accomplishes it, unless it's hidden in a UIWebView in some app I use. (Gmail might come close if it didn't apparently use onclick instead of ontouchstart, and custom scrolling instead of -webkit-overflow-scrolling: touch, for no discernible reason.)

It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow.

And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing.

As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.

FWIW, I've had to do my desktop web development without the benefit of frameworks for the last 4 years, since the latency constraints on Google Search preclude using them. It's nowhere near as hard now as it was in 2007, when you had to worry about IE6/IE7/Firefox/Safari, and IMHO is the biggest hole in most web developer's skillsets. Mobile HTML5 is easier still as the vast majority of the market uses Webkit, though the Mobile Search team here tells me that you can't assume that since there're still a bunch of shitty Blackberries around. If you still need JQuery/Prototype/Closure to do anything useful in Javascript, I really would recommend learning the browser-native HTML5 APIs and CSS3, because they aren't that much harder and perform much better.

(I do like the better layout systems and widget libraries of native frameworks - I did desktop app development with Swing and MFC before HTML/JS, and it really was significantly easier to put together a complex UI that matches the native look & feel with those. HTML5 gives you the opportunity to be creative that you don't have when you overrely on a framework, though.)

Livestand by yahoo! on iPad, but y! killed it. i hope they bring it back. it was really awesome app.

To be clear, I'm not necessarily backing his argument. Just clarifying it.