Jquip

jQuery in Parts

View the Project on GitHub mythz/jquip

Run the test suiteDirectly in your browser

Run Backbone testsCompatible with the latest release

jQuery getting too big?

The primary goal of this project would be for the feedback/demand to kickstart jquery.com into re-organizing its code-base so it's more modular since we believe we've proved the most useful parts of jQuery is a fraction of its code-base.

To this end, follow this project if you want jquery.com to measure the demand for this. Another project with similar goals is http://ender.no.de/ - for node.js. JSLim is another project that takes a novel approach to reducing code size with advanced minification techniques.

Zepto.js is another great alternative to jQuery, it's fast, light and optimized for mobile/webkit browsers. It's a popular option for PhoneGap developers with full support for the Backbone.js, Underscore.js and Spine.js frameworks. It has very recently added support for the latest Safari, Chrome, Firefox and Opera browsers - it makes use of latest EcmaScript 5 APIs without shims so if this is your targetted market, we encourage you to try it.

Based on recent posts it does looks like jQuery wants to build a slimmer jQuery. Although we don't think giving a trim is going far enough, we hope they perform larger re-structural changes allowing us to use most of the useful parts at a fraction of their cost. Their recent conversations into future file size reduction do sound promising.

Introducing jquip - aka jQuery-in-parts. Build Status

Smaller, Lighter, Faster, more modular jQuery - include only the parts you want! Don't use it, Don't include it.

Minified & gzipped code sizes (v.03):

Query Engine options (not required for modern browsers)

The core jquip.js is only 6.6KB (minified and gzipped) - a fraction of the size of jQuery.

Has 90% of the good parts of jQuery (rest to be added plugins as needed), small enough to drop-in as source saving an external js reference.

Automatically downloads parts needed for older browsers

Sizzle.js is only added on demand (if it's not already included) from cdnjs.com for browsers that need it (i.e. <=IE7) as we believe it's the optimal way to download shims for browsers that need it.

Most code has been ported from jQuery or Zepto.js and optimized where possible, e.g. internals use underscore's native _.each over jquery's slower $.each etc.

Licence: http://www.opensource.org/licenses/mit-license.php (Same as jQuery and Zepto.js)

Build customizable jquip packages with the jQuip Library Builder service

The jquip Simple Demo is also available to try online, whilst a version compiled with Google's Closure Library (Advanced mode) is in the repo.

Disclaimer

This is NOT an official jQuery.com project.

Code-base will now be more stable as we've reached our goal of jquip.js (with the events + docready plugins) working in Backbone.js, there are likely a few fixes still to be added but the core is close to feature complete and wont require the major refactoring done recently.

We would still like to hear feedback on issues/non-implemented core functionality so we can measure the API popularity of missing pieces.

News

v.03

v.02

v.01

pre-alpha, first release

Roadmap

What's in the box? - i.e. the 90% good parts

Methods marked with * are only partially implemented.

Methods operating on a $(selctor)

static methods off $

Plugins

Pick and choose the parts of jQuery when and add you use them.

Other parts of jQuery can be Added via Plugins which is simply a matter of copying or including the script after the core jquip.js.

events

Methods on $(selector)

Helpers on $(selector)

blur focus focusin focusout load resize scroll unload click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup error

documentReady

yep, it's a plugin!

css

ajax

based on David Flanagan HttpUtils modfied to work like jQuery's ajax.

custom

Plugin Authors (adding your own plugins)

Extending jquip:

You can also include Sizzle.js or qwery.js above jquip.js (using IE's conditional comments is a good approach), it will automatically be registered. The q-{queryEngine}.js plugins are also self-registering.

Intercept the $(){ .. } constructor and inject your own implementation. Return true to short-circuit. e.g: from the docready plugin:

$.plug("docready", function ($) { $.hook(function (selector, ctx) { if (typeof selector == "function") { this.ready(selector); return true; } }); ... });

Limitations

Many corner cases we feel that are not likely to be hit in normal development have been intentionally stripped out, it's therefore possible for older browsers to experience some issues if you code hits these edge cases.

In addition to its fluent API, jQuery does a lot of cross-browser normalization as well as sanitization and quarantine for edge cases in older browsers which no doubt makes it a safer but slower option.

Non supported examples:

We prefer not to take the perf and code-bloat hit of this quarantine - if your app does hit one of these edge cases you will either need to code a specific workaround for your apps usage (which will in all likely be more optimized than jQuery's general purpose solution) or simply move back to using jQuery.

Best Practices

Contrary to the strong-held opinions of many "javascript experts" DOMContentLoaded is rarely the fastest solution to run your app's logic. It is a safer option but in most cases your app will run faster if you execute your javascript somewhere below the HTML elements they reference even if it's at the bottom of your page it will fire before DOMContentLoaded which will no longer be required. This guidance is from the Google Apps and YUI developer teams (amongst others). If you can't control where user scripts are placed, DOMContentLoaded is still a suitable option. This answer on StackOverflow provides a good overview over when to use it.

We thought we'd clarify as we've received a lot of feedback (aka strong opinions) on this subject - this is why jQuery's popular docready is a plugin that's not included by default - simply include it as a plugin if you wish.

Similarly related, for best page load times you should move scripts to the bottom of your page, e.g. before the closing </body> tag.

If you're not referencing jquip near the bottom of your page and don't have either the events or docready plugins included, you should call $.onload() in your own post DOMReady event. It performs post processing tasks like downloading Sizzle.js (for <=IE7), calculates browser feature support, etc.

async script loading

As of v.03 the recommended approach to load scripts is now in $(callback) which gets fired right after all on async loaded scripts (inc user scripts) have been downloaded, which is still straight away for modern browsers (i.e. when no async downloads are needed). This recommendation can be ignored if you are only performing primitive queries (i.e. by #id, tag or .class) where querySelectorAll or Sizzle.js are not needed.

For older browsers (<=IE7) Sizzle.js is downloaded on demand, if ajax plugin is included JSON is also downloaded if it doesn't exist.

User and plugin scripts can be loaded dynamically with $.loadAsync(url, cb) which get loaded before $(callback) is fired. Additional scripts that are not needed on first page loaded can be downloaded with $.loadScript(url, cb).

Our recommendation for ultimate performance is to have a single reference to bundled and minified scripts needed immediately when the page is loaded. Followed by async downloading of all scripts required by your websites later.

Pre-fetching scripts needed on subsequent pages so its hot in your browsers cache is also a good idea.

Mini Query Engine (jquip.q-min.js)

Weighing at just 0.6k query-min is an ultra fast selector engine for browsers that don't provide native support for the querySelectorAll APIs (e.g. <=IE7). It works by offloading as much work as possible to the browsers primitive document.getElementById(), document.getElementsByTagName() and document.getElementsByClassName() apis.

On our last JavaScript heavy project, performance was improved by 7-8x in older browsers. If you're having performance issues with older browsers it's worth evaluating.

All selectors require an Id (i.e. #) Tag (e.g. INPUT) or class name in each child selector.

Valid Examples:

For optimal performance in <= IE7, the first child selector should be a tag or an #id as it cuts down the amount of DOM traversing needed to be done in JavaScript since there is no document.getElementsByClassName() available.

jquip Library Builder Service

The project now includes the node.js /server/jquip.builder.js so you can host your own jquip Library builder service internally.

Contributing

I'd love help with this so Contributors and pull requests are very welcome!

The main task that needs doing is to get all the missing jQuery parts in as plugins and a comprehensive test suite so we can properly identify the parts of jQuery supported.

Feedback is welcome, drop me a line on @demisbellot.

Contributors