The differences lie underneath and appear when you start writing your app. If you prefer to write HTML and you think in HTML, then jQuery Mobile, App Framework, and Kendo UI are the better choices. All three of these will accept your app as a stack of DIVs, then parse and and lay them out appropriately. If your app is relatively static with a well-defined map of links between pages, this is a pretty simple way to program. You write HTML and it looks like Objective-C or Java, running natively.
Sencha Touch takes a different approach, asking for the app to be defined as big JSON object. Kendo UI can also work with apps to some extent, but its model and the included examples are generally focused on HTML first. With Sencha Touch, you're writing JavaScript and linking it together with Sencha's JavaScript libraries. I used Sencha Touch with some data-intensive apps that need to create dynamic pages on the fly. The data arrived as a JSON object, and I handed it off to Sencha to parse and display.
I could have done the same with jQuery Mobile, but it would have been trickier. My code would have been responsible for parsing the data structure and creating the elements. It's not that hard to do, but it's nicer to leave it up to the app.
There may be an argument for using the more programmer-centric approach in case the world of HTML changes. If the local app is responsible for changing the JSON into the right mix of HTML, it can evolve and adapt to different platforms. It might use different sets of tags for the different mobile platforms. Or as time passes and new architectures and strategies emerge, the next generation of the local code can adopt them. Your JSON stays the same, but the approach can change.
The argument against this approach is that all of this processing takes some time. It has a cost in terms of memory and time even if it's just a megabyte or a millisecond. However, I haven't noticed any problems with my apps, which use big trees filled with data.
As much as I enjoyed working in the JavaScript layer, I often found it a bit confusing. No matter how well done a framework's API happens to be, it's still entirely new. I understand HTML much better, and that's why I found myself gravitating to it whenever I didn't need all of the power of dynamic JavaScript. HTML is simpler -- and that's a big advantage.
I think many developers will also find success with the simpler frameworks, at least for static constellations of pages. It's possible to build amazing mobile apps using the same skills for building nesting DIVs normally used to create Web pages. This can allow someone who is proficient in Web development to do the work of someone who knows Objective-C and someone else who knows Java, all at the same time. This is quite a feat because it's rare to find a programmer who is up to speed on one, let alone both. HTML, CSS, and a bit of JavaScript are much more common. This produces the leverage that makes these frameworks so attractive.
This article, "Review: Mobile Web development frameworks face off," was originally published at InfoWorld.com. Follow the latest developments in application development and mobile technology at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.