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

241–250 of 360 posts

Re: You might not need jQuery

#241

Post by Iftheshoefits »

leeoniya wrote: post #239
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 strongly believe jQuery has created a generation of developers who know the library but not the language i think you mean "know the library but not the DOM and additional HTML5 APIs" - they are after all just native libraries. ES5/6 would be the "language"

JavaScript is a dynamic language, and it is arguably the case that many of the frameworks that exist for it hide or transform enough of the "native" implementation details as to be different languages. Or supersets of it, if you like. I don't think it's at all unreasonable to suggest that a developer who uses jQuery (or any other framework) doesn't have to have more than a vague, fleeting understanding of the "native" language under it.

Re: You might not need jQuery

#242

Post by latj »

lfender6445 wrote: post #240
politician wrote: post #237

Earlier quoted context omitted.

In other words, jQuery is the Rails of JavaScript?

jQuery is a library where rails is a framework. but I will agree, a lot of developers are likely to use it as a crutch in lieu of fully understanding cost vs benefit in your app. if this is the case, then you very might well need jquery.

node express is the rails ;)

Re: You might not need jQuery

#243

Post by doorhammer »

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…

> 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 whole lot faster than the alternatives.

So I'm by no means a compilers or js engine expert, and this really is an honest to god question and not an attempt at sideways criticism.

When I use each, forEach, map, or something like that, I'm usually optimizing for my own readability and to try to create more concise and understandable code (admittedly only for folks comfortable with those paradigms) and not actual raw performance.

Is it the case that Array.prototype.forEach is faster than a for loop for all modern browsers, and could that change with engine optimizations? My wonder there is that it smells like premature optimization while sacrificing readability (again, assuming you think map/forEach/etc is more readable, which might be a huge assumption).

Thoughts?

Re: You might not need jQuery

#244

Post by smileysteve »

EpicEng wrote: post #99
_lce0 wrote: post #88

Earlier quoted context omitted.

git fork jquery git branch "fix-performance-issue-at- " git commit ... git push

Rarely that easy. Oftentimes a performance issue can be traced back to an implementation that must support a dizzying array of use cases. You may not need all of that, but you certainly cannot just tear it out and push it back up.

You make another great point. Jquery includes tests for its implementations.

When you improve a slow implementation, it should be tested against that existing dizzying array of use cases.

Re: You might not need jQuery

#245

Post by nostrademons »

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…

Another JSPerf on loops with largely the same conclusions:

http://jsperf.com/loops/70

Re: You might not need jQuery

#246

Post by danielweber »

polemic wrote: post #49

This be right on a purist level, but on every practical level there is little reason not to use [library of your choice]. If you're loading from the google/jQuery CDN (with suitable fallback, obvs.) you've got a good chance of a cache hit, and even if it misses it's a tiny one-off penalty. And ultimately, why not? jQuery works, has a wide base of users, etc. Sure your trivial Js might not need jQuery features now, bu…

Isn't it a giant security hole to be loading part of your library from another site you don't control?

Zillions of people do it anyway, so it's not like you won't have lots of company.

Re: You might not need jQuery

#247

Post by craigc »

smrtinsert wrote: post #171
__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…

For me jquery is all about events. Making sure I get the event tree bubbling in the correct way across the entire universe of browsers and all its data being normalized is such a time saver. Even their support isn't perfect, but I'm sure its way better than any other event library out there in terms of breadth and depth of testing. The selectors bit is a nice to have, but that is getting easier since its inclusion in…

If you are looking for a standalone event (delegation) library check out one I wrote http://craig.is/riding/gators. The syntax is very similar to jQuery.

Re: You might not need jQuery

#248

Post by jimbokun »

logicallee wrote: post #228
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…

did you write this post with a thesaurus? No? You literally typed EVERY SINGLE WORD in this post? Having tools at your disposal is a good thing. Why would you type out four sentences when you can have pages of pre-written content?

Saying things more concisely in natural language is usually a good thing, too.

Re: You might not need jQuery

#249

Post by DigitalSea »

doorhammer wrote: post #243
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…

> 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 you use Javascript for, you eventually get to a point where the milliseconds of delays and spikes in RAM usage add up and cause delays/lag.

I think it's just important to be aware of the alternatives and trade-offs using certain methods and knowing when to a 3 line method in place of a one-liner piece of jQuery. On a site I am currently working on I am using jQuery.each, I am modifying elements in the page using jQuery.width and all kinds of other things I normally would advise against in a large application. But the site I am building which is a Wordpress theme uses such little amounts of Javascript that using a more optimal method wouldn't really make much of a different interaction and latency wise.

My point was more-so that there are developers out there using poorer methods even in large-scale applications because that's the only way they know how to do it. Just being aware of what you can do in Javascript can be a beautiful thing and even save your hide in a situation where the page is freezing up when you scroll (an event I recently witnessed occur and had to fix).

In time I do believe native methods and certain implementations will get better. Javascript has evolved quite a lot in the last few years and shows no signs of slowing down.

Post reply on HN