JQuery 1.8b1: what’s new?(blog.jquery.com)
blog.jquery.com
JQuery 1.8b1: what’s new?
http://blog.jquery.com/2012/06/22/jquery-1-8-beta-1-see-whats-coming-and-going/
7 comments
http://trends.builtwith.com/javascript/jQuery is where we get that statistic from
Wish I could access the full list, but I think that's convincing enough. Thanks for the link.
According to Wappalyzer 60% of sites that use a JavaScript framework use jQuery:
http://wappalyzer.com/categories/javascript-frameworks
It's a different statistic but does make the 50% seem reasonable.
http://wappalyzer.com/categories/javascript-frameworks
It's a different statistic but does make the 50% seem reasonable.
"powering" is a bit of a weasel word in this case. Plenty of those sites should work just fine without jQuery or any javascript..
So to say jQuery "powers" half the major websites on the Internet is like saying "Cup holders power 99% of all passenger vehicles world-wide".
So to say jQuery "powers" half the major websites on the Internet is like saying "Cup holders power 99% of all passenger vehicles world-wide".
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.
What data do you have that supports that Joomla is the world's most popular CMS?
It sounds nicely ambiguous. What's a 'major' website?
[deleted]
I would just guess that most major websites are using it.
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.
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.
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.
[deleted]
I can't imagine why you'd need jQuery on mobile in the first place? What exactly are these core features that the standard DOM apis don't give you?
I suppose you write all your code in assembly too? There's no room for going higher-level than the APIs exposed by the browser?
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.
Binding event handlers in a loop is an anti-pattern greatly promoted by jQuery during several years. You should use event delegation.
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.
Edit: typos
Edit: typos
As far as I know jQuery is written with "native API", so there is obviously a way to do this in JavaScript.
document.body.addEventListener("click", function(e) {
if (e.target.className == "clicky") {
doSomething();
}
}, false);document.getElementsByClassName('clicky').forEach(function(el) { el.addEventListener('click', doSomething); });
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.
Array.prototype.slice.call(document.getElementsBy....
That's also a ton of tying and a lot of code that a minifier can't reduce. I guess its possible, but do you really want to writing such verbose code?
The DOM API is clear enough that silly abstractions like "selector engines" are unnecessary.
The C vs. Assembly argument is such a silly non-point; apples and artichokes.
The C vs. Assembly argument is such a silly non-point; apples and artichokes.
Selector engines are clearly not silly abstractions otherwise all major browsers would not have implemented querySelectorAll.
But since they did, why use jQuery on mobile when 100% of mobile browsers support querySelectorAll?
…which is a façade for the existing CSS engine. Developers clamoured for it (right or wrong), and it was implemented.
Hilarious that you think that one of the core features of the most successful JS library in history is a "silly abstraction".
And JQuery is much more than just a selector engine.
And JQuery is much more than just a selector engine.
"I can't imagine why you'd need jQuery on mobile in the first place?"
How about having the jQuery functionality on mobile device?, Recommended reading http://en.wikipedia.org/wiki/JQuery
How about having the jQuery functionality on mobile device?, Recommended reading http://en.wikipedia.org/wiki/JQuery
A massive script such as jQuery does not belong on a mobile device, minified or not. Surely mobile developers would know that minimal script is best.
I browse to tons of pages on my phone every day that presumably use JQuery and work fine. We're not in the WAP days anymore.
I guess my humble iPod Touch that sputters out on bloated sites like GitHub just isn't up to snuff.
Try loading a page without script bloat and you'll see a noticeable difference.
Try loading a page without script bloat and you'll see a noticeable difference.
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.
[0]: http://i.imgur.com/Ta223.png
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
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.
[1] https://groups.google.com/forum/#!topic/jquery-bugs-team/2zb...
[1] https://groups.google.com/forum/#!topic/jquery-bugs-team/2zb...
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.
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.
Global ajax events: ( are being removed )
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.
> Ajax events should be attached only on document as of 1.9.
Looks like they are not being removed but that you should attach to document only.
Looks like they are not being removed but that you should attach to document only.
VENDOR-PREFIXED CSS PROPERTIES
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.
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.
Vendor specific cssHooks are always executed when defined, allowing you to deal with specifics of implementation in your own code.
How exactly do you handle the "change in spec" case in your code right now?
How exactly do you handle the "change in spec" case in your code right now?
Then use -vendor-prefixed-property-name not property-name.
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 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.
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.
Anybody have any data on this?