Call for jQuery 1.8 Ideas

Posted on by

We’re ready for our next round of community input, this time for version 1.8! This is your chance to suggest things we can fix, add, change, or remove in jQuery to make it better.

You can add a suggestion using this form; whenever possible provide links to a bug report, a page with a detailed description, or implementations that represent your idea. We’d like to have all your input by December 5 so we can read and discuss them before setting the 1.8 roadmap.

Many thanks for the suggestions left on our earlier blog post about how we can improve jQuery by trimming it down. We’ve gone through those comments and have a few thoughts about how we can address some of them in future versions.

Create a configurable download builder

Several people wondered why we don’t have a way to build a file with just the parts of jQuery you need, since jQuery UI, for example, has that option. It’s not quite the same situation. You know if you are using, say UI Accordion because you call it directly. You often do not know if you or some plugin you include on your page is using $.fn.prepend() or $.fn.animate(). Whether you are using them may even depend on parameters you pass to plugins at runtime.

To keep jQuery development manageable and ensure that CDNs can offer a single file that everyone on the Internet can share and cache effectively, the team wants to stay with a single file as its primary offering. Creating a configurable download may improve file size marginally, but it also complicates documentation, plugin use, and debugging. That is a lot more work for both you and us.

We’re already beginning the efforts to improve modularity by eliminating unwanted dependencies inside jQuery; many of the deprecated features we announce will be directed towards removing those dependencies. By laying that groundwork, others who want to create their own smaller subsets of jQuery or modular versions should have a much easier job.

However, we believe we can do even better than that, and would like to offer automated ways for any user to create an optimally minimized file that includes both application code and just the needed parts of jQuery. In particular, we are working with the Google Closure Compiler team to see if we could use its ADVANCED_OPTIMIZATIONS option. We’ll have more information on our progress as it develops.

Wait until version 2.0 before removing things

We’re sensitive to breaking all the existing jQuery code out there. That is why we are deprecating things as early as possible, so that people have plenty of time to change their code. Just because we deprecate something today, it does not necessarily mean we’ll remove it in the next version. We believe the list of things actually being removed in 1.8 are minor and unlikely to affect most users.

If our experiments with Closure Compiler pan out, we may even be able to leave in many deprecated features but they will be automatically removed if you don’t use them and build a custom application file that includes jQuery. That would be the best of both worlds.

Remove IE 6, 7, and/or 8 support

This topic comes up constantly, so let’s try to put it to bed once and for all. People tend to greatly overestimate the amount of code in jQuery that is specifically related to IE. Most of the problems in IE 6 and IE 7 are also present in IE 8, so there is no real size or complexity benefit to dropping support for the first two as long as that last one still has appreciable desktop market share and must be supported. Nobody (including Microsoft itself) likes these Jurassic Park browsers, but stripping out support for them right now would break web sites for many users.

That said, we know that older-IE support is not required in some scenarios such as mobile browsers. We are looking into ways to put as much of that code as possible into a single clearly marked block so that it can be easily removed by someone who is willing to create their own custom jQuery version. It may also be possible to get Closure Compiler’s help with this issue as well. However, we are not sure that will even provide a significant space savings in gzipped file size, and it won’t offer a performance boost since those code paths aren’t taken in other browsers.

Remove jQuery.browser

We have documented for nearly two years that we intend to move jQuery.browser into a plugin, and several people suggested it in the comments as well. Browser sniffing is not a reliable way to look for features, we recommend something like Modernizr instead. The regular expressions used for browser sniffing are large and don’t compress well; moving it to a plugin will ensure that only the people who use it must pay that size penalty.

What about your ideas?

Please do take this opportunity to give us your input. The team is looking forward to reviewing your suggestions. Oh, and don’t forget to try jQuery 1.7.1 soon!

111 thoughts on “Call for jQuery 1.8 Ideas

  1. Split jquery in many js files, one with functions for dom manipulation, one for ajax, one for utilities, one for core jquery (basic $ support).

    This will permit use of parts of jquery in other environments other than browsers, that dont have an dom for example, or permit use of $ajax in webworkers, and many other use cases.

  2. Extend new HTML5 audio and video features like the following methods : .play(), .pause(), .paused().


  3. arozhik on said:

    Most important thing is google closure compiler advanced optimization support.
    Do not remove old browsers suport, use conditional compilation instead.
    Put everything, what can be cutted off under conditional compilation blocks.

    I love jquery, but now it fat and ugly, time to change that with adv. Optimization.

  4. David Svetlik on said:

    Just brainstorming now, but how about using .is() without arguments instead of “ugly” get(0) or length jQuery check?

    So this
    if ($(‘#some-element’).get(0)) {}

    would turn into this
    if ($(‘#some-element’).is()) {}
    /* plus it returns a “real” boolean value, hurray! */

    Also, had somebody already mentioned that is slightly confusing to have methods called is() and not(), whilst each is doing completely different thing?

  5. I think a built in templating engine would be useful. I know templ() is not going to be progressing but I’d like to see a built in alterntative.

  6. Anton Smatanik on said:

    first thing – Remove IE 6, 7 support. it is matter of principle.

    second – contact plugin developers and announce them changes, they will be prepared and update they codes. in another way you may add in they plugins maximum usable version of jQuery. don’t be hold back by low quality plugins!

  7. Kevin on said:

    The performance of transition effects like show(time), hide(time), fadeIn/Out, animate etc. performing very bad on mobile devices. It would be nice to see some progress there.

  8. I’ve been searching for a way to select a parent element that is more than one parent back.

    parentsUntil() doesn’t work as it finds every parent until you reach the correct parent. At the minute I’m using parent().parent().parent() which is ugly and feels horrible to write!

    Ideally, I’d like a property like nth-parent(3) which would select the 3rd parent (Or Great-Grandparent).

    Does this functionality already exist?

  9. Brian on said:

    There’s very little extra I’d want to see added to jQuery. I’d rather have the weight come down, and especially advanced mode CC support.

    For most of the new HTML5 stuff, I don’t see it belonging in jQuery core. I could much more easily see JQuery-UI-like projects being added; JQuery Media, JQuery Communications, JQuery Storage, etc.

    That said, there are three basic things I almost always end up extending into jQuery:

    makeClass(), removeClass() – create and delete css classes. jQuery lets you add and remove classes from elements, and we all know the negatives of inlined css… but jQuery has nothing built in to make it easy when you need to manipulate classes on the fly.

    The other is just basic syntactic sugar:

    enable : function (bool) {
    return $(this).prop(‘disabled’, !bool);

    $element.enable(false); is just so much easier to read clearly compared to $element.prop(‘disabled’, true); The same thing for .readonly() and .check().