JQuery 1.8 Released | Hacker News Reader

JQuery 1.8 Released

blog.jquery.com

220 pointswarp40 comments

Open articleView on HN

Hey dmethvin,

You guys are doing awesome work. Thank you.

jQuery’s selector engine is faster than ever, thanks to a rewrite (well, really two rewrites) by Timmy Willison.

Would love to see some benchmarks!

http://jsperf.com/sizzle-1-7-2-vs-1-8

According to a few runs of this benchmark, a number of these tests are slower in 1.8, particularly selecting by class. That's rather off-putting. I hope it's just me.

Using Chrome 21.0.1180.57 on OSX.

I ran it a few times as well and most of the benchmarks seemed to be within statistically insignificant margins, except for three which were much faster -- including $('#id'), which has got to be the most common selector (at least it is in my code).

I think it's still worth the upgrade.

I use class selection most often, so any slowdown there is a cause of concern for me. The other slowdowns are not as big of a deal, providing it means speedups in more important places.

On my system these are the results for the class selector test:

   1.7.2  4,123 ops/s   242 microseconds/op  
   1.8.0  4,061 ops/s   246 microseconds/op

Are you seeing some large difference? You'd need to be selecting things by class several hundreds of times a second before it could possibly make a difference.

In practical terms, the speedup in custom selectors is probably the most important, since they are so slow.

It's a small difference, but these small differences version after version add up to a lot of nickels.

As I mentioned in another comment, increasing performance for ID selection (which is already much, much faster than other types) at the expense of other types makes for sexy benchmarks, but is less than stellar in the real world.

This is nonsense.

Making a huge increase in one type of selector for the sake of an insignificant decrease in another selector is an obvious win.

Let's do a simple thought experiment. You have two selectors A and B. A takes 100x more time to evaluate than B (which is about how id and class selectors compare). You evaluate them equally often, say N times each. If the time B takes to evaluate is t, your total execution time is 101t.

Now someone comes along and makes B 10x faster while making A 2% slower (which is what the numbers above seem to show for the class selector). Now your execution time is 102.1t, which happens to be larger than 101t.

The upshot of all this is that if use frequencies are equal, performance improvements for slow things (even small ones) are worth a lot more than performance improvements for things that are already fast. Now obviously you have to weight by frequency of use, which may differ for different API consumers.

There's only one case in which speeding up already-fast stuff at the cost of slow stuff getting even slower is an obvious win regardless of use frequency: benchmarks averaged using geometric means. Which is the most popular averaging method, of course: see Dromaeo, V8 benchmark, PeaceKeeper, etc.

Just out of curiousity, have you considered using querySelector or querySelectorAll directly for your really hot cases? There's a good chance that it'll be faster than the jQuery version in the non-ID cases.

Yeah, that's one of the first steps if a selection benchmarks slowly. I just dislike adding complexity in any form. It adds up so quickly in complex software.

Running latest version of Chrome on Windows 7 here and seeing the same things. Nothing is overly much faster and in some instances, like you noticed selecting a class is slower in 1.8 compared to 1.7.2. A little worrying, but I'm sure there's an explanation.

I'm running Chrome on Win7 and I'm seeing approx 80-90% faster for the id test, but no real difference in any other test.

I'm seeing the same but because ID selection is already 2 orders of magnitude faster than any other type, the net win here is significantly reduced. The rich are just getting richer.

"the net win here is significantly reduced"

Do you mind illustrating how the net performance of jQuery has been reduced with the release of 1.8?

jQuery is now modular, but jQuery.com doesn't have the custom download option like they do for jQuery UI's themeroller. When that comes out, it's going to be big news yet again.

They've made the build tools modular using grunt.

Considering that they have custom download options for jQuery UI and recently added a tool for jQuery Mobile (http://jquerymobile.com/download-builder/), I expect it won't be many more months before they add one to jquery.com.

jquip (aka jQuery in parts): https://github.com/mythz/jquip

Does include an online builder at: http://jquip.ubixar.com/ It's also the only version of jQuery to support Google Closure's advanced compilation mode.

Anyway, I'm happy to see jQuery moving into a smaller more modular code-base.

It's much easier to make jQuery UI modular than it is to make jQuery core modular. You know that you're using autocomplete, tabs, sliders, or dialogs; you can see them on the screen. If you're including jQuery core with several jQuery plugins it won't always be clear which parts of jQuery core you are using, either directly or through those plugins. If you already know your project's dependencies, the grunt build option in 1.8 gives you that flexibility now so there's no need to wait. If you don't know those dependencies, a page of check boxes will just make creating and debugging a working build more frustrating. Closure Compiler Advanced Optimizations promise to automate that process, but we still have a way to go on getting that integrated into jQuery.

>Automatic CSS prefixing

Does this mean I can apply rounded corners via jquery css without having to write 4 separate css properties for each browser?

Yes.

This will come in handy and is very 'jQueryish' - handling browser BS out-of-view so you can get on with your day.

I wouldn't recommend using jQuery to style your site. That sounds incredibly silly. Apply a class that is already properly prefixed. You can use a tool like www.compass-style.org to write one line that writes it for all. Please don't use jQuery for styling.

http://leaverou.github.com/prefixfree/

Thought I'd share this because this was giving me the shits.

We don’t expect to get any bug reports on this release, since there have been several betas and a release candidate that everyone has had plenty of opportunities to thoroughly test. Ha ha, that joke never gets old. We know that far too many of you wait for a final release before even trying it with your code. So now there is really no reason to wait, and you can find out if there are any bugs you could have reported earlier.

Is it just me, or is that overly passive-aggressive for a release announcement?

I didn't read it that way, I thought it was hilarious…

I hoped it was funny. I also hoped it would take some of the fury off the bug reports from people who hadn't tried any of the betas or RCs and now are finding problems. Like this one that just arrived: http://bugs.jquery.com/ticket/12232

Honestly, I don't know how you deal with some people's complaints.

It's just you.

dmethvin is a surprisingly nice person for being development lead on jQuery dealing with the crazy volume of complaints/ bogus bug reports. He's actually just being lighthearted and jocular here. I can see it from the other perspective, but that's not Dave's style.

  Size reduction wasn’t our primary goal in this version,  
  but we felt it was important to hold the line on code  
  growth, and we definitely achieved that.

Does anyone have pointers to examples of specific changes between 1.7.2 and 1.8 in this area?

A very large number of them were code refactors to take better advantage of gzip; Richard Gibson (gibson042) has become a master of that [1]. It turns out that a good style guide can actually help improve gzip compression as well [2]. Others were things like an optimization for $("body") which we pulled out [3]. Its main job seems to have been to look good on a circa-2008 benchmark that didn't cache its selectors. The Sizzle optimizations that Timmy Willison (timmywil) did pretty much made the jQuery-side optimizations unnecessary anyway.

[1] https://github.com/jquery/jquery/pull/788 [2] https://github.com/jquery/jquery/pull/840 [3] https://github.com/jquery/jquery/commit/9ebc27db54194c88fa7a...

Finally we can use border-box box-sizing everywhere! http://paulirish.com/2012/box-sizing-border-box-ftw/ The bug has been fixed: http://bugs.jquery.com/ticket/11004

Good eyes! I completely missed that in the changelog. border-box: box-sizing really makes life easier when working with complex layouts. I'm always amused by the fact that old IE's much-berated interpretation of the box model is actually favourable!

indeed. I can't stand when setting width:100% can actually extend past the bounds of the parent.

When you strip away years of familiarity and conditioning to accept the standard box model, it's hard not to conclude that it's completely unintuitive and back-asswards!

I'm less and less excited when I see new releases of jquery. I guess it's so widely used that you can't add cool stuff without messing with already existing code or pissing some people off.

TL & DR for the patch: - some internal rewrite - some small fixes - smaller code size

I think that's usually the sign of a mature platform. Less super exciting features and better stability and reduction in code-size. It's better than the alternative or greater and greater bloat.

Thats what I keep saying about Prototype.js

Reply on news.ycombinator.com