121–130 of 138 posts
If you quite literally want "what jQuery uses to select things" and nothing else, you're really looking for Sizzle. http://sizzlejs.com/
Earlier quoted context omitted.
True, jQuery doesn't use the native NodeList for various reasons, but since QSA returns a NodeList, that'd be the equivalent for this "substitute".
> jQuery doesn't use the native NodeList for various reasons Those reasons being: * because it's garbage * because native objects shouldn't (and may not necessarily be) extended * because static nodelists didn't even exist back when jquery was created * because you can't create a nodelist in userland code
* because NodeList instances are host objects and host objects often behaved in unexpected ways in older browsers and IE
If you want to have a look at host object weirdness, try using `console.log` as if it were a function when using the F12 developer tools in IE8. Surprise: it can be invoked like a function, but it doesn't have any of the methods you'd expect a function to have (e.g. apply, call, let alone bind). Another host object quirk was that they were often read-only (which is why "thin" AJAX libraries can't manipulate the native XHR objects directly if they want to support IE8).
"Who cares about IE8?" you ask? Surprisingly some sectors of certain industries still do (civil service in Germany, for example). If your market overlaps with those groups, you'll be thankful most of us were at least able to skip IE7 after IE6 finally died (I'm not sure whether we'll be as lucky with IE9 when IE8 finally bites the dust).
Earlier quoted context omitted.
It's the same reason that, yes, you can put "var x" in an if-block, but it's bad practice because it misleads the reader (even one who knows that Javascript is function scoped) into thinking that x is block-scoped.
I'm almost embarrassed to say it took me way to long to realize JavaScript wasn't block scoped.
Javascript never should've had C-like syntax if it was to have the feature set it does. Its syntax descends from a tradition of languages that have none of its actual features. Most other C-like languages have block scope[0]. So the syntax PLUS the terrible, awful, no-good very bad name lead you to believe it's more-or-less dynamic Java, when nothing could be further from the truth.
[0] ...and require declaration before usage, and have sensible 'this' semantics, and are class-based, and have function parameters that are more than just syntactic sugar, and have ACTUAL arrays, and...
If you are using $ signs all over your code, they'd better refer to jquery and nothing else. jQuery has, for better or worse, become such an integral part of web development, the $ namespace is pretty much owned by it at this point. If you do want to use it for not-jquery, it should be something that is drastically different so someone new trying to patch a bug on prod doesn't run around in circles wondering why thei…
It's not even a project, it's a GitHub Gist. Talk about a lot of fuss being made over nothing.
Of course, the horse is out of the barn on the personal $ library front, so maybe Irish doesn't have to worry about inadvertently influencing people badly. There already was a no-library/micro-library trend 4-5 years ago where lots of people would write their own tiny jQuery-like DOM utilities, and I've worked on a few projects where someone used jQuery-like idioms for their partial reimplementation (I call them "nayQuery"). Even the better ones are a pain where they subvert expectations. And of course, when someone later decides to add jQuery to the project (makes sense, jQuery does more and has an ecosystem around it), now you're using $ for the custom library and jQuery for jQuery, which is disorienting.
I've written my own version of what Irish presents here -- it's a useful exercise, I appreciate his contribution (helps me think about some different ways to approach it), and sometimes it's even concretely useful when you're getting started on a small project with a limited browser target where the rest of the codebase is going to be smaller than jQuery itself.
But when I write something like this, I always name it differently than $.
Earlier quoted context omitted.
Loading over 30 Kb of minified/gzipped Javascript over a 3G connection on a mobile phone is very problematic, as the bandwidth is poor, the CPU capacity for decompressing and parsing is poorer than on the desktop, so the latency can many times be measured in seconds, therefore loading over 30 Kb of stuff that you don't need gets to be a tough pill to swallow. Also the argument of caching is often brought up, but in m…
It sounds like you've done the work to validate the fact that 30Kb is too much for your use case. However, let's be clear here: most people who complain about the size of jQuery are doing so without any basis whatsoever. And even if people are measuring, they may not be measuring the right things. If not using jQuery causes you to reduce your Ajax usage, and reload entire pages as a result instead of only reloading t…
Yes, you can re-implement jQuery in 10 lines of code... if you only support 0.1% of the functionality of jQuery. jQuery was a game changer for web client side development. Thousands of work hours have been spent on it. It had a specially important role of dealing with all the inconsistencies between browsers. If you don't use all the features, nowadays you can just create a custom build with the stuff you want. If yo…
We will always need jQuery. We need a well maintained library that addresses browser inconsistencies and provides a better API. (Don't expect my gist to be maintained like jQuery is. :) I wrote a doc a year ago documenting all the bugs jQuery fixes for you (linked elsewhere in this thread). The jQuery team is talented and I respect their dedication and work greatly. I'm also interested in a conversation about what developers want most from their browser JS stdlib. Because whatever a developer's answer is, shouldn't they be able to get a custom build of that?
Tries to play it cool by wrecking jQuery? Check. No semicolons? Check. Put together by Paul Irish? Check. Yep, this submission is Hipster 1.0 Certified.
Earlier quoted context omitted.
> jQuery as a library has now become huge > So if you can cut down your cold cache loading times by not > including the full jQuery library, that's probably a win jQuery 1.11.3 is 38.4 KB when minified and gzipped. jQuery 2.1.4 is 34.1 KB when minified and gzipped. I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most f…
> I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated. Remember size isn't as much of an issue when it's less than 100kb (though 3G or less networks that will still be painful). The biggest issue is yet another fi…
Less javascript means less cycles burned executing boilerplate framework factories means faster page loading means longer battery life means you can keep that two year old phone that's not quite so fast instead of throwing it in the trash.
jQuery causes global warming. (tongue-in-cheek of course, but not entirely)
Yes, you can re-implement jQuery in 10 lines of code... if you only support 0.1% of the functionality of jQuery. jQuery was a game changer for web client side development. Thousands of work hours have been spent on it. It had a specially important role of dealing with all the inconsistencies between browsers. If you don't use all the features, nowadays you can just create a custom build with the stuff you want. If yo…
I wrote this thing because I wanted the classic jQuery API goodness for 1) grabbing elements and 2) binding events. Yes, obviously this gist doesn't cover the feature set of jQuery; and in my brief readme, I hope I didn't convey something different. We will always need jQuery. We need a well maintained library that addresses browser inconsistencies and provides a better API. (Don't expect my gist to be maintained lik…