13 ms·
You will probably need jQuery
- buritica 13y agoWill I?
- korzun 13y agohttp://en.wikipedia.org/wiki/List_of_burn_centers_in_the_United_States http://en.wikipedia.org/wiki/List_of_burn_centers_in_the_Uni...
- zebra 13y agoDear friend, here we are trying not to be Reddit2, and while your post is funny, it does bring nothing to the discussion.
- Fizzadar 13y agopfft I'd rather not offer support for buggy/lagging-behind JS implementations.
- camus2 13y agoYeah, you'd rather not have a business since you dont care about potential client configurations.
- DanBC 13y agoRemember how lousy those [Best Viewed in BroswerX] banner buttons were?
- youWontLikeThis 13y agoYep, as much as those "best viewed in chrome" are.
- seandougall 13y agoWhat do you mean "were"? Mine still looks great next to the hit counter and the link to ./guestbook.cgi!
- Bahamut 13y agoNope, don't usually need it. Also that link locked up my mobile browser for a bit :/
- danheberden 13y agoprobably because github uses jquery
- Bahamut 13y agoNo, 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.
- spaceborn 13y agoIntentionally provocative? It's simply a counter argument.
- rwaldron 13y ago"poor intentionally provocative OP"? How is a list of irrefutable facts a "poor intentionally provocative [original post]"? Show me how smart you are!
- deleted 13y ago[deleted]
- Rumudiez 13y agoYou 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.
- deleted 13y ago[deleted]
- rwaldron 13y agoYou're welcome. It's every line of the jQuery source code, syntax highlighted by github. http://www.amazon.com/Pinzon-Egyptian-Cotton-725-Gram-6-Piece/dp/B002S52ZKS/ref=sr_1_1?ie=UTF8&qid=1391122803&sr=8-1&keywords=towel http://www.amazon.com/Pinzon-Egyptian-Cotton-725-Gram-6-Piec... For your tears.
- danheberden 13y agohow in the hell am i going to have bandwidth for jQuery AND my 200K of carousel images?!
- Yver 13y agoIt's not just about bandwidth, it's also about parsing and executing ~82KB of JavaScript before doing anything on the page.
- bentlegen 13y agoDo you happen to know what the performance impact of parsing and executing ~82KB of JavaScript is? Genuinely curious to know the numbers.
- danheberden 13y agoI get about ~7ms in chrome on a mbp and ~200ms on my shitty nexus s. http://danheberden.com/tools/howlongtoloadjquery.htm http://danheberden.com/tools/howlongtoloadjquery.htm
- nostrademons 13y ago74ms 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.
- danheberden 13y agoI thought we were taking download time out of this
- nostrademons 13y agoThe "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.
- h2s 13y agoThis is a bloody clever counter-argument as well as an excellent example of the right way to use comments.
- shtylman 13y agoLots 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.
- rwaldron 13y agoOMG, 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 https://github.com/jquery/jquery#modules
- shtylman 13y agoAs 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.
- siddboots 13y agoSo 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.
- jmduke 13y agoIt's worth keeping in mind that the size of minified jQuery is 32kb.
- sfeng 13y agoMy 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.
- rwaldron 13y agoTake only what you need https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules
- sfeng 13y agoBut 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.
- nlp 13y agoUgh, 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.
- nlp 13y agoI'm so close to using flash right now. Anyone?
- nlp 13y agoDo I put jQuery before the div? Or after the div? Or in the div?
- roryokane 13y agoI 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 http://stackoverflow.com/tour). Post your question from the following page, editing the details as necessary: http://stackoverflow.com/questions/ask?title=HTML5%20animations%20not%20working%20on%20a%20Nokia%203310%20when%20using%20jQuery&tags=jquery+css-animations http://stackoverflow.com/questions/ask?title=HTML5%20animati...
- msoad 13y agoI 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!
- chc 13y agoThese 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.
- rwaldron 13y ago> 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.
- shtylman 13y agoI'll get the medic.
- 13y ago
- msoad 13y agoI just leave this here: document.querySelectorAll('div').forEach
- danheberden 13y agoNodeLists don't have .forEach in their prototype chain kiddo ([].forEach.call(nodeList, hollaback);)
- scrabble 13y agoI 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.
- TheSisb2 13y agojQuery 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.
- WalterSear 13y agoThat's a hilarious rebuttal.
- tks2103 13y agojust search for all the comments by rwaldron and have a good time
- dpweb 13y agoWriting 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.