11 comments

[ 3.1 ms ] story [ 44.7 ms ] thread
Is this just a fork of jQuery Mobile?
Looks like jquery mobile + client side MVC-like framework.

Adding node.js as a requirement to do client side development seems like it would be a big deterrent.

(comment deleted)
How does this compare to http://www.phonegap.com/?
A better comparison would be backbone.js.

It don't see any mention of it building natively to devices on the site. So you could still use Phonegap in combination with it.

I'm currently building a mobile app with backbone.js + jQuery Mobile + Phonegap. Backbone works great for me so I see no reason to switch.

Care to talk more about how you're using Backbone.js and jQuery Mobile?

I'm interested in this combination and wondering why this project wouldn't choose to build on Backbone.js. It seems they would just be reinventing the wheel here and losing the benefit of using the same library on full apps and mobile.

This is probably more worthy of a blog post.

To summarize in a few lines. Backbone.js has been wonderful for creating the MVC backend for the application. It uses Localstorage and syncs with a REST server on demand.

jQuery Mobile is still very rough on the edges. Most of the headaches I've had have been with getting jQuery mobile to work properly with the backbone controllers.

If jQuery Mobile was less buggy, performed better and was more Backbone.js friendly, then I would highly recommend taking this route.

But even though its not quite there yet, it's entirely possible to build a multi-device mobile app using backbone+jqmobile+phonegap. Just be prepared to hack both libraries.

I'm not quite seeing how this differentiates from JQTouch or just vanilla jQuery Mobile.

However, since I'm doing mobile HTML5/js development right now, I'll check it out after work and give my thoughts after playing around with it.

One difference at least seems to be that this encourages development entirely through Javascript. In that sense, it seems more like trying to compare jQuery to Backbone.

The disadvantage of this of course, is you lose the true cross platform (plain html) capability that jQuery mobile and jQtouch both provide. Though I don't imagine that would be hard for this project to facilitate at some point.

Interesting - I'm about to start working on a mobile site and I noticed there weren't many mobile frameworks that also used the MVC pattern. However, at first glance, I don't like that it requires node.js since I'm mostly on Windows.

This is just me nitpicking here: why did they feel the need to define two global variables (YES/NO) as aliases for true and false, respectively?

We were defining it just for better readability:

isAsync:YES just sounds more naturally than isAsync:false.

Saw and liked it in Objective-C....