JQ.Mobi Is A Mobile-Optimized HTML5 Rewrite Of the JQuery Framework | Hacker News Reader

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

readwriteweb.com

60 pointswerencole38 comments

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".

I don't know, it doesn't sit right.

Especially when parts are straight copies out of Zepto.

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.

They didn't even bother to change the indentation whitespace...

"fully ready to use in production", with absolutely no unit tests, and when the question comes up it's immediately dismissed: https://github.com/appMobi/jQ.Mobi/issues/2

Skip.

Funny as hell how they closed that issue with "trying to stop flamewar" comment :D :D

I feel the same. Here's what the circles should like: http://jsfiddle.net/vjeux/DSp2m/1/

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...

Why is the trashing of other developer's work necessary in promoting your own?

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.

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.

Interesting, John Resig shared that exact same critique when Zepto first came out over year ago: http://news.ycombinator.com/item?id=1843787

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

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.

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.

[1] http://gs.statcounter.com/#mobile_browser-ww-monthly-201012-...

Well, I can't argue, excellent point.

I'm sorry you're being downvoted.

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.

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.

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.

Hey, here's the git hub account w/ API examples: https://github.com/appMobi/jQ.Mobi

Ah, interesting, thanks. I'll take a look.

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.

Yup. All great projects but jQuery Mobile is just too damn slow. Drives me crazy.

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.

From their blog: "If you have seen our jQ.Mobi video, you’ll see we outline problems with jQueryMobile."

Where's the video?

http://www.youtube.com/watch?v=MwNdWZsRXgk

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?

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.

Does backbone use .data()?

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.

edit: Looks like JQ.Mobi does support .data() anyway: https://github.com/appMobi/jQ.Mobi/blob/master/jq.mobi.js#L3...

The idea is to drop in and replace jquery on mobile.

The idea is, sure, but can it? Zepto is supposed to be a drop-in replacement too, and it definitely isn't.

The claim they do not implement the majority of JQuery's APIs, only the most used ones, so I guess it depends on how much of JQuery you actually use.

Well, as an observer of these things, sign up for the beta and let me know how it works out.

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.

> Mostly because it's almost impossible to know.

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.

Reply on news.ycombinator.com