29 ms·

You Don't Need JQuery

240 points by rnicholus 12y ago

deleted 12y ago
[deleted]
random28345 12y ago
Every time I try to build something without jQuery, I regret it. Not because of selectors, that's (sometimes) easy to do for lots of (basic) selectors. Not because of DOM manipulation, as long as you're willing to sacrifice simplicity and readability, you can build iterative loops to modify a collection of HTML elements. No, it's the unexpected things that cause me pain. Want to use event handlers on dynamically generated DOM objects? Write your own event bubbling library. Want to create custom events/handlers? Ditto. Promises, .serialize(), .extend(), etc. might all be simple to write your own version, but when you realize you've reimplemented 50% of jQuery to avoid using jQuery, you feel like an idiot. [Source: I do this every 3 years] Life is too short to not use jQuery.
- sfeng 12y ago
  There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does. Real bundling with tools like Browserify is making it more and more feasible to use single-purpose libraries instead of monolithic ones like jQuery.
  - random28345 12y ago
    > There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does. I agree with all those things. jQuery is the lowest common denominator. It's the best at nothing, bloated with support for Palm Pilot browsers and Safari 1.0, and doesn't have all the cool grunt/gulp/amd/broccoli/cucumber/jsx/fotm neologisms. If I'm building a new, long-term project, I'm going to evaluate all the options, and craft the best possible technology stack for my new app. But sometimes worse is better. Like a smooth pebble pulled out of a stream, it's taken a long journey and had most of the rough edges rubbed off. It's already in your browser cache from 4 different CDNs. Someone else can pick it up and support it easily. And that's what often makes it the best choice, when you want to avoid bikeshedding over what the hottest new thing is, and just make a webpage. jQuery may not be the best technology, but it's a sane default.
  - bombtrack 12y ago
    I'm sure you're aware of this, but for others who may not know: the 2.x versions of jQuery dropped support for old browsers (IE 6, 7, 8) to reduce size (12% smaller) and complexity necessitated by being so backwards-compatible [0]. Thankfully we only support IE9+ where I work, so I grab the latest 2.x version these days. [0] - http://blog.jquery.com/2013/04/18/jquery-2-0-released/ http://blog.jquery.com/2013/04/18/jquery-2-0-released/
  - wvenable 12y ago
    The thing is there's always other libraries that provide better implementations of things. Likely the instant you pick one, there will be something "better". jQuery has the benefit of being as much of a standard library for the web as anything else. Often it's not worth the time and effort to hunt down the absolute perfect combination of libraries to accomplish the same thing.
- Youpinadi 12y ago
  Agreed 1000%
- NDizzle 12y ago
  Yep. Use the built in browser methods? For which browser?!? All of them? I have to support some enterprise guys on IE8, sometimes I'm lucky to have them on IE9. Life isn't always a hipster website where people can get lunch delivered on their phone or whatever. Things like jQuery are fine.
  - pjmlp 12y ago
    Fully agree with you, it is worse actually as even between versions of a specific browser, behaviors change.
- williamcotton 12y ago
  Life is definitely too short to not be using npm, browserify and React! https://www.npmjs.com/package/browserify https://www.npmjs.com/package/browserify https://www.npmjs.com/package/react https://www.npmjs.com/package/react And then use just what modules you need. All the functionality of jQuery has already been ported to various modules. https://www.npmjs.com/package/extend https://www.npmjs.com/package/extend https://www.npmjs.com/package/promise https://www.npmjs.com/package/promise https://www.npmjs.com/package/serialize-form https://www.npmjs.com/package/serialize-form
  - random28345 12y ago
    > Life is definitely too short to not be using npm, browserify and React! These are all cool things, but sometimes you want to simply make a web page without setting up node and npm and all that jazz. Think of it this way... jQuery is like getting a subset of the most common functions you get by using in browserify, but without requiring a build step!
    - klibertp 12y ago
      > sometimes you want to simply make a web page without setting up node and npm and all that jazz No, absolutely impossible. That would mean I'd have to actually write JavaScript instead of LiveScript and that would be unbearable... ;) On a more serious note: yes, node is a bit of an overhead. It may be too much for very simple, one-off projects, but it starts making sense as soon as the project becomes even a little bit more complex.
    - williamcotton 12y ago
      This is about more than just a build process. jQuery's imperative DOM manipulation is a horrible way to manage state compared to React. These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approach to system design. A build process that integrates with a versioned package manager is fantastic.
- Pxtl 12y ago
  Yeah, the problem with jQuery is all that other stuff that nobody uses and backwards compatibility with browsers nobody supports. A "lite" jQuery with the same familiar API but a stripped-down featureset for higher performance and smaller size would be nice.
  - K-Wall 12y ago
    Zepto might be what you are looking for. http://zeptojs.com/ http://zeptojs.com/
  - abritishguy 12y ago
    Just use the CDN copy of jquery and it will be cached in the users browser already since so many websites already use it.
    - LocalPCGuy 12y ago
      Not really, the cache-hit benefit is a myth. Too many CDNs, too many versions of jQuery in use, cache's too small... So ..using jQuery via a CDN, depending on which you use you have a 1 in 119, or 1 in 833 chance of the user having a cached copy. http://www.i-technology.net/2013/11/the-myth-of-cdn.html http://www.i-technology.net/2013/11/the-myth-of-cdn.html more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... There are valid reasons to use a CDN (get the scripts closer to the end user, offload the data transfer costs to the CDN provider, etc) but it isn't due to the potential for a cache hit.
      - chdir 12y ago
        > you have a 1 in 119, or 1 in 833 chance of the user having a cached copy That statistics has assumptions on what's the most popular jQuery versions being used. It would make sense if there was real data to support that.
  - dmethvin 12y ago
    You're aware of jQuery custom builds? Leave out what you don't use. It's in the README file.
- kaonashi 12y ago
  React handles event normalization, fyi.
- klibertp 12y ago
  You can "eat the cake and have it too" with something like this: http://microjs.com/ http://microjs.com/ Basically you import everything you need and only what you need. Need extend? No prob: http://microjs.com/#extend http://microjs.com/#extend - just pick one. And with browserify and npm literally everything you need to do to include a library in your project is a single command, so having to include "that many libraries" is not really a problem. I'm a huge fan of having many little libraries instead of a few big ones, and JS - both on the backend and frontend - makes this possible to the bigger extent than most other environments.
  - girvo 12y ago
    Same. Between Micro JS, Vue.js and Browserify, I can craft the perfect tech stack with best-of-breed libraries, and come out with a much smaller, faster, and less janky site at the end of it. Oh, and being CommonJS modules via Browserify makes life pretty great, and my code maintainable and easy to follow!
- icantthinkofone 12y ago
  I've only used jQuery once, for a client who insisted we use it, and it was the worst experience of my company's life. It only made us use bold on all our documents which proudly states, "No JQuery!".
  - _mtr 12y ago
    Surely you can expand on this story. What made using jQuery so painful?
    - mkhalil 12y ago
      I'll try. My client was mad I was trying to charge him an extra $6000 for the time I spend to get the stuff I write to work across different browsers and asked me to use jQuery instead.
      - deleted 12y ago
        [deleted]
- agumonkey 12y ago
  greenspuns-tenth-rule.js
atwebb 12y ago
Still reading through but it mentions, IE7 when, as I've found out recently, going to a 2.x jQuery release will break IE8 functionality which is still used within organizations either as the actual browser or through compatibility mode. I didn't care for the format of the page but do like the author's tone and points so far. I think a lot of the issues people have with jQuery is that (as the article mentions) it's become synonymous with Javascript and abstracts so many things that many people using it don't understand the underlying framework and functions. That and why include more resources if you don't really need to.
- jrochkind1 12y ago
  There is a lot of misconceptions here. There are two parallel tracks of JQuery maintained, with _identical functionality_, one which supports IE8 and less, one which doesn't. JQuery team is supporting both. If they don't behave identically, that's a bug. If you don't need IE8 or less support, you can use the smaller higher-performance JQuery that doesn't support IE8. If you do need IE8 or before you use the other variant. Your code remains identical either way. JQuery still supports IE8 and less, and has announced no plans to stop. A lot of people are confused about this, and it's made more confusing by their mistakes about version labelling. At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x (IE9 and above). There are identical parallel versions of each. 1.11.0 and 2.1.1 have identical functionality. Yes, this is super confusing, so going forward in the future, they will call the old-browser-compat variant "JQuery compat", and the no-old-browsers variant "JQuery", and version numbers will be sync'd. http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/ http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-genera... At present, the JQuery team is still committed to maintaining identical functionality in an old-browser-compat variant, and a newer no-old-browser variant, sync'd, for the indefinite future. And in fact they recommend the Compat version "for most web sites, since it provides the best compatibility for all website visitors." They could at some point in the future decide to stop doing so -- they have said they won't do so until usage of older browsers has dropped significantly.
  - atwebb 12y ago
    Thanks for the detailed response, that is clearly my mistake. I did an install from NuGet and went with 2.1.1 making an assumption that the latest build was the greatest build and not really doing a lot of research. On my end, it was a browser compatibility mode setting and a meta tag resolved the issue for just my site and is fine for the usecase.
johnwards 12y ago
Tickets to jQuery UK 2015 are on sale now! http://jqueryuk.com/2015/ http://jqueryuk.com/2015/ (Sorry ;)) In all seriousness I'd recommend watching Adam Sontag's keynote from jQuery UK 2014 which covers the "not needing" jQuery stuff http://vimeo.com/97723665 http://vimeo.com/97723665
bshimmin 12y ago
You can basically sum up this entire rather ridiculous site with "Yes, you don't need jQuery, you can just use the built-in methods, but using jQuery is generally more pleasant, more consistent, and involves less typing". One particularly egregious example from the site: $('#foo').removeClass('bold'); vs. document.getElementById('foo').className = document.getElementById('foo').className.replace(/^bold$/, ''); The author summarises this, helpfully: "As usual, more characters, but still easy without jQuery." Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.
- oneeyedpigeon 12y ago
  .classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.classList https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist http://caniuse.com/#feat=classlist
  - jhpriestley 12y ago
    `$(".foo").removeClass("bold")` becomes the wonderfully concise [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })
    - sfeng 12y ago
      This may seem anecdotal, but I can tell you from writing a lot of non-jQueryified code that with modern browsers, applying classes to dozens of elements dynamically can be an anti-pattern. 99% of the time, when doing something which previously would have required that, I can use a single class on a parent element.
praetorian84 12y ago
It's something you see a lot of, especially from non-frontend developers that don't really think twice about downloading an extra 80-90kb of JavaScript. I do find the support for events in JQuery quite convenient, especially for projects that still require IE8 support. Although if that's all you're using it for, there are probably better ways.
dangerlibrary 12y ago
The AJAX examples fall a little flat. Yes, .ajax is a wrapper, and it was written because the API for XMLHTTPRequest is needlessly complicated and verbose. If you're developing a single page application, you only load jquery once, then do the rest with AJAX calls for JSON and assets. It's worth the <100 KB on initial page load, at least for the projects I've worked on.
- jackmaney 12y ago
  Not to mention that if you're loading jQuery via a CDN, there's a good chance that your end user has it in their cache already.
pawelk 12y ago
Similar resource with many code snippets: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ and related HN thread: https://news.ycombinator.com/item?id=7152068 https://news.ycombinator.com/item?id=7152068
potch 12y ago
Here's a list of DOM bugs in browsers that jQuery works around: https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/preview?sle=true https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh... Pretty sure they're not all fixed, and this is just the ignorance du jour.
- psychometry 12y ago
  So many of the author's examples required different bits of code for different browsers. It's almost like they don't understand why people use jQuery and just chalk it up to ignorance when using a framework it's almost a necessity these days. It's this stupid "you're not a real developer unless you're twiddling bits on your hard drive with a magnet" mentality that I absolutely despise.
  - icantthinkofone 12y ago
    It's a page and a half of mostly IE bugs. You should know your bugs and not try to cover them up but, more troubling that you don't want to know these things. Programmers I know want to write code, especially things as insignificant as these.
cezary 12y ago
Another great resource when trimming down jquery use is http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- terminado 12y ago
  ...and then, of course, there's: http://youmightnotnotneedjquery.com/ http://youmightnotnotneedjquery.com/ or https://gist.github.com/rwaldron/8720084#file-reasons-md https://gist.github.com/rwaldron/8720084#file-reasons-md (discussion: https://news.ycombinator.com/item?id=7153630 https://news.ycombinator.com/item?id=7153630)
contactmatts 12y ago
When I first read this post, I thought the link may be to this website: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ . I developed a Cordova application recently, and I only needed jQuery for Bootstrap. All custom JS was able to be done using the DOM API. However, I was spoiled since I only had to develop against a recent webkit version (my target was iOS 7)
- felipesabino 12y ago
  I had the same feeling when started working with angular, were you don't need jQuery or anything else to manipulate the DOM. It is spoiled, I agree, but it feels good to be "free" :p
bstrom 12y ago
Lots of blanket statements in this article. He asserts there is a 'proper' order to learning JavaScript but makes no demonstration of that assertion. For me, jQuery was a gateway that hid much of the incidental complexity of working with a byzantine API (the dom). That was incredibly useful. If every beginner started with trying to understand the DOM, they'd probably be scared off (and rightly so).
- icantthinkofone 12y ago
  What you call Byzantine, I call normal. Some things are harder to learn than others but you can't throw your hands up in the air and let someone else (jQuery) do the simple things for you. Working with the DOM is what we programmers do. I've never seen so many people complain so much about programming than those who use jQuery.
  - bstrom 12y ago
    The DOM strikes as being composed of layers of incidental complexity that get in the way of the actual problem you're trying to solve. jQuery, or abstractions like it, allow us to compose more elegant and semantically meaningful solutions to problems. If writing boilerplate is interesting for some reason, be it for performance reasons perhaps, then by all means. I find it a bit tedious and appreciate tools that allow me to focus on the problems at hand, rather than obscure browser differences and internal API implementation inconsistencies.
leeoniya 12y ago
for those interested in a lighter jquery, most features and same api there are these alternatives: https://github.com/kenwheeler/cash https://github.com/kenwheeler/cash https://github.com/finom/balalaika https://github.com/finom/balalaika
- nightwolf 12y ago
  Also Zepto: http://zeptojs.com/ http://zeptojs.com/
whoisthemachine 12y ago
I also don't need a calculator but I regularly use one to do even simple arithmetic operations, because it speeds up the operation and guarantees a certain result with given inputs. The purpose of an SDK such as jQuery is to help a developer do common tasks without needing to write his own library. If it's used widely in the industry then even better. If it's open source, even more betterer.
corwinstephen 12y ago
This guy's argument is strikingly similar to that of the one made by those people who are anti-Apple, despite the fact that working with Apple products is a commonly pleasant experience, simply for the fact that they're Apple. Just because a lot of people use something that they're not being forced to use doesn't necessarily mean that they've been "tricked" into doing so.
- icantthinkofone 12y ago
  Using Apple products is a pleasant experience. Using jQuery is to avoid learning how to code while purporting that it makes things easier cross browser. Of course, if that were the real reason, we would also have cQuery and c++Query and so on but, instead, we just learn how to code.
  - recursive 12y ago
    In your c and c++ analogies, what are the inconsistent DOM API implementations?
    - Nullabillity 12y ago
      Well, to be fair, the APIs aren't very consistent between OSes. But then again, I guess Java is the jQuery of C++. :P
  - justinpaulson 12y ago
    Yeah, and for that matter, why are we writing C anyway when we could just write everything in assembly? Lazy!
jon_kuperman 12y ago
http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
lolwhat 12y ago
Yeah, you don't need anything. You can write all your apps in vanilla JS, but if you feel like speeding up development...
- walshemj 12y ago
  and slowing down your website
  - pizzasynthesis 12y ago
    jQuery is usually cached in your browser because of how common it is. From what I understand, the slowing is negligible. Part of a developer's role is to mitigate site performance with the speed of process. Inlining of critical CSS is one way to balance out initial page load, for example.
    - icantthinkofone 12y ago
      This is part myth. The chances your site has the same version of jQuery that the visitor's browser cache is are pretty low. iirc, someone once said it was less than 5%.
      - lolwhat 12y ago
        most of the time, it's less than 1% http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
  - lolwhat 12y ago
    well that's the trade-off, isn't it? unless my app is speed-heavy, i'm not gonna spend the extra man-hours needed (that jquery saves me) so that website runs negligibly faster.
    - walshemj 12y ago
      good luck ranking in google and explaining your self to your md when your major publishing site takes 20 seconds to load I wont mention any names but I know of two cases of this.
bbcbasic 12y ago
There is a case to not use JQuery: When you really don't need it. I.e. you have one call to JQuery and it can easily be done natively. Then by removing JQuery you make the page download and load faster. If you are using just the basic JQuery features you could consider Zepto instead, so a smaller download but still giving you the abstraction you desire.
hcarvalhoalves 12y ago
Right off the bat, on the first 3 examples, he shows how you need to use different APIs depending on the IE version. That alone is enough reason to use jQuery and not having to bother.
- icantthinkofone 12y ago
  You're pointing out an IE problem, not a javascript problem that isn't present in other browsers.
  - gurraman 12y ago
    It's a developer's problem.
  - squeaky-clean 12y ago
    And your point is? Pointing the blame at a different source doesn't mean the problem isn't present. If a client needs IE support, what do you do? Write the code three times? Detect IE and redirect the user to chrome-frame, then cry when you don't get paid? I don't care who caused the problem. Just that it wasn't me, I can't fix it, and I have a deadline to meet and constraints to follow. jQuery is a lifesaver.
    - Zarel 12y ago
      Chrome Frame is no longer supported. :(
  - deleted 12y ago
    [deleted]
jrochkind1 12y ago
The tutorial in how to do things without JQuery is actually hugely useful to me. I have been considering a project where for various reasons it would be much better to avoid JQuery, and I realized that I had no idea how to do some common things without JQuery. This is a well-organized guide. It would be even better if he took out the three sentences after every section that just say, over and over again, "So why would you use JQuery, isn't this just as good?" Who cares, sometimes I agree sometimes I don't, and the boilerplate argument repeated over and over sounds whiny and gets in the way of the actual useful information OP has to impart. If you have your own external reasons to consider doing without JQuery (as I do), then an _honest_ assessment of where you are likely to have the most trouble would be more useful, than just repeating "Really, you're an idiot if you think you need JQuery" over and over again. Still, useful documentation, thanks.
mariusmg 12y ago
You sooooo do need jQuery if your web apps needs to run on as many browser/versions as possible.
- teknologist 12y ago
  I'd like to see the IE 7/8 versions of these snippets on the site in the OP. Wouldn't be so concise then, eh?
ggonweb 12y ago
Higher level abstractions, are not required if you plan to write your code in assembly. Lets go for it.
rip747 12y ago
rule of thumb: if you don't think you need to use jQuery, use jQuery anyways.
hnriot 12y ago
I do need JQuery because I want to focus on the application and not nuances of different js implementations. And I want to use the simple selector mechanisms. Then there's plugins, I use those too and many assume/require JQuery. So no, I disagree. Stupid article.
- todd3834 12y ago
  The article is controversial but it is definitely not stupid.
- iopq 12y ago
  If you spent any time trying to get your website to load in under 1 second, removing jquery plugins is the first thing you do. Not only do you have to load the jquery, you need to load the plugins after you already have jquery which makes it even slower.
todd3834 12y ago
You might not need jQuery but I much prefer jQuery's ajax API to using the XMLHttpRequest
cwbrandsma 12y ago
Next up: you don't need Underscore/Lodash! Forget this "you don't need JQuery"...JQuery, the entire library, is basically an API bug report against the DOM! What browsers need to start doing is get off their butts and start implementing a real selector implementation like Sizzle. Reduce JQuery to set of polyfils after that. As for IE7 support. Sorry that still accounts for too much of my traffic to ignore.
- mcintyre1994 12y ago
  Are you aware of QuerySelectorAll? I think Sizzle does more but I expect internally most of it delegates to that when available by now - it should support all CSS selectors. https://developer.mozilla.org/en/docs/Web/API/Document.querySelectorAll https://developer.mozilla.org/en/docs/Web/API/Document.query...
lostInComm 12y ago
This is a bunch of drivel. Anyone who knows their ass from a hole in the ground knows there are functions that back jQuery. jQuery just wraps in a nice, easy-to-use solution.
andrezsanchez 12y ago
Imperative DOM manipulation is a pain one way or another. React does a great job of alleviating this pain by allowing for declarative DOM manipulation, but it would be great to be able to do this without needing the rest of React.
- grosskur 12y ago
  You might be interested in the virtual-dom and vdom-thunk NPM packages, which are used in mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury See also Raynos's "NPM-style Frontend" presentation: https://www.youtube.com/watch?v=8w0_Xw7PPFQ https://www.youtube.com/watch?v=8w0_Xw7PPFQ
sleek 12y ago
Swing and a miss
rip747 12y ago
Actually I think the biggest reason to use jQuery is the plugin ecosystem. Think about it... if you want to do _anything_ there is a jQuery plugin already written to do it.
martin-adams 12y ago
Articles like this make me thankful that I've done my 10,000 hours of web development learning the ins and outs of the DOM and it's interactions with JavaScript (mostly topics covered in Crockford's book). Admittedly, about 9,950 of those hours were making it work in IE6. jQuery is a framework, like many others. Programming is not about learning frameworks, it's about learning the language, it's runtime behaviours and of course software development in general. Frameworks are there to speed up development time.
- teknologist 12y ago
  after 10,000 hours you're still calling jQuery a framework?
  - martin-adams 12y ago
    replace(/framework/ig, 'library') better?
    - teknologist 12y ago
      ☺
sebnukem2 12y ago
You Don't Need JQuery if your time is worthless, and don't mind spending 20x the amount of time to make your stuff almost work on IE.
serve_yay 12y ago
I'm getting very tired of people realizing that browsers now ship with `document.querySelectorAll` and saying that means you don't need jQuery anymore.
andy_ppp 12y ago
Guaranteed stable, well known, monolithic blob or write something yourself that fits your needs perfectly. Fear or Love on the web developer scale of needs.
caoglish 12y ago
You don't need jQuery if you have written better wrapped API library and have already attracted millions of developer to test your library. For the eco-system point of view, jQuery have been tested in the widest markets for many many years. well written document, many online cases, many supporters, many bug reporters, high cover unit tests,good code quality and so on. Using jQuery for project is smart move unless high performance requirement.
jbeja 12y ago
You don't need jQuery if you don't care about ie-9 (which I don't)
dpweb 12y ago
This and you're good for selectors, but there's no right or wrong answer - use what works for you and the project. $ = document.querySelector.bind(document); $$ = document.querySelectorAll.bind(document);
vijayboyapati 12y ago
https://plus.google.com/110888393967521869195/posts/4REjUe5aXGr https://plus.google.com/110888393967521869195/posts/4REjUe5a... #humor
codingdave 12y ago
I don't need power steering or an automatic transmission in my car either. And I don't need a garage door opener or a microwave. I don't need a wifi router... I can hard-wire my whole home. There are many things in this life that I do not NEED, but that make life easy. jQuery fits into this same category.
keeran 12y ago
I thought it was a joke site, I scanned the first example and saw the single jQuery way of doing something followed by n other ways depending on the browser / IE level.
nathan_f77 12y ago
I disagree, jQuery is awesome, even for seasoned web developers. Of course you don't need it, but it makes life a lot easier when working with XHR, events, selectors, etc. If you're worried about dependencies, you could just compile your released library with the Google Closure compile, and strip out everything you don't use. You could even set up a pipeline to produce two releases: one that has bits of jQuery embedded, and a smaller one that requires jQuery. EDIT: Thanks to dmethvin [1], I just learned that you can also build your own jQuery [2] that only includes the modules you need. [1] https://news.ycombinator.com/item?id=8760352 https://news.ycombinator.com/item?id=8760352 [2] https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules
- bjourne 12y ago
  It's better to just use one of the jquery versions hosted on the google developer cdn: https://developers.google.com/speed/libraries/devguide https://developers.google.com/speed/libraries/devguide If you link to a popular jquery version, I bet the odds of the user already having the library cached is approaching 95%+ so your dependency is essentially free as no requests will be made in that case.
  - LocalPCGuy 12y ago
    The odds approach 1.7%. http://www.i-technology.net/2013/11/the-myth-of-cdn.html http://www.i-technology.net/2013/11/the-myth-of-cdn.html more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
bb0wn 12y ago
The best thing about jQuery is that it abstracts away most of the browser-specific quirkiness for you. Using jQuery for that feature alone makes it worth using.
elchief 12y ago
Oh noes! An 83KB download, which is probably already in the browser's cache, on your site that is 1MB per request.
deleted 12y ago
[deleted]
IkmoIkmo 12y ago
Who needs an operating system if you can write your own? Then you might as well write a browser, and develop a web language for it, and then you can write your own jQuery type library in that language. Because, why not, you don't NEED to use all these excellent tools already available for which I provide no reason not to actually use them. I'm just saying, you don't need them.
hit8run 12y ago
I started to use Angular instead of jQuery. It comes with jqlite and a lot of the stuff I would use jQuery for (e.g. form validation) can still be easily done.
- hit8run 12y ago
  Why do I get a downvote for this? Angular 1.2 weights around 108kb and jQuery around 1.11 around 96kb and one gets a whole lot of extra functionality with angular if you use its strenghts correctly.
joshstrange 12y ago
If we've heard this argument once we've heard it a million times. Of course you don't need jQuery but unless you are writing an internal-only app and plan on writing everything from the ground up (all your auto-completes, multi-selects, etc) then you do need jQuery. I am not a fan of a lot of the code that I've seen written with jQuery but jQuery itself is not evil anymore than PHP is evil because people do stupid stuff with it. If you use jQuery correctly it is an invaluable tool that makes your like 100x easier. Event handling alone, I want to puke when I see the default way to do this, way too much typing, way too verbose. If I had to write that multiple times a day then I would probably create a helper function to abstract it away and I'd be on my way to building my own jQuery. No thank you, I'll take the one that's battle-tested and maintained. I'm getting sick of seeing this argument, if you work in a bubble then sure, be my guest (I'll be laughing at all the extra typing you will be doing) but if you plan on deploying your code to the real world? Just use jQuery and save yourself a headache.
allenguo 12y ago
Relevant: http://vanilla-js.com/ http://vanilla-js.com/.
diltonm 12y ago
>> In fact, this is completely unneccsary with the existence of forEach and Object.keys() (both available in IE9+). Oh the eyes of Microsoft shine gracefully upon us, we are so blessed. First, get a spell checker. Second, abandon jQuery at you peril. Browser makers should be required to embed jQuery. jQuery makes JavaScript almost bearable to deal with. That says a lot.
- deleted 12y ago
  [deleted]
drikerf 12y ago
Too bad lot's of libraries like bootstrap depend on it. Btw, published some time ago http://youmightnotneedjquery.com http://youmightnotneedjquery.com sums it up well and a good reference for jquery people.
drivingmenuts 12y ago
No, I don't need jQuery, but memory really isn't that much of an issue anymore and convenience wins over bandwidth.
malandrew 12y ago
"This is your reminder that the DOM is actually a giant, mutable, global variable in the middle of your program. Act accordingly." –Marco Rogers (@polotek) https://twitter.com/polotek/status/543590973846999040 https://twitter.com/polotek/status/543590973846999040
Morphling 12y ago
I guess if you are super optimizing your website then getting rid of all the useless stuff is fine, but at least I don't notice big enough performance increase to get rid of jQuery even if it's just for the $('selector').
olla 12y ago
Lately everything I build with jQuery I will eventually regret it. The first most annoying problem is that events triggered in jQuery cannot be seen by other modules correctly. Even not by another jQuery instance. There is also the usual size problem, when writing reusable code. For example whenever I want to reuse some 100 lines of code on another project I will have to add almost 100kb of jQuery to make it work. Working also on some bigger everlasting projects, like the wysihtml.com editor, has shown that when you need to patch some browser misbehaviours, native javascript is the only way to go. Such patches need to be as close to their error source as possible.
PSeitz 12y ago
An if you care for performance, you shouldn't use jquery. It is very slow: http://stackoverflow.com/questions/11503534/jquery-vs-document-queryselectorall/21539115#21539115 http://stackoverflow.com/questions/11503534/jquery-vs-docume...
- radio4fan 12y ago
  But if you care about programmer productivity, you use jQuery, then you profile, then you optimise where required. The last step isn't usually necessary.
  - PSeitz 12y ago
    I would rather choose something else for productivity.
deleted 12y ago
[deleted]
steve0341 12y ago
So why reinvent the wheel? Rename title to "Dom manipulation can be done without Jquery, but use what works for you!"
bwindels 12y ago
I don't mind using a library for dom manipulation, or for xhr, or for missing ES5 function ... My problem with jquery is that it does all of it, in a very entangled way. This makes it very tempting to mix parts of your application that really shouldn't know about each other (like dom manipulation (UI) and XHR (IO)). I prefer to use a dedicated library for all of those things and to hide the fact that I am using a particular library to the rest of the application. I've seen standardising on one true huge library throughout an application gone wrong several times and it's very hard to refactor your way out of it.
teknologist 12y ago
Doing ajax without jQuery is also good fun var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState === 4) { callback(JSON.parse(xhr.responseText)); } }; xhr.open('POST', url, true); xhr.setRequestHeader('Content-Type', 'application/json'); xhr.send(JSON.stringify(data)); And that's not taking care of errors, edge cases or Internet Explorer at all. In jQuery: $.post(url, data)
collyw 12y ago
Except, being old school, I remember 7 or 8 years ago, when everyone would complain about IE compatibility and various quirks between browsers. JQuery apparently sorted all of that out. And now we should go back to the bad old ways?
teknologist 12y ago
jQuery should be pre-JIT-compiled in browsers. performance problem solved.
grahamel 12y ago
Everytime I see one of these I think I should do more with https://news.ycombinator.com/item?id=7863271 https://news.ycombinator.com/item?id=7863271 Yes it's useful to know what jQuery is doing underneath but the whole point of it is that you don't have to worry about that and can concentrate on on the rest of your build. Sure, you might not need it and there are other alternatives, both as plain JS and with other libraries, but it does it's job well and will always be easier for others to pick up when coming onto a project.
pjmlp 12y ago
Of course you don't need jQuery, if your customers are happy that you target only one browser specific version. I think the rest of us will rather keep on using it, or similar library.
lfottaviano 12y ago
Don't be bad, look the positive of this site, it teachs us jquery
ponyous 12y ago
My Argument is that you don't need jQuery but you definitely need some kind of library to avoid most common time-consuming tasks.
alxndr 12y ago
A couple days after this was posted to HN, the release of jQuery 1.11.2 and 2.1.3 offers an example of why you might want jQuery even if you might not need it. http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/ http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-re... > "A bug like this one emphasizes the benefit of using a library like jQuery rather than going directly to the DOM APIs."

240 points by rnicholus 12y ago

deleted 12y ago

[deleted]

Every time I try to build something without jQuery, I regret it. Not because of selectors, that's (sometimes) easy to do for lots of (basic) selectors. Not because of DOM manipulation, as long as you're willing to sacrifice simplicity and readability, you can build iterative loops to modify a collection of HTML elements. No, it's the unexpected things that cause me pain. Want to use event handlers on dynamically generated DOM objects? Write your own event bubbling library. Want to create custom events/handlers? Ditto. Promises, .serialize(), .extend(), etc. might all be simple to write your own version, but when you realize you've reimplemented 50% of jQuery to avoid using jQuery, you feel like an idiot. [Source: I do this every 3 years] Life is too short to not use jQuery.

sfeng 12y ago
There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does. Real bundling with tools like Browserify is making it more and more feasible to use single-purpose libraries instead of monolithic ones like jQuery.
- random28345 12y ago
  > There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does. I agree with all those things. jQuery is the lowest common denominator. It's the best at nothing, bloated with support for Palm Pilot browsers and Safari 1.0, and doesn't have all the cool grunt/gulp/amd/broccoli/cucumber/jsx/fotm neologisms. If I'm building a new, long-term project, I'm going to evaluate all the options, and craft the best possible technology stack for my new app. But sometimes worse is better. Like a smooth pebble pulled out of a stream, it's taken a long journey and had most of the rough edges rubbed off. It's already in your browser cache from 4 different CDNs. Someone else can pick it up and support it easily. And that's what often makes it the best choice, when you want to avoid bikeshedding over what the hottest new thing is, and just make a webpage. jQuery may not be the best technology, but it's a sane default.
- bombtrack 12y ago
  I'm sure you're aware of this, but for others who may not know: the 2.x versions of jQuery dropped support for old browsers (IE 6, 7, 8) to reduce size (12% smaller) and complexity necessitated by being so backwards-compatible [0]. Thankfully we only support IE9+ where I work, so I grab the latest 2.x version these days. [0] - http://blog.jquery.com/2013/04/18/jquery-2-0-released/ http://blog.jquery.com/2013/04/18/jquery-2-0-released/
- wvenable 12y ago
  The thing is there's always other libraries that provide better implementations of things. Likely the instant you pick one, there will be something "better". jQuery has the benefit of being as much of a standard library for the web as anything else. Often it's not worth the time and effort to hunt down the absolute perfect combination of libraries to accomplish the same thing.
Youpinadi 12y ago
Agreed 1000%
NDizzle 12y ago
Yep. Use the built in browser methods? For which browser?!? All of them? I have to support some enterprise guys on IE8, sometimes I'm lucky to have them on IE9. Life isn't always a hipster website where people can get lunch delivered on their phone or whatever. Things like jQuery are fine.
- pjmlp 12y ago
  Fully agree with you, it is worse actually as even between versions of a specific browser, behaviors change.
williamcotton 12y ago
Life is definitely too short to not be using npm, browserify and React! https://www.npmjs.com/package/browserify https://www.npmjs.com/package/browserify https://www.npmjs.com/package/react https://www.npmjs.com/package/react And then use just what modules you need. All the functionality of jQuery has already been ported to various modules. https://www.npmjs.com/package/extend https://www.npmjs.com/package/extend https://www.npmjs.com/package/promise https://www.npmjs.com/package/promise https://www.npmjs.com/package/serialize-form https://www.npmjs.com/package/serialize-form
- random28345 12y ago
  > Life is definitely too short to not be using npm, browserify and React! These are all cool things, but sometimes you want to simply make a web page without setting up node and npm and all that jazz. Think of it this way... jQuery is like getting a subset of the most common functions you get by using in browserify, but without requiring a build step!
  - klibertp 12y ago
    > sometimes you want to simply make a web page without setting up node and npm and all that jazz No, absolutely impossible. That would mean I'd have to actually write JavaScript instead of LiveScript and that would be unbearable... ;) On a more serious note: yes, node is a bit of an overhead. It may be too much for very simple, one-off projects, but it starts making sense as soon as the project becomes even a little bit more complex.
  - williamcotton 12y ago
    This is about more than just a build process. jQuery's imperative DOM manipulation is a horrible way to manage state compared to React. These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approach to system design. A build process that integrates with a versioned package manager is fantastic.
Pxtl 12y ago
Yeah, the problem with jQuery is all that other stuff that nobody uses and backwards compatibility with browsers nobody supports. A "lite" jQuery with the same familiar API but a stripped-down featureset for higher performance and smaller size would be nice.
- K-Wall 12y ago
  Zepto might be what you are looking for. http://zeptojs.com/ http://zeptojs.com/
- abritishguy 12y ago
  Just use the CDN copy of jquery and it will be cached in the users browser already since so many websites already use it.
  - LocalPCGuy 12y ago
    Not really, the cache-hit benefit is a myth. Too many CDNs, too many versions of jQuery in use, cache's too small... So ..using jQuery via a CDN, depending on which you use you have a 1 in 119, or 1 in 833 chance of the user having a cached copy. http://www.i-technology.net/2013/11/the-myth-of-cdn.html http://www.i-technology.net/2013/11/the-myth-of-cdn.html more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... There are valid reasons to use a CDN (get the scripts closer to the end user, offload the data transfer costs to the CDN provider, etc) but it isn't due to the potential for a cache hit.
    - chdir 12y ago
      > you have a 1 in 119, or 1 in 833 chance of the user having a cached copy That statistics has assumptions on what's the most popular jQuery versions being used. It would make sense if there was real data to support that.
- dmethvin 12y ago
  You're aware of jQuery custom builds? Leave out what you don't use. It's in the README file.
kaonashi 12y ago
React handles event normalization, fyi.
klibertp 12y ago
You can "eat the cake and have it too" with something like this: http://microjs.com/ http://microjs.com/ Basically you import everything you need and only what you need. Need extend? No prob: http://microjs.com/#extend http://microjs.com/#extend - just pick one. And with browserify and npm literally everything you need to do to include a library in your project is a single command, so having to include "that many libraries" is not really a problem. I'm a huge fan of having many little libraries instead of a few big ones, and JS - both on the backend and frontend - makes this possible to the bigger extent than most other environments.
- girvo 12y ago
  Same. Between Micro JS, Vue.js and Browserify, I can craft the perfect tech stack with best-of-breed libraries, and come out with a much smaller, faster, and less janky site at the end of it. Oh, and being CommonJS modules via Browserify makes life pretty great, and my code maintainable and easy to follow!
icantthinkofone 12y ago
I've only used jQuery once, for a client who insisted we use it, and it was the worst experience of my company's life. It only made us use bold on all our documents which proudly states, "No JQuery!".
- _mtr 12y ago
  Surely you can expand on this story. What made using jQuery so painful?
  - mkhalil 12y ago
    I'll try. My client was mad I was trying to charge him an extra $6000 for the time I spend to get the stuff I write to work across different browsers and asked me to use jQuery instead.
    - deleted 12y ago
      [deleted]
agumonkey 12y ago
greenspuns-tenth-rule.js

atwebb 12y ago

Still reading through but it mentions, IE7 when, as I've found out recently, going to a 2.x jQuery release will break IE8 functionality which is still used within organizations either as the actual browser or through compatibility mode. I didn't care for the format of the page but do like the author's tone and points so far. I think a lot of the issues people have with jQuery is that (as the article mentions) it's become synonymous with Javascript and abstracts so many things that many people using it don't understand the underlying framework and functions. That and why include more resources if you don't really need to.

jrochkind1 12y ago
There is a lot of misconceptions here. There are two parallel tracks of JQuery maintained, with _identical functionality_, one which supports IE8 and less, one which doesn't. JQuery team is supporting both. If they don't behave identically, that's a bug. If you don't need IE8 or less support, you can use the smaller higher-performance JQuery that doesn't support IE8. If you do need IE8 or before you use the other variant. Your code remains identical either way. JQuery still supports IE8 and less, and has announced no plans to stop. A lot of people are confused about this, and it's made more confusing by their mistakes about version labelling. At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x (IE9 and above). There are identical parallel versions of each. 1.11.0 and 2.1.1 have identical functionality. Yes, this is super confusing, so going forward in the future, they will call the old-browser-compat variant "JQuery compat", and the no-old-browsers variant "JQuery", and version numbers will be sync'd. http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/ http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-genera... At present, the JQuery team is still committed to maintaining identical functionality in an old-browser-compat variant, and a newer no-old-browser variant, sync'd, for the indefinite future. And in fact they recommend the Compat version "for most web sites, since it provides the best compatibility for all website visitors." They could at some point in the future decide to stop doing so -- they have said they won't do so until usage of older browsers has dropped significantly.
- atwebb 12y ago
  Thanks for the detailed response, that is clearly my mistake. I did an install from NuGet and went with 2.1.1 making an assumption that the latest build was the greatest build and not really doing a lot of research. On my end, it was a browser compatibility mode setting and a meta tag resolved the issue for just my site and is fine for the usecase.

johnwards 12y ago

Tickets to jQuery UK 2015 are on sale now! http://jqueryuk.com/2015/ http://jqueryuk.com/2015/ (Sorry ;)) In all seriousness I'd recommend watching Adam Sontag's keynote from jQuery UK 2014 which covers the "not needing" jQuery stuff http://vimeo.com/97723665 http://vimeo.com/97723665

bshimmin 12y ago

You can basically sum up this entire rather ridiculous site with "Yes, you don't need jQuery, you can just use the built-in methods, but using jQuery is generally more pleasant, more consistent, and involves less typing". One particularly egregious example from the site: $('#foo').removeClass('bold'); vs. document.getElementById('foo').className = document.getElementById('foo').className.replace(/^bold$/, ''); The author summarises this, helpfully: "As usual, more characters, but still easy without jQuery." Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.

oneeyedpigeon 12y ago
.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.classList https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist http://caniuse.com/#feat=classlist
- jhpriestley 12y ago
  `$(".foo").removeClass("bold")` becomes the wonderfully concise [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })
  - sfeng 12y ago
    This may seem anecdotal, but I can tell you from writing a lot of non-jQueryified code that with modern browsers, applying classes to dozens of elements dynamically can be an anti-pattern. 99% of the time, when doing something which previously would have required that, I can use a single class on a parent element.

praetorian84 12y ago

It's something you see a lot of, especially from non-frontend developers that don't really think twice about downloading an extra 80-90kb of JavaScript. I do find the support for events in JQuery quite convenient, especially for projects that still require IE8 support. Although if that's all you're using it for, there are probably better ways.

dangerlibrary 12y ago

The AJAX examples fall a little flat. Yes, .ajax is a wrapper, and it was written because the API for XMLHTTPRequest is needlessly complicated and verbose. If you're developing a single page application, you only load jquery once, then do the rest with AJAX calls for JSON and assets. It's worth the <100 KB on initial page load, at least for the projects I've worked on.

jackmaney 12y ago
Not to mention that if you're loading jQuery via a CDN, there's a good chance that your end user has it in their cache already.

pawelk 12y ago

Similar resource with many code snippets: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ and related HN thread: https://news.ycombinator.com/item?id=7152068 https://news.ycombinator.com/item?id=7152068

potch 12y ago

Here's a list of DOM bugs in browsers that jQuery works around: https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/preview?sle=true https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh... Pretty sure they're not all fixed, and this is just the ignorance du jour.

psychometry 12y ago
So many of the author's examples required different bits of code for different browsers. It's almost like they don't understand why people use jQuery and just chalk it up to ignorance when using a framework it's almost a necessity these days. It's this stupid "you're not a real developer unless you're twiddling bits on your hard drive with a magnet" mentality that I absolutely despise.
- icantthinkofone 12y ago
  It's a page and a half of mostly IE bugs. You should know your bugs and not try to cover them up but, more troubling that you don't want to know these things. Programmers I know want to write code, especially things as insignificant as these.

cezary 12y ago

Another great resource when trimming down jquery use is http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

terminado 12y ago
...and then, of course, there's: http://youmightnotnotneedjquery.com/ http://youmightnotnotneedjquery.com/ or https://gist.github.com/rwaldron/8720084#file-reasons-md https://gist.github.com/rwaldron/8720084#file-reasons-md (discussion: https://news.ycombinator.com/item?id=7153630 https://news.ycombinator.com/item?id=7153630)

contactmatts 12y ago

When I first read this post, I thought the link may be to this website: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ . I developed a Cordova application recently, and I only needed jQuery for Bootstrap. All custom JS was able to be done using the DOM API. However, I was spoiled since I only had to develop against a recent webkit version (my target was iOS 7)

felipesabino 12y ago
I had the same feeling when started working with angular, were you don't need jQuery or anything else to manipulate the DOM. It is spoiled, I agree, but it feels good to be "free" :p

bstrom 12y ago

Lots of blanket statements in this article. He asserts there is a 'proper' order to learning JavaScript but makes no demonstration of that assertion. For me, jQuery was a gateway that hid much of the incidental complexity of working with a byzantine API (the dom). That was incredibly useful. If every beginner started with trying to understand the DOM, they'd probably be scared off (and rightly so).

icantthinkofone 12y ago
What you call Byzantine, I call normal. Some things are harder to learn than others but you can't throw your hands up in the air and let someone else (jQuery) do the simple things for you. Working with the DOM is what we programmers do. I've never seen so many people complain so much about programming than those who use jQuery.
- bstrom 12y ago
  The DOM strikes as being composed of layers of incidental complexity that get in the way of the actual problem you're trying to solve. jQuery, or abstractions like it, allow us to compose more elegant and semantically meaningful solutions to problems. If writing boilerplate is interesting for some reason, be it for performance reasons perhaps, then by all means. I find it a bit tedious and appreciate tools that allow me to focus on the problems at hand, rather than obscure browser differences and internal API implementation inconsistencies.

leeoniya 12y ago

for those interested in a lighter jquery, most features and same api there are these alternatives: https://github.com/kenwheeler/cash https://github.com/kenwheeler/cash https://github.com/finom/balalaika https://github.com/finom/balalaika

nightwolf 12y ago
Also Zepto: http://zeptojs.com/ http://zeptojs.com/

whoisthemachine 12y ago

I also don't need a calculator but I regularly use one to do even simple arithmetic operations, because it speeds up the operation and guarantees a certain result with given inputs. The purpose of an SDK such as jQuery is to help a developer do common tasks without needing to write his own library. If it's used widely in the industry then even better. If it's open source, even more betterer.

corwinstephen 12y ago

This guy's argument is strikingly similar to that of the one made by those people who are anti-Apple, despite the fact that working with Apple products is a commonly pleasant experience, simply for the fact that they're Apple. Just because a lot of people use something that they're not being forced to use doesn't necessarily mean that they've been "tricked" into doing so.

icantthinkofone 12y ago
Using Apple products is a pleasant experience. Using jQuery is to avoid learning how to code while purporting that it makes things easier cross browser. Of course, if that were the real reason, we would also have cQuery and c++Query and so on but, instead, we just learn how to code.
- recursive 12y ago
  In your c and c++ analogies, what are the inconsistent DOM API implementations?
  - Nullabillity 12y ago
    Well, to be fair, the APIs aren't very consistent between OSes. But then again, I guess Java is the jQuery of C++. :P
- justinpaulson 12y ago
  Yeah, and for that matter, why are we writing C anyway when we could just write everything in assembly? Lazy!

jon_kuperman 12y ago

http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

lolwhat 12y ago

Yeah, you don't need anything. You can write all your apps in vanilla JS, but if you feel like speeding up development...

walshemj 12y ago
and slowing down your website
- pizzasynthesis 12y ago
  jQuery is usually cached in your browser because of how common it is. From what I understand, the slowing is negligible. Part of a developer's role is to mitigate site performance with the speed of process. Inlining of critical CSS is one way to balance out initial page load, for example.
  - icantthinkofone 12y ago
    This is part myth. The chances your site has the same version of jQuery that the visitor's browser cache is are pretty low. iirc, someone once said it was less than 5%.
    - lolwhat 12y ago
      most of the time, it's less than 1% http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
- lolwhat 12y ago
  well that's the trade-off, isn't it? unless my app is speed-heavy, i'm not gonna spend the extra man-hours needed (that jquery saves me) so that website runs negligibly faster.
  - walshemj 12y ago
    good luck ranking in google and explaining your self to your md when your major publishing site takes 20 seconds to load I wont mention any names but I know of two cases of this.

bbcbasic 12y ago

There is a case to not use JQuery: When you really don't need it. I.e. you have one call to JQuery and it can easily be done natively. Then by removing JQuery you make the page download and load faster. If you are using just the basic JQuery features you could consider Zepto instead, so a smaller download but still giving you the abstraction you desire.

hcarvalhoalves 12y ago

Right off the bat, on the first 3 examples, he shows how you need to use different APIs depending on the IE version. That alone is enough reason to use jQuery and not having to bother.

icantthinkofone 12y ago
You're pointing out an IE problem, not a javascript problem that isn't present in other browsers.
- gurraman 12y ago
  It's a developer's problem.
- squeaky-clean 12y ago
  And your point is? Pointing the blame at a different source doesn't mean the problem isn't present. If a client needs IE support, what do you do? Write the code three times? Detect IE and redirect the user to chrome-frame, then cry when you don't get paid? I don't care who caused the problem. Just that it wasn't me, I can't fix it, and I have a deadline to meet and constraints to follow. jQuery is a lifesaver.
  - Zarel 12y ago
    Chrome Frame is no longer supported. :(
- deleted 12y ago
  [deleted]

jrochkind1 12y ago

The tutorial in how to do things without JQuery is actually hugely useful to me. I have been considering a project where for various reasons it would be much better to avoid JQuery, and I realized that I had no idea how to do some common things without JQuery. This is a well-organized guide. It would be even better if he took out the three sentences after every section that just say, over and over again, "So why would you use JQuery, isn't this just as good?" Who cares, sometimes I agree sometimes I don't, and the boilerplate argument repeated over and over sounds whiny and gets in the way of the actual useful information OP has to impart. If you have your own external reasons to consider doing without JQuery (as I do), then an _honest_ assessment of where you are likely to have the most trouble would be more useful, than just repeating "Really, you're an idiot if you think you need JQuery" over and over again. Still, useful documentation, thanks.

mariusmg 12y ago

You sooooo do need jQuery if your web apps needs to run on as many browser/versions as possible.

teknologist 12y ago
I'd like to see the IE 7/8 versions of these snippets on the site in the OP. Wouldn't be so concise then, eh?

ggonweb 12y ago

Higher level abstractions, are not required if you plan to write your code in assembly. Lets go for it.

rip747 12y ago

rule of thumb: if you don't think you need to use jQuery, use jQuery anyways.

hnriot 12y ago

I do need JQuery because I want to focus on the application and not nuances of different js implementations. And I want to use the simple selector mechanisms. Then there's plugins, I use those too and many assume/require JQuery. So no, I disagree. Stupid article.

todd3834 12y ago
The article is controversial but it is definitely not stupid.
iopq 12y ago
If you spent any time trying to get your website to load in under 1 second, removing jquery plugins is the first thing you do. Not only do you have to load the jquery, you need to load the plugins after you already have jquery which makes it even slower.

todd3834 12y ago

You might not need jQuery but I much prefer jQuery's ajax API to using the XMLHttpRequest

cwbrandsma 12y ago

Next up: you don't need Underscore/Lodash! Forget this "you don't need JQuery"...JQuery, the entire library, is basically an API bug report against the DOM! What browsers need to start doing is get off their butts and start implementing a real selector implementation like Sizzle. Reduce JQuery to set of polyfils after that. As for IE7 support. Sorry that still accounts for too much of my traffic to ignore.

mcintyre1994 12y ago
Are you aware of QuerySelectorAll? I think Sizzle does more but I expect internally most of it delegates to that when available by now - it should support all CSS selectors. https://developer.mozilla.org/en/docs/Web/API/Document.querySelectorAll https://developer.mozilla.org/en/docs/Web/API/Document.query...

lostInComm 12y ago

This is a bunch of drivel. Anyone who knows their ass from a hole in the ground knows there are functions that back jQuery. jQuery just wraps in a nice, easy-to-use solution.

andrezsanchez 12y ago

Imperative DOM manipulation is a pain one way or another. React does a great job of alleviating this pain by allowing for declarative DOM manipulation, but it would be great to be able to do this without needing the rest of React.

grosskur 12y ago
You might be interested in the virtual-dom and vdom-thunk NPM packages, which are used in mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury See also Raynos's "NPM-style Frontend" presentation: https://www.youtube.com/watch?v=8w0_Xw7PPFQ https://www.youtube.com/watch?v=8w0_Xw7PPFQ

sleek 12y ago

Swing and a miss

rip747 12y ago

Actually I think the biggest reason to use jQuery is the plugin ecosystem. Think about it... if you want to do _anything_ there is a jQuery plugin already written to do it.

martin-adams 12y ago

Articles like this make me thankful that I've done my 10,000 hours of web development learning the ins and outs of the DOM and it's interactions with JavaScript (mostly topics covered in Crockford's book). Admittedly, about 9,950 of those hours were making it work in IE6. jQuery is a framework, like many others. Programming is not about learning frameworks, it's about learning the language, it's runtime behaviours and of course software development in general. Frameworks are there to speed up development time.

teknologist 12y ago
after 10,000 hours you're still calling jQuery a framework?
- martin-adams 12y ago
  replace(/framework/ig, 'library') better?
  - teknologist 12y ago
    ☺

sebnukem2 12y ago

You Don't Need JQuery if your time is worthless, and don't mind spending 20x the amount of time to make your stuff almost work on IE.

serve_yay 12y ago

I'm getting very tired of people realizing that browsers now ship with `document.querySelectorAll` and saying that means you don't need jQuery anymore.

andy_ppp 12y ago

Guaranteed stable, well known, monolithic blob or write something yourself that fits your needs perfectly. Fear or Love on the web developer scale of needs.

caoglish 12y ago

You don't need jQuery if you have written better wrapped API library and have already attracted millions of developer to test your library. For the eco-system point of view, jQuery have been tested in the widest markets for many many years. well written document, many online cases, many supporters, many bug reporters, high cover unit tests,good code quality and so on. Using jQuery for project is smart move unless high performance requirement.

jbeja 12y ago

You don't need jQuery if you don't care about ie-9 (which I don't)

dpweb 12y ago

This and you're good for selectors, but there's no right or wrong answer - use what works for you and the project. $ = document.querySelector.bind(document); $$ = document.querySelectorAll.bind(document);

vijayboyapati 12y ago

https://plus.google.com/110888393967521869195/posts/4REjUe5aXGr https://plus.google.com/110888393967521869195/posts/4REjUe5a... #humor

codingdave 12y ago

I don't need power steering or an automatic transmission in my car either. And I don't need a garage door opener or a microwave. I don't need a wifi router... I can hard-wire my whole home. There are many things in this life that I do not NEED, but that make life easy. jQuery fits into this same category.

keeran 12y ago

I thought it was a joke site, I scanned the first example and saw the single jQuery way of doing something followed by n other ways depending on the browser / IE level.

nathan_f77 12y ago

I disagree, jQuery is awesome, even for seasoned web developers. Of course you don't need it, but it makes life a lot easier when working with XHR, events, selectors, etc. If you're worried about dependencies, you could just compile your released library with the Google Closure compile, and strip out everything you don't use. You could even set up a pipeline to produce two releases: one that has bits of jQuery embedded, and a smaller one that requires jQuery. EDIT: Thanks to dmethvin [1], I just learned that you can also build your own jQuery [2] that only includes the modules you need. [1] https://news.ycombinator.com/item?id=8760352 https://news.ycombinator.com/item?id=8760352 [2] https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules

bjourne 12y ago
It's better to just use one of the jquery versions hosted on the google developer cdn: https://developers.google.com/speed/libraries/devguide https://developers.google.com/speed/libraries/devguide If you link to a popular jquery version, I bet the odds of the user already having the library cached is approaching 95%+ so your dependency is essentially free as no requests will be made in that case.
- LocalPCGuy 12y ago
  The odds approach 1.7%. http://www.i-technology.net/2013/11/the-myth-of-cdn.html http://www.i-technology.net/2013/11/the-myth-of-cdn.html more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

bb0wn 12y ago

The best thing about jQuery is that it abstracts away most of the browser-specific quirkiness for you. Using jQuery for that feature alone makes it worth using.

elchief 12y ago

Oh noes! An 83KB download, which is probably already in the browser's cache, on your site that is 1MB per request.

deleted 12y ago

[deleted]

IkmoIkmo 12y ago

Who needs an operating system if you can write your own? Then you might as well write a browser, and develop a web language for it, and then you can write your own jQuery type library in that language. Because, why not, you don't NEED to use all these excellent tools already available for which I provide no reason not to actually use them. I'm just saying, you don't need them.

hit8run 12y ago

I started to use Angular instead of jQuery. It comes with jqlite and a lot of the stuff I would use jQuery for (e.g. form validation) can still be easily done.

hit8run 12y ago
Why do I get a downvote for this? Angular 1.2 weights around 108kb and jQuery around 1.11 around 96kb and one gets a whole lot of extra functionality with angular if you use its strenghts correctly.

joshstrange 12y ago

If we've heard this argument once we've heard it a million times. Of course you don't need jQuery but unless you are writing an internal-only app and plan on writing everything from the ground up (all your auto-completes, multi-selects, etc) then you do need jQuery. I am not a fan of a lot of the code that I've seen written with jQuery but jQuery itself is not evil anymore than PHP is evil because people do stupid stuff with it. If you use jQuery correctly it is an invaluable tool that makes your like 100x easier. Event handling alone, I want to puke when I see the default way to do this, way too much typing, way too verbose. If I had to write that multiple times a day then I would probably create a helper function to abstract it away and I'd be on my way to building my own jQuery. No thank you, I'll take the one that's battle-tested and maintained. I'm getting sick of seeing this argument, if you work in a bubble then sure, be my guest (I'll be laughing at all the extra typing you will be doing) but if you plan on deploying your code to the real world? Just use jQuery and save yourself a headache.

allenguo 12y ago

Relevant: http://vanilla-js.com/ http://vanilla-js.com/.

diltonm 12y ago

>> In fact, this is completely unneccsary with the existence of forEach and Object.keys() (both available in IE9+). Oh the eyes of Microsoft shine gracefully upon us, we are so blessed. First, get a spell checker. Second, abandon jQuery at you peril. Browser makers should be required to embed jQuery. jQuery makes JavaScript almost bearable to deal with. That says a lot.

deleted 12y ago
[deleted]

drikerf 12y ago

Too bad lot's of libraries like bootstrap depend on it. Btw, published some time ago http://youmightnotneedjquery.com http://youmightnotneedjquery.com sums it up well and a good reference for jquery people.

drivingmenuts 12y ago

No, I don't need jQuery, but memory really isn't that much of an issue anymore and convenience wins over bandwidth.

malandrew 12y ago

"This is your reminder that the DOM is actually a giant, mutable, global variable in the middle of your program. Act accordingly." –Marco Rogers (@polotek) https://twitter.com/polotek/status/543590973846999040 https://twitter.com/polotek/status/543590973846999040

Morphling 12y ago

I guess if you are super optimizing your website then getting rid of all the useless stuff is fine, but at least I don't notice big enough performance increase to get rid of jQuery even if it's just for the $('selector').

olla 12y ago

Lately everything I build with jQuery I will eventually regret it. The first most annoying problem is that events triggered in jQuery cannot be seen by other modules correctly. Even not by another jQuery instance. There is also the usual size problem, when writing reusable code. For example whenever I want to reuse some 100 lines of code on another project I will have to add almost 100kb of jQuery to make it work. Working also on some bigger everlasting projects, like the wysihtml.com editor, has shown that when you need to patch some browser misbehaviours, native javascript is the only way to go. Such patches need to be as close to their error source as possible.

PSeitz 12y ago

An if you care for performance, you shouldn't use jquery. It is very slow: http://stackoverflow.com/questions/11503534/jquery-vs-document-queryselectorall/21539115#21539115 http://stackoverflow.com/questions/11503534/jquery-vs-docume...

radio4fan 12y ago
But if you care about programmer productivity, you use jQuery, then you profile, then you optimise where required. The last step isn't usually necessary.
- PSeitz 12y ago
  I would rather choose something else for productivity.

deleted 12y ago

[deleted]

steve0341 12y ago

So why reinvent the wheel? Rename title to "Dom manipulation can be done without Jquery, but use what works for you!"

bwindels 12y ago

I don't mind using a library for dom manipulation, or for xhr, or for missing ES5 function ... My problem with jquery is that it does all of it, in a very entangled way. This makes it very tempting to mix parts of your application that really shouldn't know about each other (like dom manipulation (UI) and XHR (IO)). I prefer to use a dedicated library for all of those things and to hide the fact that I am using a particular library to the rest of the application. I've seen standardising on one true huge library throughout an application gone wrong several times and it's very hard to refactor your way out of it.

teknologist 12y ago

Doing ajax without jQuery is also good fun var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState === 4) { callback(JSON.parse(xhr.responseText)); } }; xhr.open('POST', url, true); xhr.setRequestHeader('Content-Type', 'application/json'); xhr.send(JSON.stringify(data)); And that's not taking care of errors, edge cases or Internet Explorer at all. In jQuery: $.post(url, data)

collyw 12y ago

Except, being old school, I remember 7 or 8 years ago, when everyone would complain about IE compatibility and various quirks between browsers. JQuery apparently sorted all of that out. And now we should go back to the bad old ways?

teknologist 12y ago

jQuery should be pre-JIT-compiled in browsers. performance problem solved.

grahamel 12y ago

Everytime I see one of these I think I should do more with https://news.ycombinator.com/item?id=7863271 https://news.ycombinator.com/item?id=7863271 Yes it's useful to know what jQuery is doing underneath but the whole point of it is that you don't have to worry about that and can concentrate on on the rest of your build. Sure, you might not need it and there are other alternatives, both as plain JS and with other libraries, but it does it's job well and will always be easier for others to pick up when coming onto a project.

pjmlp 12y ago

Of course you don't need jQuery, if your customers are happy that you target only one browser specific version. I think the rest of us will rather keep on using it, or similar library.

lfottaviano 12y ago

Don't be bad, look the positive of this site, it teachs us jquery

ponyous 12y ago

My Argument is that you don't need jQuery but you definitely need some kind of library to avoid most common time-consuming tasks.

alxndr 12y ago

A couple days after this was posted to HN, the release of jQuery 1.11.2 and 2.1.3 offers an example of why you might want jQuery even if you might not need it. http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/ http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-re... > "A bug like this one emphasizes the benefit of using a library like jQuery rather than going directly to the DOM APIs."