
JQuery 1.11 and 2.1 Released - cleverjake
http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
======
rschmitty
Appears this fixes the annoying warning in chrome, yay!

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

~~~
paws
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'

------
valtron
Rejoice! No more

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

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

~~~
ancarda
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

~~~
lobster_johnson
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](http://browserify.org)

[2] [http://bower.io](http://bower.io)

~~~
andreypopp
Not sure if bower has something to do with npm cause it's a separate package
manager.

~~~
lobster_johnson
You're absolutely right. I thought it was based on nom, but it's not.

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

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

------
jcampbell1
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...](https://gist.github.com/jcampbell1/8601940/raw/f409862786b8f577aed91236ee37005321f64c51/old+jquery)
I think it is jQuery version 0.3.

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

------
csmithuk
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.

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

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

~~~
jrochkind1
This is a hazard of open source or shared community code in general, I think
most of us have run into -- and more will be as history moves forward, more
years and more projects means more abandoned projects, and more dependency
changes meaning abandoned projects become liabilities.

To some extent there's not much you can do, the risk is just part of the game;
you're making a tradeoff, risking future lock-in to abandonware, by gaining
produtivity by using someone elses shared code.

But the one thing you CAN do is avoid using projects with restrictive
licenses. It takes something pretty exceptional ly valuable (AND with all the
signs of being a project with legs) to get me to use something with a
restrictive license. If it's got a sufficiently flexible license AND is
popular, it's pretty likely someone (if not me) is going to step in to do the
bare minimum of changes neccessary for security or dependency upgrades.

The other thing one can do is try not to use projects with really poorly
written/organized code -- cause it's an additional barrier to someone else
patching it once it's abandonware. But that's harder to judge correctly, and
anyway if the thing is really useful and difficult for me to reinvent myself,
I'm likely to ignore perceived bad code quality and use it anyway.

~~~
jmulho
> But the one thing you CAN do is avoid using projects with restrictive
> licenses.

Could you provide some rules of thumb for how to quickly "avoid using projects
with restrictive licenses" (short of getting a law degree). I assume there are
a handful of popular licenses that you just know are what you are looking for
(e.g. BSD, Apache, GPL2, or something) and you look for that. Otherwise you
scan for specific restrictive or unrestrictive verbage. For the uninitiated,
could you explain what you are looking for?

~~~
acdha
That'd be it exactly: if it's not e.g. {BSD,Apache,GPLv3,CC0} think carefully
before using it. If they haven't picked a license, email first and ask – if
they can't pick a license, it's not a serious project.

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

~~~
ljoshua
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.

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

~~~
Jakob
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...](http://jsperf.com/jquery-show-hide-vs-css-display-none-block/21)

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.

~~~
dmethvin
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?

~~~
Jakob
I agree with hide() and show(). Their performance is not that important since
they are a swiss army knife and hopefully not used on too many elements at a
time. The bad performance of .css() in the jsperf above is strange, though.

Profiling shows that it is not one big function but many small which
accumulate. The camelCase function alone takes 3% of the speed in Chrome, the
internal access() structure takes nearly half the time itself.

Speed could be achieved with the byte cost of specialised functions for easy
cases like css(key, value) where you can skip most of the checks and queuing.

This shortcut for show/hide is roughly 16x faster and should remain more or
less so even after extending it to cache the previous style and adding common
exceptions for <tr>, !important, etc. Shortcuts like those could be used if it
is clear that the chosen function signature is very easy like
$('p').css('display', 'none') so all other checks can be skipped but would add
to the payload of jQuery.

    
    
        $.fn.cssDisplay=function(show) {
          var d=show?'block':typeof show==='undefined'?'':'none',
            length=this.length, i=0;
          for(;i<length;) {
            this[i++].style.display=d;
          }
          return this;
        }
    

I’ll have a look into a more generic and faster .css() solution.

