Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

331–340 of 360 posts

Re: You might not need jQuery

#331
post #302

Earlier quoted context omitted.

Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than j…

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

You can certainly use JQuery as your API base if you're willing to take the hit on performance and a few hundred KB download, and are willing to take that hit on every project you write.

The problem is that this shuts you out of a lot of hot, emerging markets that can be quite lucrative. You will never work for Google (as a front-end engineer) if you only know JQuery and not the native DOM APIs. Your mobile HTML5 apps will suck and will lose out to native counterparts in the app store. You're at a disadvantage in any competitive web market where people bounce from the website if it's too slow (there are more of these than you think).

If you're willing to limit yourself in this way, sure, go for JQuery. There is still a pretty booming market for Intranet apps or progressive-enhancement mostly-static sites where JQuery is just fine, and it provides a nice productivity boost for those use-cases.

The advantage of polyfills is that they give you flexibility and let you push the edge of technology today, and then they don't become obsolete tomorrow. As the web evolves you just get rid of the polyfill and you already know the latest & greatest of tomorrow. That lets you push into the emerging new markets that can be quite lucrative, at the expense of actually learning the (sometimes hard-to-use) APIs on the bleeding edge.

Re: You might not need jQuery

#332
post #266

Earlier quoted context omitted.

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

> 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". I think this is more important than a side note. The reason jQuery's 'children' or 'find' is way better in my eyes is because of the support for arrays as target and argument, and the possibility to pass the resulting collection to the next command as is. Going the native route, filteri…

It's the main reason I dislike jQuery. It's hard to debug.

    document.getElementById('non-existent').classList; // error

    $('#non-existent').addClass('yay'); // hidden bug
I prefer the explicit solution.

Re: You might not need jQuery

#334
I'm a little sad to see that nowadays there's a strong sentiment of "just use the pre-packaged tool", whereas when jQuery was still in its infancy, there was a lot of lively hacker-minded chatter on the down-and-dirty of getting things to be cross browser.

It's as if there are now two "levels" of people - "regular developers" and "framework designers", and only the latter are really supposed to know about the nitty-gritty. The excitement of finding out about standard, cross-browser gems like insertAdjacentHtml is all but gone :(

I get it that people are focusing more on the entrepreneurial side of things now, but I miss the banter of aspiring tinkerers.

Re: You might not need jQuery

#335

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…

Thank you for reminding me that it's necessary to use my own judgment when deciding which approach makes the most sense to me.

Re: You might not need jQuery

#336
post #307
post #209

Earlier quoted context omitted.

Considering XMLHttpRequest is what other browsers used before IE caught up, I assume it does work the way you'd expect across modern browsers. I'd have to check the standard and IE8+'s conformance to the standard to be sure. That's what this post is really about for me, reminding that modern browsers follow a standard that allows for getting rid of most of jQuery. Reading it also made me recall a post from 2005 by PH…

XMLHttpRequest was first introduced in IE5. I think in retrospect MS regrets its introduction, but that is another discussion entirely.

As I recall, they specifically implemented it in order to facilitate Outlook’s web interface – their collective regret may be tempered by the satisfaction they got from all those high-margin site license sales to which that feature contributed.

Re: You might not need jQuery

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

What would be awesome is if jQuery had the same kind of download builder as jQuery UI, so that you could only include the parts of it that you actually need for a library.

Re: You might not need jQuery

#338
post #270

Earlier quoted context omitted.

It is very castrated, better to use hidden iframe + window.postMessage for cors in ie8 and ie9.

I don't think "castrated" is the word you meant :-) Perhaps "constrained" or "restricted"

...why not?

"to render impotent or deprive of vitality"

Re: You might not need jQuery

#340
post #218
post #163

Earlier quoted context omitted.

> Apps built on newer front-end frameworks like Angular and React might not need it, for example. Well, Angular has jQuery (lite) built in.

It has a jQuery-mostly-compatible node wrapper built-in, which is why it doesn't need jQuery.

Which is both good and bad in that it also modifies jQuery's internals if it's present. (I last looked at the 1.0.x branch)
Post reply on HN