Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

Post reply on HN
Print view View original

251–260 of 360 posts

Re: You might not need jQuery

#251

Post by drdaeman »

jpatte wrote: post #96
sfeng wrote: post #75

Earlier quoted context omitted.

You don't need an abstraction to do something that's natively implemented on your platform.

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?

Re: You might not need jQuery

#252

Post by kevingadd »

DigitalSea wrote: post #235

I implore all developers to learn native Javascript methods, because I strongly believe jQuery has created a generation of developers who know the library but not the language. You'd be surprised how many developers I've come across think iterating over an object or array requires Javascript and how many people don't know how to write a simple for or while loop in Javascript. jQuery is a fantastic library, but it is…

jsperf benchmarks of small highly optimizable loops are no better than random numbers. they aren't accurate.

It is true, however, that array.forEach can theoretically be worse than a hand-written loop - and I think in some cases it currently is. This is due to the fact that a call through Array.forEach might have to enter and exit C++ code, instead of remaining entirely in JS, which prevents optimizations like inlining and invariant code motion.

However, these problems will go away over time as most JS builtins are moved to pure JS implementations (which enables full optimizations).

If you are trying to determine things like 'what's the fastest way to iterate a sequence', the ONLY REALISTIC WAY to do this is to benchmark your actual use case, in context and see which approach is faster. Microbenchmarks applied to a language like JavaScript are, 99% of the time, complete horseshit.

Re: You might not need jQuery

#253

Post by doorhammer »

DigitalSea wrote: post #249
doorhammer wrote: post #243

Earlier quoted context omitted.

> The alternative given for a jQuery.each statement is the IE9+ supported Array.prototype.forEach — now you'd think this would be faster right? It's actually still not as performant as it could be. As this jsPerf set of benchmarks shows is that a for loop is the most performant option: http://jsperf.com/foreach-vs-jquery-each/38 — it might not be as pretty as jQuery.each or Array.prototype.forEach, but heck, it's a w…

I think you make a very valid point. One poorly optimised loop using jQuery.each or Array.prototype.forEach unless you're writing a heavily JS intensive application isn't really going to make a noticable difference to performance. The average Joe developing a Wordpress theme with a slideshow and a few other little pieces of JS probably won't see any lag nor benchmark said theme. However, it does all add up the more y…

Got it. That makes sense, and I definitely agree with the point of knowing the language features and being aware of the trade offs you're making by choosing one technique over the other.

Re: You might not need jQuery

#254

Post by AznHisoka »

efuquen wrote: post #57

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…

I totally agree. We need a "Why you don't need Ember" and "Why you don't need AngularJS" lesson before we even think about not needing JQuery.

Re: You might not need jQuery

#255

Post by samspot »

DigitalSea wrote: post #235

I implore all developers to learn native Javascript methods, because I strongly believe jQuery has created a generation of developers who know the library but not the language. You'd be surprised how many developers I've come across think iterating over an object or array requires Javascript and how many people don't know how to write a simple for or while loop in Javascript. jQuery is a fantastic library, but it is…

I like each better than for primarily for readability. However I usually use the each from underscore, and I'm not sure how well that one performs.

Re: You might not need jQuery

#257

Post by kibibu »

drdaeman wrote: post #251
jpatte wrote: post #96

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?

This equivalency only works when el is a DOMElement, not a selector string.

Re: You might not need jQuery

#258

Post by sinkasapa »

hrktb wrote: post #196
sinkasapa wrote: post #122

Earlier quoted context omitted.

I think the point is that "$.contains(el, child)" is not a useful abstraction of "el.contains(child)".

You wont have $.contains, instead $(el).children(child) returns a chainable filtered list of the first level of child nodes, or $(el).find(child) will go down recursively. jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.

These two new functions you mentioned are both in the article linked to above. 'el.children' and 'el.querySelectorAll(selector)' are given as alternates. It is true they aren't 100% the same but JQuery isn't different enough in my opinion for there to be any clear reason to use it instead of what is already available.

As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator".

Re: You might not need jQuery

#259

Post by aj »

hacknat wrote: post #210
__david__ wrote: post #102

Earlier quoted context omitted.

I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing. A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code. Certain parts of jQuery are heavenly and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not…

It might be the most cached file on the internet. Pulling jQuery is hardly expensive. Especially if you're pulling it from the google cdn.

Caching or CDN does not help in squeezing out JS performance (actual JS execution and not n/w performance)

Re: You might not need jQuery

#260

Post by kishor_gurtu »

nostrademons wrote: post #212
latj wrote: post #116

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…

IE has been basically standards-compliant for XHR since IE9, and possibly before: http://www.w3.org/TR/XMLHttpRequest/#interface-xmlhttpreques... http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85)...

Funny, because IE invented XHR.
Post reply on HN