301–310 of 360 posts
People that are not fans of jQuery are people that are are only familiar w/ MVC on client side and are not using APIs (ex: Parse, Kinvey, etc.)
Earlier quoted context omitted.
are you serious ? thats actually a good example on why you should use jquery. First of all the dev needs to know exactly on which platforms he will run into problems and how to solve them...And what if you need not one but several polyfills ? That gets messy pretty quickly.
Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than j…
Why? If I just drop jQuery in and treat that as my API baseline, what do I lose? A little performance, a few hundred kilobytes' download (almost certainly cached from a CDN anyway). And it frees me up from remembering a bunch of corner cases and keeping track of a bunch of implementation details, letting me focus my attention on more important things.
I may not need jquery for compatibility, I need it because it makes code in a language I find unesthetic and unconsitent more readable. Yes I can do vanilla JS, but my productivity and readability in jquery is better. And this site proves my claim: all their vanillaJS exemple are less expressive and more error prone.
Earlier quoted context omitted.
Actually, no. IE8 supports it. http://caniuse.com/queryselector
IE8 is limited to the old CSS selectors so basically it sucks and doesn't really support it.
The new-stuff, while great for styling, isn't all that relevant for scripting. nth-child, say, is often (though not always) simply an indexing operation on the return value of querySelectorAll; and in general you don't even want that since usually you have a specific element in mind and have labelled that element with a class to find it.
I don't support IE8 anymore, and use CSS3 liberally in the actual css, yet I can't think of more than a handful of cases I used the selectors from javascript, certainly none of them critical. Do you actually use this?
Earlier quoted context omitted.
Yeah, you need XDomainRequest for CORS requests in IE8 and 9. IE10 is fully standards-compliant. http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...
It is very castrated, better to use hidden iframe + window.postMessage for cors in ie8 and ie9.
>post-IE8, browsers are pretty easy to deal with on their own. False: - CSS browser prefixes are automatically inserted by jQuery - Many jQuery selectors don't exist in the CSS selector specification - Looks really really ugly and that makes it hard to read for you and other coders. var pairs = $(".form").not(".old").serialize(); /* without jQuery */ var pairs = [].slice.call(document.querySelectorAll(".form")); var…
> Looks really really ugly and that makes it hard to read for you and other coders. This point might have been better made if you hadn't intentionally structured it to be as unreadable as possible, and also shoved in a few lines of comments to pad it out and make it look bigger than it needs to be. Not a very honest example at all, considering native JS can be as readable as you want to make it. > So be kind with you…
$(".enemy").after('').remove()
var enemies = document.querySelectorAll(".enemy")
for (var i = 0; i Earlier quoted context omitted.
I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense. However, the author goes beyond just selector vs. getElementById(). Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore. How about the code for fade? I never even knew the details of this feature. And I'm…
Considering XMLHttpRequest is what other browsers used before IE caught up, I assume it does work the way you'd expect across modern browsers. I'd have to check the standard and IE8+'s conformance to the standard to be sure. That's what this post is really about for me, reminding that modern browsers follow a standard that allows for getting rid of most of jQuery. Reading it also made me recall a post from 2005 by PH…
It seems to me that if you are making a library, and therefore do not want to make assumptions about the availability of jQuery, one potential solution would be to go the route of AngularJS[1] and have a 'soft' dependency on jQuery.
In this instance you would use jQuery if it was present, but fall back on the code found in this submission if it wasn't.
Are there potential downsides to this solution that I am missing?
Earlier quoted context omitted.
Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.
> $(el).hide() > el.style.display = 'none' You meant something more like document.querySelectorAll(el).forEach(function(e) { e.style.display = 'none'; } and a polyfill for IE8 due to lack of native Array#forEach, right?
No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…
This.
A thing that the examples on that site did not address is the power of jQuery("element.selector") selects a "bucket"/array of elements and functions are executed on each element in that bucket.
So now you may have to add that functionality into your library. Then there is always a non-logical browser inconsistency that needs to be taken care of. Then you need to write tests. Time used for managing the library piles up very fast.