181–190 of 360 posts
Earlier quoted context omitted.
If you are developing a library, then your users _Might_ need to support old browsers and _Might_ need jQuery.
lots of js libs are for things like webgl that already dictate a recent browser.
Earlier quoted context omitted.
> jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of user…
Nope. jQuery 2 just removed code for IE 6/7/8. Nothing was added. Code sized reduced, but almost the same performance. My benchmark shows only 10-15% improvement. That's nothing compared to using the DOM API straight up.
Earlier quoted context omitted.
More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
A classList polyfill is like 500b compressed. No need to blow a non-existent problem out of proportion. https://github.com/remy/polyfills/blob/master/classList.js
Earlier quoted context omitted.
It sounds like you're looking for the querySelector and querySelectorAll methods: https://developer.mozilla.org/en-US/docs/Web/API/Document.qu...
querySelector and querySelectorAll could have been pretty great, but they suffer from some serious problems as they ended up spec'd. The one I hate most is that qSA returns Yet Another JavaScript Collection That Is A Lot Like An Array But Isn't An Array And Therefore Doesn't Have Any Of The Nice Methods(TM). Yes, you're going to have to iterate over the thing using an index in a loop. There's others: http://ejohn.org…
Array.prototype.slice.call(document.querySelectorAll('.myClass'), 0);
function qsa(sel) {
return Array.prototype.slice.call(document.querySelectorAll(sel), 0);
}
qsa('.myClass'); // Returns array of elementsAngularJS is all you need.
Does Angular use the jQuery library?
Yes, Angular can use jQuery if it's present in your app when the application is being bootstrapped. If jQuery is not present in your script path, Angular falls back to its own implementation of the subset of jQuery that we call jQLite.
Due to a change to use on()/off() rather than bind()/unbind(), Angular 1.2 only operates with jQuery 1.7.1 or above.
I've also started using Angular.js quite a bit and have found most of the time, it requires less code than jQuery. It also has its own subset of jQuery "jqLite" which has a much smaller footprint so your app doesn't need to rely on that jQuery dependency.
I feel empathy for the OP, for two main reasons: 1) The fact that some people don't realize that JavaScript != jQuery scares me. 2) jQuery born when cross-browser compatibility was a mess and today it still carries that weight. I think nowadays it needs to be more modular and less monolithic.
DOM != Javascript
That's the thing you dont understand and makes you say silly things.
I would like to add a thought about the dispute about the need of using jQuery. Let's say we know a consultant, let's call him Bob, who works on client projects. He needs to implement new features fast, and does not want to worry about low level stuff. Once he's done with a project, he moves on to another. Then, we meet a JS-framework developer, let's call her Alice. She has to weight every line of code she writes be…
My project currently depends on libraries which in turn have dependencies on mutually exclusive versions of jQuery, so we conditionally load a whole second copy some of the time. I've been meaning to fix the libraries that require older jQuery so we can fix this, but the bugs run deep, the libraries are pretty unmaintainable, and I'm under pressure to keep shipping features.