Succeeding (with a Caveat) with Lavaca, Cordova 3.0, and BreweryDB
I've said it before, and I'll say it again - JavaScript MVC Frameworks are not my thing... typically. MVC is logical to me, but doing so much on the client-side often leads developers to only support a limited set of browsers/devices. Hesitations aside, I've found places where I feel MVC frameworks can shine. Only want to support hybrid apps where you take a native app and package web views in some fashion? You already are limiting the browsers and devices, so this can work. I won't go into the business decision to go down this route in the first place - but assuming this is your requirement, then a JavaScript MVC can be a great way to go.
All this to say - I've created an app called Local on Tap to experiment more with the MVC framework Lavaca, the latest release of Cordova, and a crowdsourced database for craft brewing called BreweryDB. I released it to the iOS App Store a month and a half ago, with the Android version coming soon (after a little more real device testing).
Lavaca
Lavaca has come a long way since its first version a year ago. If you've got Node installed, setup is quick, and the integration with Cordova is nice (although it was a lot more useful before Cordova 3.0's changes). Pull down a starter project, npm install, run "grunt server"... and you've got an app running on a local server. Run "grunt build" and you have a minified codebase ready to deploy to a server.
Lavaca has several recommendations stated out of the box with the starter app, but I chose to go a different route in many regards. There is a HeaderView that acts globally and based on Model changes will change the title and potentially determine whether back buttons should show, etc. I chose to keep the headers inside each View. This gives more flexibility in my mind, and also works more nicely with iOS 7 where headers and the status bar are tied together... and more closely tied to each individual view.
As far as working with it, it follows a fairly typical MVC pattern. You define Controllers that route to different Views with different Models, all while maintaining state, history, etc. The key to a successful Lavaca project might be in proper usage of the View's redraw method. To keep the app feeling snappy, as you click on links, I direct the user immediately to the next screen... even though the content for that screen is usually unknown and being fetched by an API call. After the new screen has completed its "enter" event and the API has returned with the appropriate data, the screen (or typically, just a section of the screen) is redrawn with the new content. Too much of this (or while animations and other events are occurring) and there can be flashes and a stuttering feel. Keeping it after "enter" and only doing the redraw once keeps things feeling responsive.
Cordova 3.0
I'm a visual guy, and command line has never been my friend. College professors swore that even when coding in object oriented languages, vi was the only true text editor. I never bought into it, but I'm starting to understand the benefits of command line tools. Adding a plugin is easy (if you know the git URL) and building a project is easy. Lavaca used to do a lot of this for us, but now Cordova does it on its own, and it's a welcome change. I've not yet experimented much with the merges folder, but it seems like a useful way to get around anything that requires it. Though, hopefully nothing does.
BreweryDB
I love the idea behind this service... and its reliability. They support the little known breweries, and since data is often populated by the fans of these breweries, it often is quick - even shortly after a tweet goes out about a new offering. The API is easy to work with and gives a solid amount of information. It is one of the best documented and well organized APIs I have worked with in a while.
I wanted to do this project quick and without a server component (to play with Lavaca), and since the BreweryDB service does not support CORS, packaging the app with Cordova seemed like a solid way to go. This, as stated at the beginning, means my requirement was for a limited set of devices.
Thoughts
After working through this project, I feel this lack of broad support is my only hesitation to do this more often. I'm a web developer, and any time I only see something work on an Apple device or something that supports touch I wonder why bother with the web. The web should be for everyone... and it's not hard to support them all. But you have to choose the right tools. And build the right way. And progressively enhance properly. And love the world.