Yes, it does raise the "herd of cloned sheep" question.
But I wouldn't worry too much. It's open source, and using the hosted version means that only that one copy has to be fixed. It is unlikely to ever be a problem on the scope of, e.g., out-of-date Wordpress installs.
It's interesting and slightly scary the CDN issue. Several months ago when there was an issue with Google's CDN, an awful lot of websites fell over as they never had a local backup in place.
Hopefully as jQuery usage grows people come to understand the need for fallbacks.
Is it really that big of a perf hit to just download the minified and use it in your source like all other libs? jq isn't that big of beast, plus if you have a large site its cached for every other page visit :)
> if you have a large site its cached for every other page visit
until you modify your own js (not that rare and uncommon) and it's back new and shiny again. from the cdn, it's just already there sitting in the browser's cache.
> Is it really that big of a perf hit
maybe not, but if you had the option to wake up with your teeth already brushed, wouldn't you take it? :D
yeah that wouldn't be fun, but maybe we could make a browser add-on to check for the md5 checksum, not a security expert here but sounds like a solution to me
MD5 is not acceptable for this purpose since it's possible to create source with the same MD5 as the original. It would need a different hash at a minimum.
I'm not sure what you mean by this. mrpollo recommended using MD5 as a checksum before executing jQuery to ensure that the CDN hasn't been compromised. For instance jQuery 1.8.0's checksum is cd8b0bffc85bb5614385ee4ce3596d07. I was under the impression that MD5 isn't malleable enough to create a non-trivial malicious script with the same hash.
Your impression is incorrect. Quoting one researcher, "Our intent is to raise awareness that MD5 is broken so drastically that its continued use in digital signature schemes and certificates poses realistic threats." See also http://en.wikipedia.org/wiki/MD5 .
I am no expert. It may be that MD5 is still relatively secure for this specific task. However, SHA2 is more secure. Use that instead.
I was thinking a cool Chrome extension might be to preload all the major javascript libraries (jquery, etc.) and change any external extension references to the preloaded ones. I'm not sure how much of a speedup this would offer but certainly it would be something.
They don't even have to get compromised to mess up the web. Too many sites point their jQuery src to the latest version, so just wait for jQuery 2.0 to come out and see how many IE 6/7/8 users complain. http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-an...
It's not many things, if you look carefully you will realize most of what is listed can be rewritten with a CSS selector. For example ":button" is the same has "button, input[type='button']". They are mostly just shorthand and that's not extra feature.
If Sizzle is present in over half of all websites, it's already a standard and one would expect either Mozilla or Google to add native support for it; it seems like low-hanging fruit.
thats just silly talk. of course they would want that stuff natively. that is why they created the querySelectorAll method. If Moz/Goog gets it native in browser, that is less bytes that need to be transfered over the wire, and therefore faster websites.
That would prevent you from using the latest version in older browsers.
Perhaps if it was implemented as a resource="jquery-1.8.0" attribute on the script tag, allowing browsers with a copy to load that instead of hitting the server.
Ingredients for success: Solve a common set of problems (browser incompatibilities, ugly API) with a simple, concise interface that maps well to the domain ($(CSS_selector).action(params)) and release under a liberal open source license (MIT). Another library that follows this pattern would be Requests (python).
This is a trend that may actually reverse in the next couple of years. JQuery's popularity has inspired a lot of new DOM API methods now present in modern browsers which are starting to make it somewhat redundant. Once IE8 is out of your support picture the major DOM API normalization issues (events in particular) are out of the way.
The only reason I can think of to use JQuery beyond that is that it's a dependency for a lot of libraries you use, you're supporting something other than Android/iOS on mobile or you really, really like the extras like animate, their powerful event system, extend and/or their ajax methods.
That said, it's popularized a lot of useful coding methods, showed everybody how normalization should be done, and demonstrated the power of closures/factory functions to keep objects very light-weight in spite of having a ton of functionality associated with them. It's not just for client-side-illiterate noobs. Studying JQ under the hood can teach a lot about JQ.
The newer JS libraries/frameworks/tools are concerning themselves more with how to implement highly complex UI in an app-maintainable way.
IE6 was released in 2001 and while it's finally on it's way out, you will run into people who want it supported.
So by next couple of years, do you mean 10 years after IE8 was released which would be 2018 we'll begin to see support for it dropping?
jQuery serves the exact purpose of allowing you to push your design forward without burning as much time supporting inconsistency. I believe jQuery defers to built in browser implementations when they are better or compatible so you still don't loose anything by using jQuery
As much as I love jQuery, I feel it can quickly become a crutch, particularly for those who have spent a fair bit of time relying on features like .animate(). Modern browsers often have alternatives that (depending on the situation) simplify your code and offer significantly better performance. Similarly, I cringe whenever I see jQuery UI pop up in an interface - while it's easy to use, it also keeps some from developing UI features of their own.
There's a time and place for everything, and as a whole, I feel many are over-relying on jQuery.
You're right. But the fact that jQuery has a much simpler API than using just javascript makes it easier for programmers to use it. It's a library and that's what libraries are for, it takes care of notorious cross browser compatibility issues (how well is another question..)
jQuery UI similarly helps implement features such as autocomplete, etc. which while you could take the time to implement again offers a simpler API with cross browser tested code.
I don't think there's any argument against the fact that jQuery has definitely made a massive impact on the use of javascript on the web. There are plenty of programmers who wouldn't touch javascript with a 10 foot pole before jQuery due to the cross browser issues. I think that's actually been a good thing for UI for the most part.
40 comments
[ 0.27 ms ] story [ 70.6 ms ] threadBut I wouldn't worry too much. It's open source, and using the hosted version means that only that one copy has to be fixed. It is unlikely to ever be a problem on the scope of, e.g., out-of-date Wordpress installs.
Hopefully as jQuery usage grows people come to understand the need for fallbacks.
until you modify your own js (not that rare and uncommon) and it's back new and shiny again. from the cdn, it's just already there sitting in the browser's cache.
> Is it really that big of a perf hit
maybe not, but if you had the option to wake up with your teeth already brushed, wouldn't you take it? :D
It's better to switch to something else and not have to worry about it.
I am no expert. It may be that MD5 is still relatively secure for this specific task. However, SHA2 is more secure. Use that instead.
Your browser caches the libraries on first load anyway.
sad
<node>.querySelector(...) and <node>.querySelectorAll(...)
If all you're using jQuery for is grabbing nodes from the DOM and attaching event listeners AND you don't care about old versions of IE then...
http://caniuse.com/queryselector
In a nut: querySelector[All] requires IE8, addEventListener requires IE9.
http://api.jquery.com/category/selectors/jquery-selector-ext...
Perhaps if it was implemented as a resource="jquery-1.8.0" attribute on the script tag, allowing browsers with a copy to load that instead of hitting the server.
The only reason I can think of to use JQuery beyond that is that it's a dependency for a lot of libraries you use, you're supporting something other than Android/iOS on mobile or you really, really like the extras like animate, their powerful event system, extend and/or their ajax methods.
That said, it's popularized a lot of useful coding methods, showed everybody how normalization should be done, and demonstrated the power of closures/factory functions to keep objects very light-weight in spite of having a ton of functionality associated with them. It's not just for client-side-illiterate noobs. Studying JQ under the hood can teach a lot about JQ.
The newer JS libraries/frameworks/tools are concerning themselves more with how to implement highly complex UI in an app-maintainable way.
IE6 was released in 2001 and while it's finally on it's way out, you will run into people who want it supported.
So by next couple of years, do you mean 10 years after IE8 was released which would be 2018 we'll begin to see support for it dropping?
jQuery serves the exact purpose of allowing you to push your design forward without burning as much time supporting inconsistency. I believe jQuery defers to built in browser implementations when they are better or compatible so you still don't loose anything by using jQuery
There's a time and place for everything, and as a whole, I feel many are over-relying on jQuery.
jQuery UI similarly helps implement features such as autocomplete, etc. which while you could take the time to implement again offers a simpler API with cross browser tested code.
I don't think there's any argument against the fact that jQuery has definitely made a massive impact on the use of javascript on the web. There are plenty of programmers who wouldn't touch javascript with a 10 foot pole before jQuery due to the cross browser issues. I think that's actually been a good thing for UI for the most part.
Can it be done faster and better ? Yes.
Can it be done cheaper ? Probably no.