Mostly because it's almost impossible to know. It might work with all of the functionality I use on a normal day, but then I'll try to branch out at some point in the future and discover that it's broken.
The developers are the ones who know what functionality is replicated and what isn't- going through myself and testing seems like a huge waste of time.
Not really, just run the Backbone test suite and substitute jQuery/Zepto with JQ.Mobi. It shouldn't pass straight away because I'm pretty sure that JQ.Mobi is missing a couple of the functions required by Backbone (see my post a couple of levels up) but it probably wouldn't be a huge deal to write them yourself.
It might take a bit shimming to get it to work but JQ.mobi supports a lot of the most obvious methods used by Backbone: .bind(), .unbind(), .html(), .ajax(), .append(), .attr().
It doesn't seem to support .delegate() or .data() though, so you would probably have to shim these (and probably a couple of others that I forgot) yourself.
Actually, you're right, it probably doesn't. I always use Backbone with the backbone.modelbinding plugin, so I forgot that it's not part of the Backbone core lib.
On a side note, the graphic that illustrates code size compared to Zepto and jQuery libraries is a bit misleading.
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.
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.
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.
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.
jQuery Mobile adds a lot of other useful stuff -- primarily the ability to create an iPhone-style UI from HTML markup. Unfortunately as other posters have mentioned, it's pretty slow.
Something about the marketing of this makes me feel uneasy.
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...".
This is OSS. Why is the trashing of other developer's work necessary in promoting your own?
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".
One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.
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.”
See also: “Those who cannot remember the past are condemned to repeat it.”
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?
It quite clearly states it is intended for the certain circumstances you describe, Webkit on mobile devices. I don't believe anyone would suggest using this for the desktop environment.
Why would I be talking about desktop browsers on a post about a mobile framework?
Firefox I know at the moment is a very minor browser on mobile, but it has the potential to grow its install base. Opera is massive outside the US (StatCounter suggests it’s leading worldwide [1]) and doesn’t use WebKit either. And Microsoft doesn’t embed WebKit as a default browser on Windows Phone 7.
It’s fine to make the choice that you only want to support WebKit but you’re cutting out potential users and that should be highlighted, not hidden away in the source code comments.
See I use Safari on my iPhone, so theoretically this shouldn’t annoy me. But I’ve made websites through the bad days of the desktop browser monoculture, and I don’t want the same thing to happen on mobile.
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.
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.
This is sort of thing that happens when developers start thinking that jQuery is "bloated" and that they can do better and start ripping out code without fully understanding the expected behaviour. Nothing in jQuery is there without good reason.
There's just far too much shit-slinging for me to even consider evaluating it.
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.
42 comments
[ 599 ms ] story [ 169 ms ] threadThe developers are the ones who know what functionality is replicated and what isn't- going through myself and testing seems like a huge waste of time.
Not really, just run the Backbone test suite and substitute jQuery/Zepto with JQ.Mobi. It shouldn't pass straight away because I'm pretty sure that JQ.Mobi is missing a couple of the functions required by Backbone (see my post a couple of levels up) but it probably wouldn't be a huge deal to write them yourself.
It doesn't seem to support .delegate() or .data() though, so you would probably have to shim these (and probably a couple of others that I forgot) yourself.
edit: Looks like JQ.Mobi does support .data() anyway: https://github.com/appMobi/jQ.Mobi/blob/master/jq.mobi.js#L3...
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.
One can argue that it's more or less OK for the radius ratio, but IMO the chart gives a falsy impression in general.
Did RWW even try it out before they wrote about it?
Where's the video?
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.
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...".
This is OSS. Why is the trashing of other developer's work necessary in promoting your own?
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".
I don't know, it doesn't sit right.
Zepto Closest Implementation: https://github.com/madrobby/zepto/blob/master/src/zepto.js#L...
JQ.Mobi: https://github.com/appMobi/jQ.Mobi/blob/master/jq.mobi.js#L3...
Zepto End Implementation: https://github.com/madrobby/zepto/blob/master/src/zepto.js#L...
JQ.Mobi: https://github.com/appMobi/jQ.Mobi/blob/master/jq.mobi.js#L4...
That said, it's all open source and there are only so many ways to write these functions succinctly.
Also, showing benchmark for only one test doesn't follow the scientific approach.
I left a comment on the page with these two points and it has vanished...
Skip.
When people like 37signals promote it as a tactic, people start to copy: http://gettingreal.37signals.com/ch02_Have_an_Enemy.php
Of relevance:
One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.
See also: “Those who cannot remember the past are condemned to repeat it.”
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?
Firefox I know at the moment is a very minor browser on mobile, but it has the potential to grow its install base. Opera is massive outside the US (StatCounter suggests it’s leading worldwide [1]) and doesn’t use WebKit either. And Microsoft doesn’t embed WebKit as a default browser on Windows Phone 7.
It’s fine to make the choice that you only want to support WebKit but you’re cutting out potential users and that should be highlighted, not hidden away in the source code comments.
[1] http://gs.statcounter.com/#mobile_browser-ww-monthly-201012-...
I tried their site on my phone, and got a nice "jQ.Mobi requires a webkit browser" popup, with a site that didn't react to any input.
And yes, I use Opera on Android.
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.
Funny how both rewrites are missing this level of detail, or it could just be further evidence of how much JQ.Mobi "derives" from Zepto
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.