JQuery 1.11 and 2.1 Released

http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/

by cleverjake • 13 years ago

128 36 13 years ago

blog.jquery.com

quarterto• 13 years ago

So happy to see official jQuery releases on npm. No more need for unmaintained third-party jquery-{browser,browserify,client,etc} packages.

ancarda• 13 years ago

Can I ask why you would want jQuery on npm? A lot of jQuery's use is DOM manipulation, something that as far as I'm aware doesn't exist on Node.js

ramigb2• 13 years ago

jQuery has much more than DOM manipulation, but since you mentioned that, some packages like Cheerio uses jQuery -to some extent- to parse DOM on scrapped HTML pages, and of course you can use jQuery to create DOM elements and append them to responds although not efficient but i am just giving examples from the top of my head here :)

camus2• 13 years ago

Because jQuery is a Javascript library,,and dev might want to test/build their own jQuery.

lobster_johnson2• 13 years ago

It's mainly so that you can use Browserify [1]. Browserify and Bower both integrate the Node.js module system into client-side JS.

You basically get a unification of backend and frontend languages -- both using JS, the same dependency and versioning system, the same way to require modules, and of course the same code. Being able to use the same libraries on the backend and frontend is huge. (But not required. Browserify/npm are still useful if you don't use Node.js.)

And it's cleaner. Relying on the Node.js dependency system means you can just import modules the same was in Node.js, instead of maintaining an ugly "vendor/" folder where you manually copy things like jQuery.

I suspect (I haven't gotten this far yet) that you can more easily unit-test your code this way. You just need a "headless" browser environment (using jsdom etc.) that's compatible jQuery.

Browserify is actually very small tool. It leaves all package management to npm, and all Browserify does is to generate a JS file that includes all your package.json-specified modules in neatly namedspaced dependency-initialization order, ready to be imported using a script tag.

There is also Bower [2] from Twitter. Unlike Browserify, Bower is mainly a wrapper around npm that acts as a separate package manager, but doesn't actually implement the glue needed to import any JS on the client side.

[1] http://browserify.org

[2] http://bower.io

brokenparser• 13 years ago

Great, now I just need a third-party package manager that only runs on their own javascript environment. Whenever I write a web application in something other than javascript (happens), that's quite a build dependency right there. I'd rather not have Ruby gems and npm packages in a Python project, for example.

valtron• 13 years ago

Rejoice! No more

    event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

rschmitty• 13 years ago

Appears this fixes the annoying warning in chrome, yay!

    event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

coreymgilmore• 13 years ago

its about time!

oneeyedpigeon2• 13 years ago

Shame; kinda gotten used to it ;)

paws• 13 years ago

That warning was bothering me enough that I ended up forking jquery-rails simply to drop in 1.11.beta3. Until jquery-rails gets updated (doesn't appear to be at the time of writing) this is an easy one liner:

gem 'jquery-rails', github: 'onpaws/jquery-rails'

morganherlocker• 13 years ago

Bummer, bootstrap still causes the same issue, which can be seen on twitter.com.

csmithuk3• 13 years ago

And we're still stuck on 1.4.2! Surprisingly difficult getting rid of older versions if your plugins all depend on an old version...

we've got to rewrite 4 plugins due to API breaks to get anywhere near this version.

Will never import any community plugins again. jQuery and jQuery UI only.

acdha2• 13 years ago

“community” doesn't mean a large volunteer workforce. If you're using those plugins, why not work with the upstream to fix compatibility?

csmithuk3• 13 years ago

Most of them are abandoned and have restrictive licenses so you're SOL then.

leterter• 13 years ago

Jquery hide and show was incredibly slow as well, did they fixed that?

Jakob2• 13 years ago

Not sure why you got downvoted. It still is slower than expected. I published a jsperf here with jquery 1.11.

http://jsperf.com/jquery-show-hide-vs-css-display-none-block...

Show()/hide() is still very expensive because it checks the visibility before setting it.

What surprised me though is that $elem.css('display', 'none') is equally slow. That smells like an upcoming pull request.

$elem[0].style.display='none' is still the way to go.

jacobr• 13 years ago

$elem[0].hidden=true should work in modern browsers as well.

dmethvin• 13 years ago

If you've got some ideas a ticket at bugs.jquery.com would be a great place to start, with whatever analysis you have.

Remember, however, that many of your "comparable" test cases are making assumptions that jQuery can't make. For example, .show() sets the display property back to what it was before a previous .hide(), to do that it has to query the display property when hiding. If you try some ideas for fixes, the unit tests should indicate whether you've run afoul of such problems.

Is the performance of .show()/.hide() causing issues? Under what conditions?

jcampbell1• 13 years ago

I was upgrading jQuery, and had a lot of different versions on the site. One of them was this gem: https://gist.github.com/jcampbell1/8601940/raw/f409862786b8f... I think it is jQuery version 0.3.

It was actually being used on a few minor pages, and still worked on modern browsers.

tambourine_man• 13 years ago

Did I read this right, they added back support for IE6, 7 and 8 on the 1.x branch?

ljoshua• 13 years ago

No, the post is a little oddly worded, but 6/7/8 support wasn't ever removed from the 1.x branch. Just important to note that the 2.x branch removes support for them.

bicknergseng• 13 years ago

Anyone know if the jQ team ever plans on moving their deferreds to the promises/A+ spec?

leeoniya• 12 years ago

from earlier discussions the conflict is with maintaining the current chainability/api

JQuery 1.11 and 2.1 Released

Related Stories