My personal experience is that if you use an mvc framework like angular then there wont much left of jquery mobile. JQM is the attraction of simplicity. Simple things keep Simple. If you think about an mvc it is obvious that you work in the field of rich user interfaces and maybe for some reason you cannot do it native. JQM is limited when its going to built a natural feeling rich UI. The way JQM works withs Forms or handles the Ajax-Navigation for example is all not useable out of the box in a rich UI. When your intention is to substitute these features by using an mvc then what is left of jqm then? The widgets, transitions...! Now the sole question is if its worth to include jqm just to have some iOS like Controls; or is it better to work out a simple mobile css.
I am using jQm 1.2 on top of Ember (latest) with ember-data for the persistance layer (also latest with tweaks).
The app is intended to replace a fully functioning point-of-sale system written in flex.
Unlike what @stefan.gebhardt says, I find this combination to be very flexible when you define roles for each component. Because jQm targets the UI heavily, I can give the role of "skins"/styling/appearance solely to jQm and then the heavy lifting is done by ember and ember-data.
Each widget that I use I created an Ember View that I use in my app, for a popup, I have App.PopupView which takes care of setting up and tearing down.
To get you started here is what works for both backbone and ember to remove navigation conflicts:
Thats my point. With the code snippet above you're disabling the hole jqm navigation inftrastructure because it not fits with a RIA architecture. So you are using then jqm as a "widget only"-framework. This is pretty much that what i wanted to say with my post above. What is left of jqm after that is html enhancing and css skining and thats, in my eyes not that much. But of course its working.
I've looked into the code of bridges between jqm and AngularJS, Ember and Backbone.js.
I seems to me like it is not very easy to understand where the responsibility between the frameworks and jqm begins and ends. I think this could be a nightmare to debug when problems arise.
My first intention was to share some logic of a desktop browser webapp with a mobile app (same backend, same model, different templates).
I didn't dive too deep into all MVC frameworks/libraries but at the moment I think that Backbone.js is the one which is least invasive in combination w/ jqm. I'd prefer ember or AngularJS for the desktop browser app, but here I'll most likely choose Backbone.js.
Still I'm very interested in your opinions or experiences - the coding has not yet started.
If you are making a native app, consider the alternative of using the Rhodes framework. It runs a server in the device in which you can write models and controllers in Ruby. It has a simple ORM implemented over SQLite (HSQLDB on Blackberry) .
It is not meant to be a clone of Rails, but it is very similar, so you can do a lot of re-purposing if you happen to be using Rails as a web backend.
Leave a comment on watusiware's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic