JQ.Mobi Is A Mobile-Optimized HTML5 Rewrite Of the JQuery Framework

Something about the marketing of this makes me feel uneasy.<p>The graphs that depict size are misleading. The initial release (today) is already at v0.9 and the site (opened 1 week ago?) says it's "fully ready to use in production" The video aims to enumerate and demonstrate a number of issues with jQuery UI and Sencha touch ("we can't get anything to work..."). "Zepto is slow", Zepto objects are big and have "large footprints". "We polled a large group of developers...".<p>This is OSS. Why is the trashing of other developer's work necessary in promoting your own?<p>On the other hand I do appreciate that someone has delved into mobile issues and is trying to address them. But why market it like this? Why tack on "an HTML5-ready jQuery" for no (apparent) reason. CSS3 transitions aren't html5. querySelectorAll is not html5. Those other libraries don't have their problems because they are not "HTML5".<p>I don't know, it doesn't sit right.

I wouldn't call this a rewrite of jQuery, it's more of a from-scratch implementation of a very small subset of jQuery APIs.<p>The semantics of the subset vary significantly from jQuery as well. Take for example the show/hide implementation. `.show()` blindly sets the display to block. jQuery remembers the value it had when you hid it (block, inline-block, table-cell, etc.) and restores that setting.

WebKit only. That might be acceptable in certain circumstances, but only if your definition of acceptability stretches to “95% of the world is on IE6; we don’t have to support anything else for our site.”<p>See also: “Those who cannot remember the past are condemned to repeat it.”<p>Edit: to downvoters, I’m not being cranky: I specifically wouldn’t use this because of this lack of compatibility and would advise against using it for the same reason (especially seeing as the couple of people I’ve pointed this out to hadn’t realised). Can you explain why you think I’m not adding to the conversation?

On a side note, the graphic that illustrates code size compared to Zepto and jQuery libraries is a bit misleading.<p>The shading and reflections suggest that the objects on the illustration are spheres, for which the volume ratio of jQuery to jQ.Mobi is about 500:1. If the objects are circles then the area ratio is still around 60:1.<p>One can argue that it's more or less OK for the radius ratio, but IMO the chart gives a falsy impression in general.

Buggy as all hell. Clicking on average takes two to get the UI to respond, the iOS transitions are awful and momentum scrolling is really bugged. No way you could use this on a proaction app.<p>Did RWW even try it out before they wrote about it?

I'm very interested in this- I'm currently building an app using jQuery+jQuery Mobile and I'm very disappointed with jQM's speed.<p>However, I'm up against a deadline, so I don't know if I'll have time to implement it, and I can't find any documentation or examples anywhere- are there any? That'll be key to working out if I can transition my code in time.

I've never had a need for JQuery on mobile. Since all mobile browsers support document.querySelector and document.querySelectorAll, I don't feel you gain that much from JQuery. That was always its killer feature on desktop. The event stuff is just sugar.

There's just far too much shit-slinging for me to even consider evaluating it.<p>I mean, cool, mention where your product does something a competitor doesn't. But repeatedly go for the jugular (with incorrect facts) and it really reflects poorly on you.

From their blog: "If you have seen our jQ.Mobi video, you’ll see we outline problems with jQueryMobile."<p>Where's the video?

I was wondering why to use this over Zepto. Then I saw the performance graphs. Is it really that much faster?

does anyone know if it's compatible with backbone like zepto can drop in and replace jquery on mobile?