Hacker News new | past | comments | ask | show | jobs | submit login
You will probably need jQuery (gist.github.com)
222 points by vladikoff on Jan 30, 2014 | hide | past | favorite | 77 comments

Lots of those are for Sizzle.

jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code.

Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much.

My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.

OMG, you should file a ticket for jQuery core to implement some kind of system for breaking up the source into modules!! Here's a link: https://github.com/jquery/jquery#modules

As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.

Personally, I don't think you can simultaneously use tons of plugins and also complain about being forced to include jQuery. If you don't have the time to roll your own, then you probably don't have the time to prototype Array ten times again for missing features in various clients.

So just ship your code along with the specific jQuery modules that you want to use. The fact that there isn't a better way to do this is a fault of javascript, not a fault of jQuery.

There is, it is called browserify and npm :)

Snarkiness and sarcasm aren't the best way to get people to take your arguments seriously.

I wasn't being snarky, I was making playful jokes :P

> it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code.

I don't understand how the presence of jQuery on a page forces you to think that way (or any specific way).

I don't understand either but it's a habit I've had a hard time breaking out of "full stack" developers.

The natural way to code is that you sit down to do a task, and you set out to do that thing in the most direct way possible, then you are done. The insight that more advanced coding techniques can metaphorically collapse space entirely and make the sum journey shorter tends to be something only picked up after years of experience... if that.

Bashing DOM nodes together to do a task is merely one manifestation of this. Multi-thousand line functions, code that makes thousands of queries to a DB and manually performs some enormous task that could have been more easily done in three slightly more complicated ones, code that just flings open a socket every time it needs to do something on the network and just starts stuffing bytes at a remote service... it's all manifestations of this.

I don't have a good word for this. I wish I did. Probably something buried on C2 somewhere if I poke around hard enough.

> Bashing DOM nodes together to do a task is merely one manifestation of this.

I suppose that's what I was getting at originally. There's absolutely nothing that removing or adding jQuery will do to impact the larger problem of treating client-side development as software engineering instead of incoherent scripting. None of the advice on the originally posted site would change those organizational/logical problems.

"Bad management"

These are the things that get cleared up by code reviews, break sprints, bug hunts, periodic refactoring… in many cases, YANGTNI applies. That's not an excuse for long-term sloppy code, but it's an excuse for developing good practice when making changes to an existing codebase.

Mootools, rest in peace, was completely modular and you'd check the features you wanted see: http://mootools.net/core/

MooTools modified built-in objects in future hostile ways. Do you miss that too?

Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.

Polymer is also following the same general approach, and has the advantage of most of it being built into the browser and webstandards.

Yep, I was a huge fan of Mootools back in the day. Took me a long time to switch over to jQuery, and even then it was because I had no other choice.

What you're asking for does exist: http://ender.jit.su

These aren't really what the author claims. The first two are actually the same thing, which doesn't appear to be jQuery working around a browser bug.

The third is just noting that a jQuery function doesn't work in some contexts.

The fourth and fifth (which, like #1, are two lines from the same comment) are just documenting a try/catch block because something jQuery is doing might throw an exception.

The sixth is legitimately working around a browser issue, but it's not something you'd need to worry about unless you wanted to write that jQuery function. Like, it doesn't actually cause problems — it's just necessary to make that jQuery function return the exact value that they want.

The seventh is just an attribute named "support".

So far it looks like this isn't actually a list of reasons you will need jQuery, but a list of places where the string "support" occurs in the jQuery source. The fact that so few of them actually have anything to do with the compatibility of client code kind of undermines the point the author is trying to make.

> These aren't really what the author claims.

As the author, I can assure you they are what I claim them to be: Points in the source code that identify some issue in some browser.

> The first two are actually the same thing,

Whoops! I thought I had removed the first one. Thanks for the bug report. The second is true, we received bug reports when we used we had issues with "use strict" in Firefox. I removed the first one anyway.

> The third is just noting that a jQuery function doesn't work in some contexts.

Wrong, it's a note about IE reporting the wrong value.

> The fourth and fifth (which, like #1, are two lines from the same comment) are just documenting a try/catch block because something jQuery is doing might throw an exception.

Because a particular browser has abnormal behaviour.

> The seventh is just an attribute named "support".

I thought removed that. It matched "support:", so you're still wrong.

> So far it looks like this isn't actually a list of reasons you will need jQuery

Accept that it does with the exception of two things I thought I had removed.

You owe me an apology.

To be perfectly honest, I think it's a bit of a reach to suggest that I "probably need jQuery" because strict mode limitations caused problems within jQuery once upon a time (like, isn't that basically jQuery fixing a problem it introduced?), or because jQuery includes a try/catch block for a case that I will never come across in my entire life. jQuery certainly needs those, but I don't.

I don't know exactly how many of the issues are real. Since of the ones I listed only 3 of 5 were real even by your count, I'd be surprised if none of the others were at all questionable. But even if we accept that they're all real, hair-on-fire problems with vanilla JavaScript, I still think you're going too far. At the very least, jQuery is not the only library out there that handles compatibility issues. Lots of people who use other libraries do not "need jQuery."

Basically, I think you have made a much broader claim than you have been able to support so far. I'm absolutely not trying to knock the hard work of the jQuery team or suggest that jQuery is useless. If you had just said, "jQuery is still really useful. Here's a few things it does for you that you'd never think of," I'd have said, "Great post — thanks for reminding everyone." Instead, you took a very hard line that came off as pretty combative, but your supporting examples were really shaky. So I disagreed.

> To be perfectly honest, I think it's a bit of a reach to suggest that I "probably need jQuery" because strict mode limitations caused problems within jQuery once upon a time (like, isn't that basically jQuery fixing a problem it introduced?),

No, the point was that it highlights an issue that exists with some browser.

Also, I didn't name this thread, notice in my gist it doesn't say anything about needing anything. I was merely presenting facts.

> I'd be surprised if none of the others were at all questionable.

If you'd like to spend the time going through each one of them with me, we can meet on IRC and work through them all. We might even be productive in eliminating some unnecessary code if we find issues that no longer exist in a browser's current and last current release. Let me know?

To your last point, I again, I didn't name or post this thread. Did you read what I wrote in the gist? I think you can't really argue with this:

"The following links will bring you to line in the jQuery (current master, is a 2.1.x build with no oldIE-specific code) source above. The line (and probably adjacent lines) will identify some existing browser issue that jQuery must account for when providing an API for consistent browser/DOM programming semantics."

That's all I said. So are we square? Wanna work on these with me? I'm a nice guy, I promise.

I think it boils down to: Jquerys cross browser bugs and limitations are well known. Your vanilla js issues are less so.

Moreover, nobody at apple is going to ever get fired for breaking the way your code works in mobile safari.

Breaking the way Jquery works, however, is probably a legitimately fireable offense.

I read line 255 the same as chc: that the jQuery function fails in certain cases with IE8. It appears the corresponding bug (mentioned in the comment) supports this reading: http://bugs.jquery.com/ticket/2968

I'll get the medic.

How are those acception handlers working out for you?

This is a bloody clever counter-argument as well as an excellent example of the right way to use comments.

how in the hell am i going to have bandwidth for jQuery AND my 200K of carousel images?!

It's not just about bandwidth, it's also about parsing and executing ~82KB of JavaScript before doing anything on the page.

Do you happen to know what the performance impact of parsing and executing ~82KB of JavaScript is? Genuinely curious to know the numbers.

I get about ~7ms in chrome on a mbp and ~200ms on my shitty nexus s. http://danheberden.com/tools/howlongtoloadjquery.htm

Cool. A few comments:

* You're loading the unminified version.

* You're factoring the network request time into the benchmark. I was interested in pure parse time. Which was 27ms according to Chrome Developer Tools: http://i.imgur.com/hgFiGTu.png (the score on the page was 110ms).

I'm curious what people who complain about "parse time" consider to be an acceptable score.

Edit: Ah, I didn't realize you were discarding the network time. I was fixated on the number spat out by the page.

74ms for initial load and averaging about 20ms subsequent loads on a MBP with Chrome. Ubuntu Chrome is similar. 837ms initial load, average about 140 ms subsequent loads on a Moto X on T-Mobile.

I thought we were taking download time out of this

The "subsequent load" time should be pretty close to this. I'm getting about 20-30ms of "Evaluate script" time when I run a profile in Chrome's Timeline tool.

jQuery arose in an era where browser quirks and incompatibilities were everywhere and, due to the circumstances of developing accessible websites, enjoyed widespread adoption. Nowadays that the front-end is getting so much attention, it pains me to see so much jQuery hate. Here are some thoughts I feel need to be articulated:

Rather than everyone reimplementing their own utility libraries, here we have one central library already cached by most areas of the internet, being maintained by some of the brightest developers in JS, and provided free of charge.

If your site permits, you are probably using the Google CDN hosted version of jQuery. If not, you should. If you can't, then your users can handle some 80kb one time load for a tremendous reduction in development time and increased consistency between browsers (let's be honest, cross-browser testing is a pain and we avoid it as much as possible).

So many people think that by using jQuery your code must immediately be bad. Spaghetti code is code with bad structure, jQuery does not enforce any structure so any bad code that includes jQuery is not the library's fault. I also believe (I don't have evidence for this) that this thought tends to occur amongst people who have learned front-end development using jQuery because it was very accessible, and then moved on to something else, and then looking back at their old, cruddy code developed negative feelings towards jQuery itself. jQuery doesn't care how you structure your code; you can use jQuery (admittedly with some difficulty) with Angular, Backbone, or any other popular framework. But you can't use Angular with Backbone. Arguments against jQuery that attack poor code / structure / "prettyness" are completely misrepresenting jQuery as a library.

In that same vain, jQuery is not slow. How you use jQuery, just like how you write your vanilla JS, is what determines performance. Some jsperfs show jQuery being slower than vanilla JS or lodash/underscore, but that's because jQuery is checking for many more things. You don't have to use jQuery if you know how to improve critical code, and you really shouldn't. However, it allows for you to write code quickly, without much complex thought for validating against edge cases at a very negligible performance reduction.

It's worth keeping in mind that the size of minified jQuery is 32kb.

I believe that size assumes gzip on top of the minification. Minified alone, jQuery should come in at just over 90kb.

gzip isn't rare, it's a standard.

I didn't claim that it was or wasn't.

I love this! People think with document.querySelector and Element.classList your need for jQuery ends!

The more DOM APIs means even more need for jQuery. Stuff like Node.bind() and Object.observe() are some samples that need to polyfilled to make it work in all your modern and badass browser!

No, they mean Node.bind(), it's a Polymer proposal.

Nope, don't usually need it. Also that link locked up my mobile browser for a bit :/

You're welcome. It's every line of the jQuery source code, syntax highlighted by github.


For your tears.

probably because github uses jquery

No, just the amount of text content downloaded and parsed into the DOM was the issue.

Kinda surprised with the downvotes considering the poor intentionally provocative OP.

Intentionally provocative? It's simply a counter argument.

"poor intentionally provocative OP"?

How is a list of irrefutable facts a "poor intentionally provocative [original post]"?

Show me how smart you are!

You seem very upset and are surely alone in feeling that way. Please refrain from posting before you start yelling people who oppose the opinion of the topic.

My question is, do you really need a 9116 line library, or do you need a handful of 100 line libraries?

Not because 32k is too much data, but because it's just not in line with how I envision dependencies anymore.

But they don't exist in isolation. They can't be argued about, reasoned about, replaced when a better way of looking at the problem is discovered, without convincing all of the jQuery elite that it's the right move.

It's not about jQuery being too many bytes, it's about the idea that A. for many things you can just use the browser APIs now, and B. for those handful of things that need libraries, make them targeted and replaceable.

Beyond all that, if you use a custom build of jQuery, you can't really trust that any library requiring it will actually work, returning to the original point: Libraries should try to not depend on jQuery, so you can enjoy your custom build in peace.

Writing a library strictly to modern browsers and using conditionally loaded polyfills is the better choice, than building cross-browser into the library.

The former, over time more people load less code, as they move to the new browsers.

The latter, code doesn't decrease, but overall the amount of dead code increases, as people move to the new browsers.

That's the cause of all this criticism of JQ now.. Over time, more of JQ code becomes dead or unnecessary as these functions are subsumed into the native browser.

I only really want jQuery core most of the time, and then only because I'm supporting IE7, which does not support ECMAscript 5.

It is often simpler to reuse this functionality that people have worked on optimizing across a large number of browsers than it is to spend the time to reimplement that functionality myself. I can better spend that time getting a new feature working.

That's a hilarious rebuttal.

just search for all the comments by rwaldron and have a good time

Ugh, I'm using jQuery with a CDN and my HTML5 animations still won't work on my Nokia 3310. Am I missing something? So frustrated.

I'm so close to using flash right now. Anyone?

Do I put jQuery before the div? Or after the div?

Or in the div?

I don’t fully understand your problem from what you’ve described, but I think you’d be more likely to get help on Stack Overflow (http://stackoverflow.com/tour). Post your question from the following page, editing the details as necessary: http://stackoverflow.com/questions/ask?title=HTML5%20animati...

Will I?






pfft I'd rather not offer support for buggy/lagging-behind JS implementations.

Yeah, you'd rather not have a business since you dont care about potential client configurations.

Remember how lousy those [Best Viewed in BroswerX] banner buttons were?

What do you mean "were"? Mine still looks great next to the hit counter and the link to ./guestbook.cgi!

Dear friend, here we are trying not to be Reddit2, and while your post is funny, it does bring nothing to the discussion.

I just leave this here:


NodeLists don't have .forEach in their prototype chain kiddo ([].forEach.call(nodeList, hollaback);)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact