What the jQuery team either perceives or peddles as "modules" are simply split files; there's no encapsulation. All that's new is a shiny node.js builder.
I am interested, though, that the team has finally noticed that optional code should be the norm. Resig himself has been quoted as wanting nothing to do with it[0].
However, omitting every single "module" only truncates 2484 lines, which leaves the 1.8.1b source at a staggering 6763 lines of code. There is still a great deal of work to be done before "modular" is a fair term to apply to the API.
There has been recent work to make jquery compatible with Google closure's advanced compilation[1]. As mentioned in John Resig's reddit comment you referenced, this would allow the compiler to automatically remove unused components in jquery and perform whole program optimizations. Unfortunately, this approach requires large rewrites to jquery to conform to the strict conventions required by the closure compiler.
If we remove the blank lines and comments, would the line count be less staggering? By that measure we definitely shouldn't include Closure Compiler annotation comments since they add lines. For better or worse, we've focused on min-gzip size as a measure.
JavaScript doesn't have a formal notion of a module. What we're referring to here is the ability to exclude some chunk of functionality from jQuery and know that, internally, jQuery does not require it. We cannot know whether other code on the page requires it.
> optional code should be the norm
Is there an easy way to know what is "optional" code when including third-party plugins, short of analyzing all the code in advance? That's what Closure Compiler AO does, but it is not for the weak.
> There is still a great deal of work to be done before "modular" is a fair term to apply to the API.
If you've got some ideas we're open to suggestions.
So there are CSS properties with vendor specific implementation, how are they going to handle that? Also what if the browser (like Chrome) changes its spec.? This could break your current code.
Events such as ajaxStart fired by $.ajax
can currently be attached to any element–even
to elements that are not in a document at all!
This creates an inefficient special case,
so we will eventually remove that ability
and fire ajax events only on document.
I need to look into this. If you are using jQuery outside of a standard browser environment this might be problematic.
I must admit that I'm surprised $.browser is going to disappear in 1.9, not because removing it is a bad thing, but because of the number of scripts that is going to break. Current jQuery UI, Bootstrap etc all use $.browser. There is presumably plenty of time before 1.9 for library authors to address this, but I can certainly see a lot of breakage coming.
Replying to myself - but thinking about it further, there is something a little ironic about the result of removing $.browser in that testing for certain behaviour can in fact increase code size in libraries. For example testing the rendering behaviour of how scrollbar width is added to containers (simplifying the problem somewhat) is something we know happens in IE6/7, which is a nice easy line of jQuery at the moment, but actually testing for it will introduce more code into libraries which can no longer use these properties.
I still don't think it is a bad thing to remove $.browser since it does encourage good code practice, but there is a lovely irony that to decrease code size in jQuery core, plug-ins will likely need to have increase their size.
Few of them are major, but the worlds most popular CMS, Joomla, runs 2-3% of all websites, and they will be switching to jQuery (from mootools) later this year.
A lot of good changes in here. The modularity will improve usability -- particularly for sites who want the core jQuery features without all the extras. My hope is this will make it easier to use jQuery on mobile -- and more comparable to Zepto in terms of size.
I remember reading somewhere that 1.8 would drop support for quirks mode in IE. Anybody know if this ended up happening? I didn't see any mention in this post.
jQuery never really "supported" quirks mode, the unit tests were not ever run in quirks for example. A few of the offset and dimensional tests tried to account for quirks, but we gave up on that totally in 1.8 in favor of fully supporting the CSS box-model property.
Many Quirks pages could still use jQuery 1.8 successfully if they avoid asking for dimensional measurements, but I'm not sure why developers would still use quirks since it throws IE into prehistoric mode and has serious performance impacts.
I don't think any knowledgeable front-end engineer would build a page in quirks mode, but a surprising number of existing sites have large swaths of pages without a doctype.
I'm just curious what the higher-level APIs are that people need from jQuery that aren't available on mobile. I recall jQuery being popular for selector queries (available on all mobile browsers natively with querySelector and querySelectorAll) and for even listeners (offers no real advantage over addEventListener as far as I can tell).
Well one nice affordance jQuery offers, is you can do manipulations en-mass without having to write out a loop, or use Array.forEach(). This helps simplify event binding and manipulation code. Also there are selectors in jQuery that are not available in querySelectorAll. And lastly querySelectorAll has some pretty buggy implementations. jQuery smoothes these out.
Sure but $('.clicky').on('click', doSomething); means no loops at all, and will bind events to all matching elements. I don't think there is a native API way to do this.
I'm not sure that works. getElementsByClassName (and Id and querySelector) returns a NodeList, not an Array, so there's no foreach, you have to convert it to an array first.
I'm so happy that the global ajax events are going, they were a big weirdness for me, especially in light of the custom events that were added in recent releases.
I am interested, though, that the team has finally noticed that optional code should be the norm. Resig himself has been quoted as wanting nothing to do with it[0].
However, omitting every single "module" only truncates 2484 lines, which leaves the 1.8.1b source at a staggering 6763 lines of code. There is still a great deal of work to be done before "modular" is a fair term to apply to the API.
[0]: http://i.imgur.com/Ta223.png