Call for jQuery 1.8 Ideas
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!
I think there should be an “answerToTheUltimateQuestion()” function that, when called, returns the number “42”. I think that would complete jQuery.
Modularized jquery with require() and (automatic) lazy dependency loading of necessary parts.
jQuery has been credited with bringing JavaScript back from the brink of extinction, essentially by meeting three key needs: Cross browser support, easy-to-use syntax, and DOM access through CSS selectors.
With regard to cross-browser support, JavaScript development was hard-to-impossible without individual developers understanding the fundamental differences between JScript and JavaScript, and the IE bugs and memory leaks in between. This feature was essential to “bridging the gap” and making development of interactive websites that work on any browser possible.
Today, the browser support matrix is actually much more complex, with a significant number of variations on Android, iPhone, and forthcoming Windows Phone and Desktop-client JavaScript support (i.e. Windows 8). And while older browser use is certainly in decline, there is still significant enough use of older browsers such as IE6-8 that it warrants continued support in jQuery.
Based on this I make two recommendations:
1. Don’t drop old browser support.
2. Add or enhance mobile and modern browser capability, especially with regard to enhancing DOM and JS performance.
Please drop the support for older browsers!
If we still support older browsers then people are never gonna upgrade them. Definitely IE6 devs are not gonna use jQuery 1.8.
I recently used jQuery in an Adobe AIR app, not because I needed to even out browser inconsistencies (of course), but because it’s a familiar syntax, has great helper functions, and it enables using some jQuery plugins.
So, it would be great to start doing “targeted bundles” of jQuery, where I could select the runtime environments. For me, for example, I only need the latest Webkit. Other people might be doing PhoneGap apps just for iOS (which again, would only be Webkit). While it might not cut a lot of code, every bit helps, does it not?
Keep old browser support. Sometimes large corporations have their own (stupid) reasons to keep use of old browsers, and removing old browser support would mean, for some of us, that we can no longer use Jquery.
These so called corporations can use earlier edition of jQuery, they are not going to die. Why are they compelling us to watch a Black and White movie in a 3D Cinema???
Consider creating a “legacy” .js script that allows for backwards compatability will still being able to cleanup jquery proper.
I also don’t believe in dropping support for other browsers unless there is a significant performance or size benefit to doing so. From the sound of this article there isn’t, so there isn’t good reason for dropping IE6 just to torture people into upgrading.
After attending the jQuery Conference in Boston this year, I’d like to see a publish/subscribe model a la AmplifyJS (my favorite session from the conference) built into jQuery core. It’s such a smooth way of loosely coupling your JS code, and I think jQuery should take a better stance of encouraging people to write better JS code through any variety of patterns. I think the only downside of jQuery is that, while it’s approachable, it subtly encourages newcomers to write unmaintainable JS code, such as where you have everything inside a $(document).ready() block (or multiple blocks). Pub/sub encourages cleaner separation of duties, such as separating UI logic from business/validation logic from AJAX logic.
Please address ticket 7442!
I’m in favor of adding an officially sanctioned pub-sub plugin ( basically copy and paste what’s on the $.Callbacks doc page into a plugin, profit ).
Although file size is an important factor, I think that performance should one up that. With mobile web becoming more prominent, perhaps a focus on performance enhancements would greatly benefit jQuery Mobile in addition to making normal jQuery apps faster in general.
Help us reduce our code, especially in places where code minifiers can’t help.
For example:
$(…..).on(‘click’, function() {
var element = $(this); // <- why can't this or one of the arguments be a jquery object?
});
or
$(…).on('click', { a: handle1, b: handle2, c: handle3 });
Why don’t use window.requestAnimationFrame for animations? Obliviously adding setInterval as fallback
A verbose debug mode that would show developers when they are not using jQuery library correctly/ideally/using the latest API.
In theory this will help us write better code and figure out what plugins we should trash or rewrite.
The minimized version of the library would not include the debug mode code.
(Something like this existed years ago but was impossible to maintain as a separate project.)
@Thomas Jane:
> Definitely IE6 devs are not gonna use jQuery 1.8.
It’s not about the developer, it’s about the user. It’s one thing for a developer to say (as we have done at work) to not support IE6, but jQuery is exposed to so many people using IE6 that it’s not in their place (yet!) to remove IE6/7 specifics.
You should create a uservoice site or something similar where people can publicly vote/comment on issues, rather than doing this via blog comments and a Google spreadsheet.
As someone who uses jQuery in a corporate setting I can say major changes like .attr() to .prop() have held us back from upgrading. These are changes that can take up to a year for us to make, and that’s if we can get the right priorities set. Please make sure that whatever you do you don’t do it quickly. We are still using 1.5.3…and we are trying to upgrade! :)
As long as the changes won’t require us to do any major overhauls beyond the .attr() change then we should be able to cope.
I would also like to see more support for mobile device events such as swipe, direction, how long they held, etc. We get asked to support the iPad and iPhone and have to use a 3rd party for simple events.
For IE, you only need support IE8+
For Firefox and Chrome and other browsers, you only need support latest version.
Agree with what Seth says, in the last couple of major releases, several key modules have been updated, e.g. ajax, attribute, event, don’t know what’s coming next. Many broken changes have been done for these versions, in terms of the code base and plguins we need to be modified and tested, that would be quite some workload. So staying in 1.5.2 would be the right thing for us, and in terms of functions it’s more than enough.
Create two versions of jQuery: one for all browsers and one for new (or near future) browsers. First for compatibility, second for performance and html 5. First with all functions (old and deprecated), second with smaller subset of functions but with same names and parameters. Both versions may be used on the same site.
support all HTML 5 features :D
Did you see this? https://github.com/mythz/jquip
Modularize the library for sure, a builder like modernizr has would be awesome. And touch events are a must.
I’m not a jquery power user but i do my best. I have trouble using the .change function. there needs to be more robust and versatile ways to watch if an object like a select box changes. not sure if that helps any :)
and then chiming in:
2 versions of jQuery sounds awful. I get the logic behind it but it’ll only create confusion. the newer browsers just need to be layered on top. progressive enhancement etc. having to build your own script will be a pain.
How about an icon that says “This site uses jQuery!”. One that animates when you hover over it with like a unicorn jumping over a rainbow or something.
There are some areas which I think should be deprecated (and removed in 2.0) or changed to slim down the API methods.
* .size() – remove, just a wrapper for ‘return foo.length’;
* .stop() – change to .animate(‘stop'[, true])
* $.browser – remove and out to a plugin (as said)
* pub/sub – add lightweight(+extensible) into core, perhaps refactor event system to allow this without the event overhead (event objects etc.)
* Back with requestAnimationFrame (if solveable, which I think it is)
* Modularize the different js files in the project, e.g. load in just core+ajax, core+dommanip etc.
This is the ones I can come up with on the top of my head.
As a corporate / web designer user of jQuery there are only 2 things that I want from jQuery: speed, and convenience. These both are pretty tightly related for us. We always use jQuery from a CDN because of its size—and the best way to load it faster is to grab it from the CDN and hope it was already cached somewhere else.
What I really want is jQuery to be modularized, like the initial work in jQuip https://github.com/mythz/jquip. This way I can include/require what I need if I need it.
I would love to make all the core jQuery transitions and effects use CSS3 instead of Javascript timers.
I think modularization should be the main focus of upcoming releases, as I consider jQuery feature complete.
You can only throw out small parts of jQuery using the deprecation route. Modularize, and users will include what they need.
I read jQuery team’s concerns about modularization, but I don’t agree.
– CDN’s can host the “full” jQuery, with all modules. (Google also hosts modularized libraries by the way)
– Plugins should specify their jQuery module dependencies
– Exotic features should still be separate jQuery plugins
And of course modularization is extra work in documentation, plugin use, and debugging. But that’s what we pay you for… Oh wait…
I don’t agree with the reason that was laid out for not making a modularized download generator ala jQueryUI or Modernizr.
If i download the full version or link to the CDN, of course i expect all plugins in the world to work.
..but if i build a modularized download, it of course means that i very well know what i am doing and what dependencies i need for my website to function correctly, no ? :)
The only thing that i would expect from a download generator to do correctly, is to manage any internal dependencies jQuery has on itself.
You are even suggesting to make this available eventually via closure compilers advanced options, which kinda contradicts your first statement of breaking plugins ..which this will if anyone uses it :)
This choice of modularity is exactly what i would like.
..except i don’t want to have to check the project out via github install linux/ant and start configuring closure compiler stuff.
I just want to check 5 checkboxes on a website and hit download :)
Plugin compatibility, i couldn’t care less about. Almost anything you could wish to accomplish, you can do so in just a few lines of jQuery + css (and this is really where jQuery shines!). Not to mention that 90% of plugins out there ..code quality leaves a lot to be desired :( ..less modules you have in your site, less your site will be prone to errors.
Two features that would be useful:
1. Mentioned above, simplify the use of touch events so that gestures and long-press are easier to use
2. Knockout.js like features, wired up with Ajax to simplify watching the server for data. This should improve the maintainable of bigger apps that use jQuery.
This is a bigger idea and in all likelihood should be punted to to 2.0 due to the horrible breakiness it would induce:
Change jQuery.each to delegate to native .forEach if available.
That should make any action that uses this.each(..) in prototype functions faster, and anyone using .each for other purposes in their code would benefit as well.
The backwards argument thing in the iterator function right now makes this suck though :(
It would be a terrible mistake to remove support of older browsers!
While they are maintained and represent a decent market share, they HAVE to be supported. As said in above comments, it’s just about the user.
Performance matters, but users rule.
Besides, modularization of jQuery appears like a must have. If delivered as AMD modules, it would even avoid the need of the jQuery + $ globals, which is always a good thing, and it would even allow the use of different versions of jQuery, for backward compatibility.
outerHtml()
Oh, and templating
I’d like to see ajax events ( ‘ajaxError’, ‘ajaxSuccess’, … ) namespaced in the ajax namespace.
Provide build in functions for interacting with files. For example, you can even get a txt file without apache right now, why not have more ready-built functions that will get text?
Having more examples on namespaces would also be a good thing to add.
Jack you want text ?
Try $.load() & $.get() (see docs), couldn’t be simpler.
On behalf of all web developers that actually value their visitors, thank you for maintaining support for older browsers. Keep up good work.
Jquery seems to be complete in terms of functionality! You could try to make it even more faster but it’s already a very good JS framwork.
I propose you to help the development of Jquery UI which seems to be moving too slowly… Although this is a widely used library.
jQuery is already fast enough for me, hardware and comms are getting faster, not slower.
On the other hand, browser apps are getting more complex, so we need more help to test and debug them.
As has already been touched on, I would like to see a developer version with built in diagnostics, logging, parameter checking and useful error messages. Use that to get code right, then switch to the normal jQuery without all the diagnostic bloat for production.
please support jqtouch. i dont know what exactly the problem is but since 1.4.2 the newer updates doesnt work well with it.
i know that jqtouch should work with jquery and not jquery with jqtouch
but it worked befor so if you can fix this issue it will be great
thx anyway.
@lior jQTouch is dead (and was unofficial), the creator was since hired by Sencha. jQuery Mobile is official.
* About modularized downloads
If modularization really isn’t feasible, i would at least like to see some efforts to get a mobile specific version of jQuery.
You could move all legacy browser stuff (well ..anything related to browsers that are really only available on the desktop) to another module, and then be able to generate a full version for those who need it, and a light, mobile specific one (ala zepto) for others who need a lighter version.
At our company we just got a new Director who has 30 years experience in the mobile market, and more precisely in mobile JavaScript widgets.
And he’s like all: jQuery and other libs are bad because of performance problems, and like we have to do everything by hand with precise optimizations per/handset.
While i do agree that the size of jQuery is starting to get quite big, i have always seen you guys go crazy over trying to always homogenize the api across browser and put in lots of time around optimizations (been using it since 1.2 and never looked back).
I just cant imagine the coding horror of trying to support 20 different navigators on mobile, not to mention all the specific bugs per/version. This is also one point where jQuery shines ..it just works, and lets us concentrate on the essential stuff: Build Products !
Keep up the good work, and i hope to see more speed/size optimizations in the future !
First of all I have to say that I love jQuery – it makes my live easier!
Modularization is something you (we) should really consider. For example: I have some projects that could be done only with the selector engine (Sizzle) and the event handling core. I don’t need effects or DOM manipulations.
I realize that this is not easy to achieve but it worth the effort.
On the other hand I also think that jQuery Mobile should not depends on jQuery core and it has to have its own life.
Cheers!
Don’t remove older browser support.
Someone said that a site made for IE6 wouldn’t require the latest jQuery.
If your new site needed IE6 support because of an outdated government/education department, why should you deny these users the faster download & performance benefits of the latest jQuery version?
Harsh criticism. Don’t start screaming at me in a flame war that invokes personal attacks. These are serious issues with your library and why I slowly started to hate the thing.
1. Remove a bunch of the useless garbage that leads to laggy/slow pages. You support event delegation, stop supporting individual event binding. Stop insisting the a tree structure of objects is a string. Don’t encourage people edit massive objects of CSS where they should just write the css class. Stop querying with sizzle inside of for-loops because people don’t cache the element. This is how your library is used by the majority, and it’s making the web a hole of slow filth for everyone, and somehow “computers are getting faster” is thought of as an acceptable answer to the problem.
2. Somewhere along the line “Write less” became “Stop understanding what your code really does”. This needs to stop. jQuery shouldn’t try to replace DOM methods. Look, .attr was made only to come back later and use .prop– when a lot of people put a lot of effort into creating these methods in the first place but for some reason element.checked=true was more confusing than $(element).attr(“checked”, “checked”), which broke semantics, and still is an issue for many people who used the library.
3. The API is absurd, and the docs are full of noise, you’re already PHP’s kid brother. This should be priority.
Foo bar +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 ;-)