Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

341–350 of 360 posts

Re: You might not need jQuery

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

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

That makes a lot of sense especially in areas where you are competing for people's attention. If you aspire to being a front-end engineer it'd be silly not to know the DOM APIs inside and out, especially now that browsers have such nice dev tooling.

But for those aspiring to create big things another approach is to find a niche where you can offer something exclusive that people want. Thefacebook offered something that students would have put up with > 1s load times to see that they couldn't reliably get anywhere else. http://en.wikipedia.org/wiki/File:Thefacebook.png

Re: You might not need jQuery

#343

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"

Your personal favorite "document fragments" is anyways supported by jQuery for HTML strings that cross a certain complexity. http://jsapi.info/jquery/1.8.0/jQuery.buildFragment

Re: You might not need jQuery

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

I don't think Array.prototype.forEach.call(el.querySelectorAll(selector)) is complex enough to pull in a new library.

Re: You might not need jQuery

#345

Earlier quoted context omitted.

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…

100k is huge, period. Whether or not a huge dependency is acceptable depends on the project. Yes, we know it depends on the project, that was the point of the site. The whole point is "if you are making a library, and don't really need jquery, please don't force that extra dependency on users of your library".

Re: You might not need jQuery

#346
post #289

Earlier quoted context omitted.

Hmm, I'm wary of a test that involves another framework to test the underlying jQ v. Native DOM performance difference. I'd be much more comfortable eliminating Backbone from the equation. Also, this is just one test - wyuenho's claim was for jQ vs. the DOM in general , which is a much broader claim than an unknown subset of functionality. I don't doubt that native DOM methods are faster than jQ, but I like claims to…

The evidence is in the form of an experiment repeatable from your browser's dev console. Play with it.

If you hand me some code to run, I'll run it. Otherwise my test risks not being the same one that you used to make the claim.

The onus is on the person making the claim, not the person trying to verify it.

Re: You might not need jQuery

#347
FWIW, I was on a jQuery-hating kick before I read this article, which explains some of the beauty behind the jQuery api.

http://coding.smashingmagazine.com/2012/10/09/designing-java...

I agree that you probably only want to use a small subset of jQuery (e.g., none of the UI, none of the transitions), and zeptojs is actually a really good alternative. But it really does provide some convenience.

Re: You might not need jQuery

#348

Earlier quoted context omitted.

20ms is significant?

Think of it as a fifth of your time budget spent doing nothing.

Most modern browsers are able to paint while loading script files, especially if you put your script files at the bottom of the page, where they belong. So, no, 20ms of parsing, compiling, and a small amount of execution is not a lot of time. Period.

Re: You might not need jQuery

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

Would just like to point out that, if you are using a commonly used CDN, jQuery/Zepto will most likely be cached already in the browser.
Post reply on HN