The jQuery patterns and anti-patterns are pretty good reading for anyone who writes plugins. The reasons for anti-pattern status are usually cited with a link to a post that covers why the technique is considered poor form. For example: universal-selector.html and requery.html.
jQ.Mobi (GitHub: appMobi / jQ.Mobi, License: MIT X11) from appMobi is a framework aimed at HTML5 mobile browsers. According to the documentation,
jQ.Mobi, is the “query selector” library. I thought this was confusing because surely a web framework that targets WebKit only has to wrap a small amount of functionality around
querySelectorAll? In reality, this library includes most of what jQuery does:
$.fn, css and attribute getters and setters, event handling, and even Ajax methods. There’s also a user interface library, and plugin support.
Each part of the library is presented as a monolithic file, and it doesn’t look like they’re built from smaller files. If this was my library, I’d split each of these files up into modules, with a build process that can output monolithic and minimised files. I’d also consider using the Asynchronous Module Definition specification to structure the library. It’s also slightly difficult to find the source – the homepage has a button that prompts for an email address, with a greyed out link to “No thanks, just get the code”.
The jQ.Mobi site claims that this is a rewrite of jQuery that targets WebKit mobile browsers, but we’ve already seen this several years ago at this point with libraries like Zepto. And there are also mobile interface libraries that are compatible with both jQuery and Zepto, like jQTouch, so I question the wisdom of coupling a jQuery clone with an interface library.