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. 1. Underscore.js
    Integration of the Underscore.js library would be great.
    It’s small and very handy, but some of the methods exist with different names.

    2. Modularize jQuery in jQuery-Base (headless, e.g. for Node.js) and jQuery for Browser environments.

    3. Full Integration in Selenium as alternative selectors.
    OK, this is a bit off-topic for 1.8, but this is just a wish ;-)

  2. @Heinrich Gobl

    The node community doesn’t need a headless jQuery file. It doesn’t have a DOM and it has ES5.

    Modularizing jQuery is great, but it should defiantly only stick to the browser environment.

  3. Seperate animations and queues from objects so they can be used as more then just chains. Creating advanced effects or something as simple as parallel effects shouldn’t force you to use object bound chains as a base.

    Having effects and queues as stand-alone objects would still allow for those chains but opens the way for easier and more advanced use of animation.

  4. charles sistovaris on said:

    jQuery doesn’t need to be improved it’s already awesome.
    Why don’t you use your talents to make a framework like Backbone (or others MVC alike) better ?

  5. 1. Modularize jQuery with async (AMD) modules. The benefits would be huge: developers could use only the parts of jQuery they actually need, without you having to create a custom download builder. For example if I want to do simple DOM manipulation but not animation, I can have a pretty slim jQuery file. Using an AMD build tool like the one RequireJS comes with you get a single optimized file containing just the parts of jQuery you require.

    2. Better mobile/touch event support. I’d like jQuery to register ontouchend events instead of click, saving me the 200ms conversion in the browser for example.

    3. CSS3 transitions/animations for all animations. There’s no need for the old way except as a fallback for old IE. CSS3 transitions look way better than JS timer animations, especially on mobile where they’re hardware accelerated.

  6. Can we fix the issue between jQuery, and nivoSlider? The slider lags balls, and dosen’t fully transition to the next images… Some part’s (little squares) are being left transition to transition… I regressed back to 1.6.4 I believe, and it’s NOT AS BAD… However that’s not the fix.

  7. 1. Templating (like the MS Plugin that you stopped supporting)
    2. Data Binding / Linking (like the MS Plugin that you stopped supporting)
    3. Local Storage / WebSQL abstraction layer, possibly with templating / data binding support
    4. Mobile build of jQuery for use with jQuery mobile which is smaller, like Zepto?
    5. Some kind of Retina image support so you dont need to roll your own CSS class detection and image swapping to show retina images in css on iphone 4+ and high dpi android phones

    Keep up the great work!

  8. @Stefano Zoffoli
    jquip is not a good idea, and jquery.css jquery.ajax functions are not present then what interest to use it?
    I use jQuery and ajax + CSS functions!

  9. Most points have already been made, but here’s my list anyway:

    1) Simple pub/sub mechanism for custom events (.trigger() is too complicated and namespacing sucks)
    2) CSS3 animations and transforms
    3) Touch events
    4) Some of the better stuff from Underscore.js (pluck, filter)
    5) Simple templating (Mustache-like), or a printf()-like function
    6) A very simple .random() utility function (basically the same as PHP’s rand())
    7) An URL parser
    8) The IE<9 HTML5 shim?

  10. Chris Kihneman on said:

    Over and over again i see people commenting on wanting modules. I am just totally missing the benefit here.

    The move to using CC to remove dead code is something i just had flat not thought about. Before the CC talk i would have been screaming for modules also – but looking at it – it just doesnt solve any issues. Take jquip for example – core, events, domready, css, ajax. yup i need those (mb not domready – but yea)! What i dont need are all the extra methods they bring to the table. I dont need all the append appendTo prepend whatever – i dont need ANY jquery aliases like mousedown click all that ‘stuff’ (i would be fine if they were removed all together – side note) – how would a module system EVER address these issues? It wouldnt – it cant.

    CC takes all the worry off of your head to concentrate on just getting it done (mind you CC still needs some work – but it sounds like they are on it).

    While you dev – you leave the full un-minified version of jquery up (like you should be doing anyways) – production time – CC all of it! Post. Done.

    What i would love to see is an easy way to replace sizzle with something else – it is a beast – and i honestly havnt ever seen a need for all the complicated situations it handles … i’ve got along just fine with id’s and a simple find (remember that whole class thing?). There are so many selector engines out there – im sure many of them would love to partner as an option for jquery (and make the appropriate changes on their end to connect properly).

    If all this happens i might be able to move back to jquery for mobile apps – right now it is just too slow and too large of a load to justify.

    Good work y’all – ur killin it! Long live jQuery!!

  11. Xavier Freymuth on said:

    [en] A track of evolution would be to look after placement for the elements of a page to each other.
    Browsers know how to place the items, they will make animations with css3 but there is nothing about the relative placement of objects relative to other objects.
    jquery.jcss_align.js is a plug-in which touches the problem but to go further it is necessary to integrate this kind of functionality.
    [fr] Une piste d’évolution serait de s’occuper des placements relatifs des éléments d’une page les uns par rapport aux autres.
    Les navigateurs savent placer les éléments, ils sauront réaliser des animations avec css3 mais il n’existe rien concernant le placement relatif des objets par rapport aux autres objets.
    jquery.jcss_align.js est un plug-in qui effleure le problème mais pour pousser plus loin il est nécessaire d’intégrer ce type de fonctionnalité.

  12. Recently, jQuery has added new types, like $.Deferred and $.Callback. Please keep doing this! I would love to see the jQuery Collection type get an actual name and factory (apart from $, I mean.) I’m not arguing against the almighty $, but it would be nice to expose functionality under its own name as well, so if I want to build a new set of HTML nodes, or query the Dom, I can do so explicitly.

  13. To me:
    – Craete multiple editions of jQuery for different demands of developers, just like eclipse.
    – Support n(n lte 3) latest versions of each type of browser only.(That is a pain, sooner or later)
    – create a IE-oriented plugin
    – Integrate with some lib or plugin like TweenLite/color-animate-plugin.

  14. It seems like a lot of people are still pulling for modular build of jQuery. I happen to really like the Google Closure Compiler approach. It’s an incredibly intelligent and robust way to remove cruft from your code.

    I would like the ability to extend certain jQuery objects more easily. For example, I have a case right now where I’d like to extend $.Deferred. The problem is that certain parts of the state aren’t stored as a part of the Deferred object, but rather as private variables within a closure. So if I make a constructor `Dfer` with a prototype of `$.Deferred()`, and create and instance `d`, as soon as I resolve `d`, all current and future instances of `Dfer` are also resolved. Of course, I can call `$.extend(this, $.Deferred())` in the constructor, but this isn’t nearly as fast.

  15. I’d like to see live() (and now on() ) events be applicable to any context, not just an immediate selector.

    There are plenty of situations where I need to use more complex filtering to get at the objects that need to be kept live. In those situations I currently have to use multiple live/on events in order to hook them up correctly.

  16. HTML5 everything. Supporting the old browsers is nice, but it’s more important to support the new.

  17. Size Size Size and load time!

    JQuery has gotten pretty big. Add a few pluggins (JQueryUI is HUGE) and it quickly gets out of control.

    The number one battle for my huge volume sites is speed, size, load time optimization.

    We all want the bells and whistles, but there has to be a better way to improve DOM load time. Defer as it is now doesn’t cut it, in most part because there is only 2 levels of priority.

    (Still without a doubt the best project/tool ever!!! TY)

  18. Francesco on said:

    I’d love that Jquery can switch automatically between standard animation and webkit-transformations:

    let me explain better:

    If i run a jquery animation on a desktop is ok but on an ipad is still kinda jerky.
    so jquery should be able to reconigze itself the OS/browser is active on and then apply the correct type of animation

  19. Sylvain on said:

    I’d be nice to know when an element is created so that we could execute a function when we generate HTML. Something like this:

    created: function () { do something }

    For now, the plugin livequery seems to be able to do this but I haven’t tested it. But if the core jquery library could do this…. PLEASE!!!!

  20. Carlos A. on said:

    I’m thinking about structure: a very basic jQuery core and everything else, the other features to be loaded on the fly (lazy loading) like plug-ins.
    To be honest I like the way it is right now, the only inconvenience is the size, but… code size and features are in direct proportion.

  21. How about getting the CORE jQuery code down to the size of, say, MooTools? That would be the best benefit to me at the moment.

    I REALLY love jQuery, it has everything I need, but sometimes it can be the largest thing on the site I am working on at the time.

    I know it’s a feature packed BEAST, but other frameworks offer similar functionality but at a smaller filesize. I no some nay-sayers will tell me to b*gger off and use those Frameworks, but those frameworks don’t have the support and the community jQuery does.

    So can we please PLEASE try to look at reducing jQuery’s filesize/footprint?

  22. Martijn on said:

    You are partly right. jQuery has been growing and growing, and that’s why some things are being deprecated already. But you can’t just remove functions and functionality because people are using it. “Screw them” is not an answer, which is hopefully obvious, so deprecating stuff is the next best option. This is being done with the new event (un)binding syntax, for example.

    Also, do not overestimate the actual size of the jQuery library. Any proper webserver will gzip/deflate it, leaving just over 30KB to be pushed onto the line. IYAM, 30KB for such a complete library is peanuts.

  23. Don’t drop support for old versions of IE!

    While it’s painful to support old versions of IE, many users have no choice when it comes to which browser they’re going to use. The organizations they work for determine what can and cannot be installed on their corporate machines. As a developer of web apps for these types of users, I appreciate that jQuery has maintained support for old versions of IE. If jQuery were to discontinue support for old version of IE, I would be forced to use another library.

  24. I want to get CSS properties in the case of “class exists in CSS, but a element has the class is not exists”.
    I think it may require a CSS parser such as JSCSSP.

  25. I would like to see the ajax response to not come back as failed when I retrieve a file with no internet connection. With the use the appcache/manifest files it is no longer pertinent to have a request fail just because internet connection can’t be found. It took quite some time to figure out why my setup of jquery mobile wouldn’t retrieve pages when in offline mode.

  26. I agree to drop old browser support. Supporting old browsers make people less reluctant to upgrade. Google doesn’t even support IE 6, and soon won’t support IE 7 (once IE 10 comes out). Also, MS is going to be rolling out auto updates in the near future for IE, so supporting legacy browsers just makes jquery bloated.

  27. Please add support for elements that are not in the HTML namespace but also in the DOM (like svg).

    Creating an svg element would be possible the same way as for a div with $(‘svg’, namespace). Currently you need to do document.createElementNS…

  28. 1. Selector by data. the same like $”[href]” just data.
    Because data can by javascript complex object, the selector may get an object as value to the selector.

    2. Selectors with parameters. It is unreadble to understand what this mean:
    $(“div[href='”+ myVar +”‘]”);
    insted i prefer a string format,like c++ PRINTF or c# string.format

    3. Add to utilities a function that equivalent to string format functions, like c++ PRINTF or c# string.format

  29. I definitely think you should consider dropping support for IE 6 & 7 but I’d say there’s still too many people using IE 8 to drop support for that just yet. I think this is generally supported by

    Any code, as little as it is, that can be removed from jQuery in relation to IE 6 & 7 I think will be very welcome of. There’s no better time now that Microsoft have officially announced IE6 is dead and less than 1% of the US now use it.


  30. Why would we drop older browser support? Come on people! That’s probably the 2nd biggest advantage of using jQuery (biggest advantage being the simplicity of working with the DOM and animations).

  31. I just read several comments mentioning a Pub/Sub module being natively added. I totally agree, with the exception of the fact that I just finished a Pub/Sub plugin for jQuery a couple nights ago. It’ll be available for download on my site ( tomorrow afternoon. Also, when the plugin site it back up it’ll pop up in there.

    I believe my Pub/Sub implementation is a great balance between power and speed and should definitely suit the needs of a very large majority of people.

  32. matt dales on said:

    Although i see a ‘discussed before’ reply in the core blog I would still like to push for Event Priority to be added to events.

    The advantage of event priority is in multi module development where events may well be bound to an element already and will normally fire first. If we want a later conditional event to fire first if it its bound then we cannot do it. Ideally of course we would write a whole interface with controllers etc before development but where that is not possible due to time etc.. event priority reduces code complexity and is a real day to day help.

    Pretty please reconsider.
    (I have sent jquery 1.7.1 with the event priority done to John Resig)

  33. sylvain on said:


    A function that detects when a variable changes value. Like this:

    var TheObject = new Object();
    TheObject.Property1 = “test”;

    $(TheObject.Property1).trackChange(function () {alert(“it changed”);});

    TheObject.Property1 = “new val”;

    “it changed”!

  34. Pls do not remove old browser support,becasue here,in China,many users are still using IE6, if jquery doesn’t support IE6, it means that, more than 33% users can’t browse webs which use jquery. Programmers in China will have to discard jquery.

  35. Vascanera on said:

    First of all: A lot of people complain about the size of jQuery. Well, the year is 2012, folks. We can now use caching for browsed resources. Cache jQuery. Load once, cache, use the (locally, duh?) cached file every time.

    Second of all: There isn’t any significant overhead on using some code for older browsers, but using that code is against any rational good progress. Corporations should ditch the old trashy browsers as well. Sooner or later, they will. The sooner, the better.

    Third: Personally, I think more (modern) events (e.g.: swipe, tap, longtap, pinch, zoom, rotate) would do for now.

    The rest is just natural progression and evolution of a (already) solid and mature library that got into the hearts and minds of so many of us.

    Keep up the good work!

  36. The year is 2012, people shouldn’t be using IE6-7 or even IE for that matter.

    Seriously, every day we are getting better libraries and better web functionality which need up to date browsers. Personally I think web browsers should make you update, like once you open it you get a message saying “To continue browsing the awesomeness of the web you must update your browser”

  37. Please expose jQuery.uuid. Sometimes I need to assign an element an unique id on the fly. (I’d rather not use timestamps for that. A counter is no solution either because I may be working in modular components and finding a valid incremental id would be inefficient.)