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:
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.
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.
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 :)
To my knowledge, Cheerio (which is great) does not depend on jQuery. I believe it just implements a limited selector, traversal, and manipulation API that's very similar to a subset of jQuery's API over the browser DOM.
Not sure I understand what that has to do with jQuery being on npm. The only way that Cheerio uses jQuery is by choosing its popular API to implement an interface to scraped pages in.
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.
> 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?
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.
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.
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?
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.
