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

321–330 of 360 posts

Re: You might not need jQuery

#321

Post by talmand »

Sssnake wrote: post #216
smrtinsert wrote: post #191

Earlier quoted context omitted.

jquery is really just an abstraction for dom, it is not an api for application building. When I have to use the dom, I definitely turn to it. I'm not sure why people object to having additional helper functions in jquery for a measely 100k or so. You don't have to use plugins you know, its not a law.

Because 100k is not measly, it is huge. And jquery is hundreds of times slower than the perfectly fine native methods.

Whether 100k is huge or not depends on the project's requirements. In some cases it's perfectly fine, in other cases it's a problem. Such a broad statement cannot be supported.

Much the same; even if jQuery is that much slower it can sometimes provide something that overcomes the slowness factor. It varies from project to project. Especially if the project scope practically requires you to rewrite jQuery from scratch, you might as well use it.

Re: You might not need jQuery

#322

Post by talmand »

wyuenho wrote: post #312
lmm wrote: post #302

Earlier quoted context omitted.

> You should always know what browser feature you are using. 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.

The point is, jQuery doesn't free you up from remembering lower level details, they are still there in your face all the time, especially when it comes to event delegation and handling. jQuery also doesn't help you with CSS, which is even more of a pain than DOM inconsistencies. The whole point of polyfills is to patch browser incompatibilities, often times without losing any performance to newer browsers, so you can…

Actually, jQuery can help with CSS inconsistencies, much the same way vanilla Javascript can, if you have the mind to use it that way.

You seem to be laying much of the "mediocre experience" on jQuery in this case. I would like to know why you feel this way. Seems to me that loading in polyfills for every browser inconsistency can lead you to the same problems you feel exist with jQuery.

I don't just care what my browser is doing, I care what all of them are doing; which often leads to using jQuery. Depends on the project and the number of expected browsers involved.

Polyfills are things you learn once and drop in once? So is jQuery.

What if the best experience to be provided suggests using jQuery? Would you use it?

All in all, to use or not use jQuery often depends on the project. If it fits, use it; if it doesn't, don't use it.

Re: You might not need jQuery

#323

Post by talmand »

nilsbunger wrote: post #131
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…

It's better if libraries don't just assume jQuery is everywhere, because I suspect those days are ending. Apps built on newer front-end frameworks like Angular and React might not need it, for example. As a library author it's becoming more important to think case-by-case -- use raw JS if you just have some simple selections or XHRs, or use Zepto/etc if that covers you, and only depend on jQuery if you really need it…

If it's just a general library to use anywhere, then sure build it with no dependencies.

But if it's a library intended for Angular then the library would be built with Angular as a dependency, much like it would be with jQuery.

I don't see a negative with a library being built that has dependencies if it is intended to be used in conjunction with the thing it is depending upon, since in most likelihood a like-minded developer is already using it.

Re: You might not need jQuery

#324

Post by talmand »

kibibu wrote: post #257
drdaeman wrote: post #251

Earlier quoted context omitted.

> $(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.

Which one is likely to be more common?

Re: You might not need jQuery

#325

Post by talmand »

daleharvey wrote: post #132
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.

Its el.hidden = true; in modern browsers

According to specs mentioned elsewhere, it seems to have reasons to exist other than just display hide/show purposes.

It's easily overridden by CSS.

el.style.display = 'none' pretty much works everywhere.

To me, it seems to depend upon what the purpose of hiding/showing the element is in specific cases.

Re: You might not need jQuery

#326

Post by talmand »

Kudos wrote: post #194
iagooar wrote: post #141

I would like to add a thought about the dispute about the need of using jQuery. Let's say we know a consultant, let's call him Bob, who works on client projects. He needs to implement new features fast, and does not want to worry about low level stuff. Once he's done with a project, he moves on to another. Then, we meet a JS-framework developer, let's call her Alice. She has to weight every line of code she writes be…

Right, and this webpage is explicitly targeting Alice.

But some of the comments on this page don't seem to get that. I'm seeing too many broad "you should never use jQuery because x" statements.

Re: You might not need jQuery

#327

Post by talmand »

BESebastian wrote: post #291
ivanca wrote: post #195

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

First off, when using jQuery you are still coding in the native language.

Second, the many debates that have happened on HN it is quite clear there is no set "style" in coding Javascript. My style of coding in the native language may be quite different than your style. Therefore, if you use your style in a verbose manner because you choose to not use jQuery and I use my style in a more concise manner because I am using jQuery, it could be said the more concise method is kinder to someone following behind.

But like all things considered a style, opinions vary.

Re: You might not need jQuery

#328

Post by talmand »

lowboy wrote: post #185
wwweston wrote: post #109

Earlier quoted context omitted.

querySelector and querySelectorAll could have been pretty great, but they suffer from some serious problems as they ended up spec'd. The one I hate most is that qSA returns Yet Another JavaScript Collection That Is A Lot Like An Array But Isn't An Array And Therefore Doesn't Have Any Of The Nice Methods(TM). Yes, you're going to have to iterate over the thing using an index in a loop. There's others: http://ejohn.org…

Array.prototype.slice.call(document.querySelectorAll('.myClass'), 0); Or if you want to abstract that into a utility function: function qsa(sel) { return Array.prototype.slice.call(document.querySelectorAll(sel), 0); } qsa('.myClass'); // Returns array of elements

And now you are on the way to rewriting jQuery from scratch.

Add a few more helper functions, separate it all out to its own js file, reuse the js file in other projects, and soon people will complain about the bloated js file you keep using in your projects.

Man, I really do enjoy my chosen line of work. It creates such fun things to debate over.

Re: You might not need jQuery

#329

Post by talmand »

dmethvin wrote: post #234
underwater wrote: post #220

Earlier quoted context omitted.

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 D…

Or even better, if you're only selecting one DOM element that doesn't need the jQuery wrapper, then don't use jQuery for that one case. There's nothing that prevents doing that even if jQuery is being used for other elements in the project.

Just because jQuery is loaded doesn't mean you have to use it for everything on the page.

Re: You might not need jQuery

#330

Post by Iftheshoefits »

TheZenPsycho wrote: post #278
Iftheshoefits wrote: post #275

Earlier quoted context omitted.

Yes, that's rather the parent's point, I think.

except "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" is wrong. It's all still javascript. Just.. plain.. javascript. with a different api/library.

I don't think you understood what I wrote. And I'll leave it at that.
Post reply on HN