Worth pointing out that a week or so after this article was written the jquery mobile beta was released:

http://jquerymobile.com/blog/2011/06/20/jquery-mobile-beta-1...

I think the specific bugs he's highlighted are fixed, certainly on the platforms we're testing on.

No, actual persistent headers and footers are still not possible with the beta. They are possible with the experimental scrollview element. Personally, I find jquery mobile to be fairly useless without the scrollview element. Sencha touch has a scrollview, but the author doesn't mention that the only reason sencha touch has had any success is that it's scope is more narrow than jquery mobile's -- sencha only works on webkit browsers. Creating a scrollview element in a webkit browser is a fairly trivial task. Creating a scrollview that will work on a windows phone is more difficult, and this kind of problem is whats hindering jquery mobile's progress, but getting it right will ensure that jquery mobile will be the dominant mobile framework come 6 months from now.

I've been using a framework called ChocolateChip-UI that allows for persistent headers (and footers, with a very minor hack) plus almost everything else you'd want. I'm using it to build a Twitter client for the BlackBerry PlayBook.

Check it out: http://www.chocolatechip-ui.com/

Has anyone else played with the dojo mobile framework? It is rarely mentioned in these type of articles. We started using it mainly for business reasons but after playing with it for a while it seems to me to have a lot more functionality than jquerymobile and the speed of new features getting into the nightlies is pretty impressive

I haven't tried dojo Mobile in a project, but the demos on their website are either extremely slow or not functional on my duel core android phone.

This is an excellent summarization and well reflects my own experiences building mobile apps with Phonegap. I found that while Appcelerator is an interesting platform, it takes the developer too far away from the core capabilities of the mobile device. By this I mean that you have many options using their custom JavaScript API, but you get little control over the final product.

Conversely, while I ended up using Phonegap for a couple of published apps, I quickly ran into the limitations inherent of that framework. One big example was the desire to play video (either remote or local). The feature simply doesn't exist in the framework.

Despite the lack of features in some aspects, phonegap is still my preferred framework because it's extensible. I get the benefit of rapid development using html5, CSS, and js while being able to edit or add objective-c code where needed to make extra stuff work.

My final conclusions were that Phonegap is good for phase 1 apps or apps that are relatively simple. Native apps are the way to go if you expect high performance.

What PhoneGap does (expose Javascript APIs for direct hardware/native library access) isn't very difficult, so if you needed to you could add-on for anything PhoneGap is missing. The real value of PhoneGap is that they've done this work on a bunch of different devices, and set up dev environments for each of them. That's a lot of coding you don't have to do if you need to support many devices.

I've just been using Chromium browser on a small window on my desktop.

It has a really excellent JS debugger (with breakpoints and watches and so on) and acts enough like Mobile Safari that most of what I've been trying to do works just the same.

Wouldn't help much with "exciting" apps, but for information-driven stuff it works well.

He says "it’s easy to debug and make changes" when referring to mobile HTML5 development, but my experiences have been the complete opposite and the only concrete claim he makes to support this is that there's a buggy and slow tool you can use to run Web Inspector against a remote device. It doesn't even look like it has breakpoints. Am I missing some other essential tool that he assumes the reader knows about?

Weinre is buggy, but it works well enough, and the web inspector does have breakpoints for Javascript. As someone who's spent way more time in web inspector than XCode, I'd say it's easier to debug, but still less powerful than XCode's tools, especially when analyzing performance and timing issues.

I was going to make the same comment. Frankly, I barely find gdb to be adequate for debugging iOS code (lackluster support for Obj C 2.0 properties, etc). The idea of having to debug a significant amount of JS inside of a native app shell without a real debugger gives me chills.

The big hope is that XCode 4.2 reduces the overhead (i.e. suck less) of Objective-C through LLVM & LLDB's improved debugger, more static checking and automatic reference counting.

Concur, but so far I haven't seen much improvement with 4.1, which, I believe, is also using llvm by default for new projects.

95% of the time, debugging in the browser will get you what you need. Of course, the 5% of time that it doesn't can be really painful.

It's a joke. The are no crossbrowser frameworks because standards are non-existent, phones can't handle scrolling long lists, and are too underpowered for CSS animations. Really, there is no such thing as a mobile web app, there's only mobile webpages.