JQuery now runs on every second website | Hacker News Reader

JQuery now runs on every second website

w3techs.com

65 pointsMarionG37 comments

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

Wow, impressive. Let's hope the jQuery sources and CDNs never get compromised!

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.

Of one of those major CDNs get hacked (rather than fail on accident), the problem will be far worse than some outdated Wordpress blogs.

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.

especially when it's trivial to implement

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"></script>
    <script type="text/javascript">
    if (typeof jQuery == 'undefined') { document.write(unescape("%3Cscript src='/path_to_scripts/js/libs/jquery-1.8.0.min.js' type='text/javascript'%3E%3C/script%3E"));}
    </script>

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

You don't need to use unescape in the fallback

    if(!jQuery)document.write('<script src="jquery.js"></scrip'+'t>');

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.

As of right now there are no practical preimage attacks on MD5, but people keep expecting one.

It's better to switch to something else and not have to worry about it.

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.

Not unless you are 1. visiting a lot of sites for the 1st time that use these libraries and/or 2. frequently clear your browser cache.

Your browser caches the libraries on first load anyway.

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

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.

You say "next couple of years".

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

Makes me wonder if it would make sense to have it built-in in browsers?

It is built in to many browsers.

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

Just to be clear, jQuery's selector syntax supports many, many things that querySelector(All) does not.

http://api.jquery.com/category/selectors/jquery-selector-ext...

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.

No thanks. The jQuery single object design pattern is one that I do not like

> 73.4% of them don't use any CDN

sad

Not really - if a one of the CDN's mentioned develops a security issue my sites are among the 26.6% that are unaffected.

You mean 73.4%?

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.

Can it be done faster and better ? Yes.

Can it be done cheaper ? Probably no.

wow - that must have taken a LOT of organising! And how do they know which website I'm going to visit next!?!

Its great to see kids my age doing amazing stuff! Thanks to JQuery, I'm able to do a lot of amazing things. It helped make JavaScript more accessible.

Well, I built a site in early 2009, worked fine with 1.3, 1.4 broke a nice feature, and 1.8 makes the site unusable. I guess it's 1.7 until eternity.

Whats wrong with sites with no jquery!

jQuery Mobile is really nice as well, give it another 7 years and it will be on a lot of mobile sites

Reply on news.ycombinator.com