Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

231–240 of 360 posts

Re: You might not need jQuery

#231
post #133
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…

Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobi…

> Over cellular connection you can nicely multiply each KB by 100ms.

This cannot possibly be true. Do you have some data to back it up?

Re: You might not need jQuery

#232
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…

In most cases where you have any level of complexity, you are better off using jQuery or some other already tested out libraries. That being said, blanket statements about technology choices are suspect because every project has different needs and requirements. You should evaluate things on a case by case basis.

If you're creating a simple brochure website for a small business and literally just need to show one hidden element on a click or do something else very simple, there's a legitimate argument to avoid jQuery. It depends on the level of complexity you need.

The web is filled with unnecessary bloat and I'd like to get rid of some of that.

Re: You might not need jQuery

#233

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…

About one year ago, I developed a shared widget. Some fraction of my clients refused to load jQuery, as they still preferred older, less popular DOM libraries.

Starting with jQuery's battle-tested event handling code, I trimmed features unnecessary for my widget: event.data, IE7 support, consistent focus events. I replaced jQuery's indispensable descendant selector feature, formerly jQuery.delegate, with a simple conditional in my event handlers. (e.g. Walk parentNode references from event.target, looking for a class name.)

I was left with about 75 lines of code in my DOM abstraction library. I preserved jQuery's tricks for Microsoft's attachEvent and Safari's text nodes. About 15 lines were dedicated to normalizing attributes. My polyfills for preventDefault and stopPropagation were about 10 lines each.

It's amazing how far native DOM has come in recent years.

Re: You might not need jQuery

#234

Earlier quoted context omitted.

> The problem with jQuery is that it's an all-or-nothing approach. The way it wraps native DOM nodes means it keeps trying to pull you back to using its inbuilt utility methods. Not true at all. You can do a custom build and leave out things you don't need. You can even leave out stuff you DO need and replace with your own simpler shim. See the README file.

Sure, it's technically possible. But not common from the projects I've seen. The APIs seem to be designed with the assumption that all your code will be using jQuery. For example converting a wrapped node to a native DOM node requires an extra call that, in my opinion, is ugly: $('.something').get(0); and could be considered to be an anti-pattern. I don't think this is a bad thing. jQuery does a good job at providing…

> The APIs seem to be designed with the assumption that all your code will be using jQuery.

Again, not true. For example, the `this` in an event handler is the actual DOM element, not a jQuery object. Whether you handle that directly with DOM methods or wrap it with `$(this)` is up to you. Many people prefer the latter but the former is often smaller and prettier.

> For example converting a wrapped node to a native DOM node requires an extra call that, in my opinion, is ugly: $('.something').get(0); and could be considered to be an anti-pattern.

How common is that, really? Your example assumes a single element with that class name. Why not chain a jQuery method behind it and handle the 0 or N cases as well?

Re: You might not need jQuery

#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 by no means a cure-all for Javascript problems.

Now about this site itself. This is a great idea getting people to use and understand native methods, but please also understand that native methods aren't always necessarily the most efficient choice. There are a few of parts of this site I think send the wrong message. Don't get me wrong, I think this is great, but sometimes native methods are no better than jQuery's.

The first one being jQuery's each method. It is a known fact that jQuery's each method is extremely slow, it works, but from a optimisation perspective native ways of looping an array are always the fastest and most efficient.

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.

The second being the use of querySelectorAll (which is awesome btw). It has similar capabilities to that of jQuery's native wrapper for querying, it looks just as nice, but once again the performance isn't all that great. Looking through multiple jsPerf benchmarks, querySelectorAll is rarely the best option to use in most cases. This is an example of one: http://jsperf.com/queryselectorall-vs-getelementsbytagname/4... — if your selector is extremely complicated, think to yourself, how can I make this easier to write? Do I need to query a chain of five classes and use CSS3 selectors, or can I just add an ID to the element I want and query it using document.getElementById instead.

Sometimes jQuery is needed though. It saves considerable amounts of time, especially when the budget of a project is tight and timeline is even tighter and you just need to get something out the door as soon as possible. If you have the time to properly build whatever it is you are building, consider spending that extra 15 seconds writing a for loop to iterate over that array or object.

And to those who understand and have taken a look into the internals of how some jQuery methods work like document.ready, you'll appreciate and know just how many different browser quirks the jQuery team have solved for us. There are quite a few methods where jQuery hides the gory details of a sometimes difficult to get right across all browsers feature.

Personally my favourite thing about Javascript is the power of documentFragment: https://developer.mozilla.org/en/docs/Web/API/DocumentFragme... — this is something all developers who use Javascript need to know about. It helps prevent reflowing and redrawing as well as being extremely efficient and fast for modifying and inserting elements into a page.

Over all of this I think we all need to reflect on the state of Javascript. It's a whole lot more powerful and better than it was 10 years ago, but I think because of the likes of jQuery and others, people have become obsessed with pretty code and methods. I know for loops and prototype methods might not be as nice as your one line of jQuery code, but don't take the easy way out, because you'll soon find the longer your Javascript grows in your app/site, the slower it will become.

Re: You might not need jQuery

#236
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.

Re: You might not need jQuery

#237

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…

In other words, jQuery is the Rails of JavaScript?

Re: You might not need jQuery

#239

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"

Re: You might not need jQuery

#240

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…

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.
Post reply on HN