14 ms·

Why I'm still using jQuery

457 points by UkiahSmith 7y ago

javinpaul 7y ago
You are not alone mate, I am also using jQuery in 2019 :-) It's one of my favorite JavaScript libraries.
isaidno 7y ago
What a great article.
- gchamonlive 7y ago
  Well you should elaborate more, you might get downvoted to oblivion yourself. You should at the very least comment on what exactly you found "shitty" about the article, giving the benefit of the doubt and a means for the author to be better. I find HN downvote system many times misused, but your comment is the perfect example of a one deserving of negative feedback
- cs02rm0 7y ago
  I found it, it's next to your comment.
- nkozyra 7y ago
  Not at all, it makes fair arguments. I may not agree with modern js+dom manipulation being awkward (it's different, but no more awkward to me than jQuery), but I can see the argument.
- Carpetsmoker 7y ago
  (author here) Thank you for your kind words and effort to engage in respectful discourse, even though we disagree. It is appreciated.
  - deleted 7y ago
    [deleted]
- pedrocx486 7y ago
  You must be new here on HN, we usually like to discuss things instead of calling them names. Mind sharing your opinions instead of just saying it's shitty?
  - deleted 7y ago
    [deleted]
  - isaidno 7y ago
    What? I think it's really good!! because it has a lot of good methods and such.
    - simion314 7y ago
      The article is filled with "unnecessary methods and such" , because you reffed to the article. If you mean jQuery , then maybe the functions you don't use others use, give some examples , the most I use daily are attr,css, find, parent, wrap,unwrap,parents,each, filter,toArray, remove, append, after etc (my project gets a ton of possible broken html or html with garbage and I clean it up)
    - DarkWiiPlayer 7y ago
      So now you're editing your comments so they say something completely different, eh? how nice...
      - nextlevelwizard 7y ago
        As of writing this comment the account in question is only 1 hour old. Maybe there should be some kind of time limit before account can comment. Anyway the account is obviously a throwaway created to troll this thread. Just ignore it.
DoctorPenguin 7y ago
I would argue that the comfort of using jQuery comes at the cost of speed and obfuscation. I stopped using jQuery about 2 years ago and for the most part had no problems whatsoever even when I was forced to support IE9. Also I found that searching http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ helps a lot when deciding how to implement certain features.
JanSt 7y ago
If JQuery is all you need to get the job done, go for it. It's still fast, simple and easy to develop. If you need state management, build a very complex app, etc. ... don't.
- cyberferret 7y ago
  This is pretty much it in a nutshell. About the only use case where I will look at a framework outside of jQuery is if I want complex state management, or be able to handle LOTS of updating hotspots on the screen. I'm a proud user of jQuery from way back in the early days, and still haven't found anything to beat it for writing a quick AJAX call to a back end from a web page.
- arp242 7y ago
  > If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff, etc. On the other hand, I find something like FastMail's web UI to be quite pleasant. So it certainly is possible, but I do think it's a lot harder to get an SPA right than it is to get a classic template-driven app right. It's also a lot more complex, which results in all sorts of problems. I don't think jQuery is the "perfect" way to develop stuff; the lack of structure means things can get messy (we've all seen that), but I'm not convinced that React is the best answer to that (just because A is imperfect doesn't mean B is the answer, a common fallacy in these types of discussions). I'm not quite sure what the best way is, and perhaps it already exists and I'm unaware of it, but in the meanwhile I prefer to stick with the "KISS" solution. If I look at the websites I really like using then they're all classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the only exception that I can think of). Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather than "classic JS vs. modern SPA" (although they're obviously related discussions).
  - EugeneOZ 7y ago
    SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.
nkozyra 7y ago
I think the most compelling reason to keep JavaScript is "it's already there." I see no reason to yank it out unless you're already doing some front end refactoring
- sureaboutthis 7y ago
  If you yanked JavaScript out, you wouldn't have jQuery either.
  - nkozyra 7y ago
    Slip of the fingers, obviously
dsenkus 7y ago
convenience is the primary reason I still sometimes use jQuery. Sure dropping one more dependency always seems rewarding, but jQuery is just a tool which when used properly saves a lot of time.
JaTochNietDan 7y ago
I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I bothered to struggle and waste so much time instead of just including jQuery and making things a bunch easier and less verbose. Sure, there may be other libraries worth using instead but the point against the "vanilla JS is all you need" argument. I actually found the cited website in this post http://youmightnotneedjquery.com http://youmightnotneedjquery.com to be so strange as examples of why you may not need jQuery that it may be satire. I was surprised to find out that it was not satire. So I actually forked it and created https://youmightneedjquery.com https://youmightneedjquery.com, on which I may change some text in the future. It may not load for you yet as the DNS propagates. You can find the fork on my Github account here: https://github.com/JaTochNietDan/youmightnotneedjquery https://github.com/JaTochNietDan/youmightnotneedjquery I'll make some changes later to show the satirical nature of it.
- paradoja 7y ago
  Getting a > Error code: SSL_ERROR_BAD_CERT_DOMAIN trying to access https://youmightneedjquery.com https://youmightneedjquery.com .
  - JaTochNietDan 7y ago
    The Github certificate takes a while to sign so I've turned off enforcement for the time being :).
- lampe3 7y ago
  So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.
  - skizm 7y ago
beders 7y ago
I'd like to introduce a new measure: Expected Complexity (EC) Possible values: --> Static webpage --> There's a Form! --> I can click things and the URL doesn't change! --> I spend a few minutes on this site and click a few things --> I spent a couple hours on this site and click lots of things --> My office hours are spent clicking on things on this site! How to determine at the start of development what EC value will be reached: Using a crystal ball (as usual) Pick your technology according to the value of EC. There's a good chance that (= :jQuery (choose-tech ["There's a Form!", "I can click things and the URL doesn't change!", "I spend a few minutes on this site and click a few things"]) is `true` and that's ok.
gchamonlive 7y ago
I have had my share of grief with jquery, but I'm not quite sure it was jquerys fault or the tools built around it. Many a time I had to reimplement stuff like radio button exclusion when a pop-up would render an HTML string as is. Did anyone have problems like that? What are the jquery limitations I should be aware of? I am asking because I am mainly backend and infrastructure developer and feel like I have little experience with frontend tools
sandreas 7y ago
I'm a bit sceptical about this article... I understand the point... jQuery is a nice place to get started for beginners and see how things have been done in the past and I also HATE the boilerplate with most modern JavaScript-Frameworks, but > I want to build webpages that are fast I don't think that jQuery is fast... Especially the fact, that jQuery hooks in every event handler to control the possibility to remove all Event handlers is something that is slowing down every app... event if jQuery is hardly used. > use the simplest feasible code I don't think that code is simple, when it is ONE single function that takes nearly every type as argument with different outcome... And I don't like that developers could use this article as a justification... especially while modern frameworks like vue.js can also be used without setting up a webpack project... But: If you read between the lines, there is something to learn ;)
- LocalPCGuy 7y ago
  > is something that is slowing down every app If that is slowing down your app, something was done wrong. This comment reads (and feel free to correct me for a wrong assumption) as written by someone that really hasn't used jQuery in a serious production capacity.
zaro 7y ago
I didn't know about http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ , but to me it seems very convincing that I need jQuery :)
- invalidusernam3 7y ago
  Exactly. I know I don't need jQuery, but sometimes it's nice to be able to do stuff like make an ajax request as a one liner vs 10+ lines. Peoples gripes with jQuery come from people importing the entire library to do one thing, like add a class to an element. Sure, in that case it's dumb to load the entire library for that single purpose. But if you're using it for 5 things? 10 things? It quickly becomes worthwhile.
  - hatch_q 7y ago
    https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch For IE, you can use a polyfill if needed.
- jeltz 7y ago
  Yeah, that site makes a really good case for using jQuery.
- ape4 7y ago
  Small detail, what's with the plus in this code from that site: last = +new Date();
  - leeoniya 7y ago
    converts the date object to a unix timestamp* (int). a + works for coercing stuff to numbers. e.g. +"0.5" is quicker than paraseFloat("0.5") and also saves you from having to know if you need to use parseFloat or parseInt. coersion to strings can also be done by appending to an empty string: "" + 0.5. * in ms
  - lewiscollard 7y ago
    It is a trick to coerce it to an integer. >> new Date() Date 2019-05-27T12:52:41.932Z >> +new Date() 1558961556913 >> +"4" // works on anything else :) 4
thrower123 7y ago
If it's not broke, don't change it. I could write more, but I'd just be echoing the post's points. I think the biggest win would be avoiding all the insane complexity of a modern npm/webpack JS development experience.
robm99x 7y ago
I’m still using jquery and bootstrap for mvp web app using, of all things, PHP and Slim Framework which surprisingly is not horrible.
cdubzzz 7y ago
The thing that really got me to start thinking twice about jQuery, much more than the youmightnotneed... website, was this performance test for selectors — https://jsperf.com/getelementbyid-vs-queryselector/25 https://jsperf.com/getelementbyid-vs-queryselector/25
- Carpetsmoker 7y ago
  You can build jQuery without the SizzleJS engine and then it'll just use document.querySelectorAll. You can, of course, also still use document.getElementById('foo'), so if you have a specific performance issue you can opt-out for that one function.
- marcosdumay 7y ago
  The slowest function on that tables gives me 900k ops/second. This will not make any difference in a mostly static page.
drikerf 7y ago
Sure. But as always. It depends. If you're writing a highly interactive app and your jQuery script starts containing a lot of view state, eventually you'll go mad and probably duplicate a lot of logic on server and client too. Seeing your app as a function of a data structure/state is then much simpler. Although it will require a bit more thought initially. App = f(s). Again, it depends. If you're writing static sites and sprinkles will stay sprinkles, jQuery will probably be a solid choice.
- scarface74 7y ago
  The most enjoyable front end development experience I’ve had is jQuery + HandlebarsJS.
- Hendrikto 7y ago
  As always, it comes down to: use an appropriate tool for the job. Sadly, that‘s not a nice title for your blog post to go viral, so people make posts like "x is dead, long live y", and "why are you still using x?", or "the era of x is over", in which they present very narrow viewpoints, and try to solve every single problem in the world with the hot new fotm framework.
droptablemain 7y ago
This is all fine and dandy; use what works for you. However, as many of us have learned when trying to aggressively optimize performance, execution time is generally much longer for jQuery than with vanilla JS. So if you're after high PageSpeed scores, for example, jQuery is the damn devil (or at least one of them).
sgift 7y ago
> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text. And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web? This is some special kind of madness and I wonder when it will stop.
- scrollaway 7y ago
  Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using JavaScript, because as it turns out, people develop with JavaScript. Putting aside how useful it is to only have one language to learn in a stack... Typescript is actually incredible to work with. Working on a typescript and react app is the most productive environment I have ever worked with my past 16 years of programming. The JavaScript world has an immense amount of tooling development behind it it's not even funny. So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. Developers are flocking en masse towards the SPA model usually BECAUSE it's easier to develop (both with a single language, and in general having the entire app be self-contained). And it's monumentally easier to maintain at scale, too. EDIT: Clarified that last paragraph.
  - 7y ago
geekamongus 7y ago
As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise. /preaching
- Carpetsmoker 7y ago
  Is this a problem that's worse with jQuery than with other libraries such as vue.js, angular, react? (genuine question, not a comeback)
  - deleted 7y ago
    [deleted]
- folkhack 7y ago
  Just curious what vulns specifically you're referring to?
  - geekamongus 7y ago
    https://snyk.io/vuln/npm:jquery https://snyk.io/vuln/npm:jquery
- madeofpalk 7y ago
  I'm curious - what are the types of vulnerabilities that lie in the client-side jQuery?
  - provolone 7y ago
    If you allow unchecked data to be stored & retrieved there are some XSS vulns in older versions. Ideally this would be prevented in a sane environment.
settsu 7y ago
I’d be curious to see how many people have a cached copy of jQuery from one of the popular CDNs and what the overall real world effects are of that. (That got me thinking of another potentially interesting analysis/discussion about the distribution of jQuery versions being used…)
ehnto 7y ago
The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next(); On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing? element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic. The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already. If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.
- dmitriid 7y ago
  > Had they learned vanilla javascript first Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS. > If you learn jQuery today, you're not learning core JavaScript DOM APIs are not core Javascript.
  - ehnto 7y ago
    You are right, but it's kind of beside the point given the context is web libraries. jQuery is built on top of the DOM API, so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from? jQuery will eventually go away while the DOM API is part of the web's core stack. Maybe it changes over time, but there will likely be a DOM API as long as there are HTML based browsers.
    - jmull 7y ago
fareesh 7y ago
Is there a plan (or is it possible) for jQuery to look at going with some kind of modular approach where you can just import the stuff that you / your plugins want? I know there are libraries that claim to have 100% parity with jQuery's selector library. Are there any ones that are making this claim reliably?
- lioeters 7y ago
  Zepto comes to mind: https://zeptojs.com/#modules https://zeptojs.com/#modules
cptrp2101 7y ago
I think, as with anything else, it's important we understand the tools we are using. I started with jQuery and the problem was (like many others) I learned it before I actually learned javascript. I've since backtracked and dug into vanilla JS so I can have a better understanding of what my code does. Since then, I haven't found a situation where I miss jQuery. However, I don't damn anyone who uses it (beyond jokey arguments with the wordpress dev on my team). It seems like this opinion won't fit in well here, but at this point I find vanilla more than enough for anything where Vue or React will be overkill. However, I'm obviously biased as a front-end app dev and am open to seeing what other people have to say. I'm not sure what to think about the server side vs. client side comments in the article since that fall outside my area of knowledge.
- h1d 7y ago
  You will soon come back to using jQuery again thinking what the point of just saving 30KB by letting your code become longer.
  - Bahamut 7y ago
    Doubtful - 30 kB minified & gzipped is a lot of code, and the fact that jQuery doesn't help with your code organization/keeping code DRY much is a huge negative.
edanm 7y ago
> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery[...] I wasn't aware of http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/, but that's an inaccurate summary of what the website tries to do and really does it a disservice. It very specifically says, in the first sentence on the site, that you should use jQuery for regular development - it's specifically talking about people developing libraries, and encouraging them to not force other people to load jQuery as an extra dependency, which is a very reasonable position. And I don't think it's trying to sell how easy plain JS is, as much as just giving translation code from common jQuery code to plain code, so that if you want to go that route, it'll be easier to do so! Here, I'll just quote the first text on the page (emphasis mine): "jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgot the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."
Chazprime 7y ago
I’m pretty much in agreement with this, to a point. jQuery is a reliable and fast way to make a age do just about anything, except maintaining state. The KISS principle is practically unheard of in web development lately - I see teams using more “hip” technologies like React or Angular for simple sites, but then the complexity of the app increases considerably for not that much in the way of gains. Sometimes simpler really is better
masswerk 7y ago
Something seldom considered while discussing the use of libraries and frameworks: green computing. Mind that you're multiplying any overhead thousandfold or even millionfold when transferring the overhead to each client connecting to the service (including several instances of network infrastructure). So,"how much effort it can be to use vanilla JS", – it may be well worth the extra effort, once, on a single side of the communication chain.
- h1d 7y ago
  Your assumption that everyone can write more efficient code than jQuery isn't making sense.
  - masswerk 7y ago
    It's certainly a matter of balance: if you need just a simple functionality or a single effect, loading (and compiling) the entirety of jQuery may not be the wisest. Similarly, I've seen d3.js loaded just to get a canvas element by 4 lines of code, where a single vanilla line would have done. (Edit: Notably, my argument was about the effort involved.)
sedatk 7y ago
jQuery is an idiomatic DSL but far from intuitive (does “after” imply a DOM modifying action or just a selector?). So I find it okay that browsers have a verbose API as it makes it clearer. Bare DOM API is nowhere close to jQuery in terms of practicality though.
viach 7y ago
Idk in regards of how better the code can be structured with React or Vue, but opening apps based in these frameworks makes similar effect to starting Monero miner locally.
nickjj 7y ago
I still use jquery too and it doesn't have to be a tangled mess of insanity nowadays. Webpack + ES6 modules + jquery is a reasonable option IMO if you like the idea of server rendered templates with sprinkles of Javascript. Plus, with the way things are heading with certain web frameworks (like Phoenix), you can do really interesting things like push the diffs of your server rendered templates over a websocket channel without having to write any user land Javascript yourself, and on the initial page load it just gets served without Javascript using the same templates. It's like the best of both worlds (super fast feeling apps, SEO just works and you don't have to duplicate templates and logic on both the client and server).
unfunco 7y ago
> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery, but the very first example is a good reason to use jQuery: one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code! There's no such thing as one line of jQuery, it's 10K lines before you add your one line to do that one thing that 10 lines of vanilla JS code can do.
- rlv-dan 7y ago
  True. But it's 9 more lines that you have to write yourself. And some people prefer being productive rather than figuring out how to do it in plain JS for the sake of it.
pier25 7y ago
To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular. I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benefit. Users don't care about SPAs, some of the most successful biggest websites are not SPAs (Amazon, Ebay, Wikipedia, etc). A static site generator like Jekyll with some sprinkled JS offers a much better experience. When that is not enough a good old server side rendered app with sprinkled JS is the next step I will consider. There are some perfectly valid use cases for SPAs but those are rare. And don't get me started on libraries/frameworks figuring it out as they go along. jQuery has had a stable API and methodology like forever. React has made major changes in only 5 years. From createElement, to JSX, to classes, to stateless components, to hooks, and only god knows what they will come up with next year.
- deleted 7y ago
  [deleted]
- noir_lord 7y ago
  Vue gets that part pretty right at least, they work hard not to break things unnecessarily across versions and never in version (in my experience). Nothing like jQuery's track record but they don't have the history yet to call on.
  - pier25 7y ago
    Yeah, you can still use the component object notation in Vue 2. AFAIK they will keep that in Vue 3 too but the team is moving onto a new hook-like API after cancelling the class based components.
    - noir_lord 7y ago
      I was bummed they cancelled the class based approach as it’s one I use and like but they did it before 3 was released so not the end of the world.
ulisesrmzroche 7y ago
Oh yeah, the current version of HN's Dropbox trope. How many years have we had this argument? Since the birth of SPAs? "You may not need SPAs" is just another "considered harmful" series of cliches fishing for upvotes. These folks always talk about making the site accessible for everyone by: taking out fancy scripts, images, colors, animations, etcetera; but their sites are the ones that get no traffic, nobody wants to read, nobody wants to use, all that. Maybe our customers don't want stupid simple shit, on account that it's stupid simple. Even the hypotethical 3rd world user, which everyone loves to cry big fake croc tears about, is using Whatsapp, is using Facebook, Instagram, etcetera. The only place people know anything about NoScript, let alone convince them, is here. And I hate HH It's one of the worst-looking, hardest-touse to use sites. It is certainly not a paragon of good design, no matter what the ancient neckbeards say. Just look at the size of those voting arrows. It's ridiculous. How many of yall give downvotes by accident? And all this price to pay for nostalgia? P.S: This whole "most sites don't need an SPA" angle is just plain bullshit. Anyone with real experience in our industry knows that.
Asmod4n 7y ago
When you are done designing your Webpage, disable JavaScript, disable CSS (if your browser supports that) and check that you are still able to grasp what you want to present your visitors. If you then don't find the relevant information in the first second, congratulations, you just made a page which is useless to people with old Screen-readers. I may be old fashioned in this regard, but i only see JS as a Add-on to the text you want to get out and only use it to add functionality which would be impossible with html and css alone. e.G. to give a hint when there are new articles to read, or when a article has changed. Comment sections for example don't require JS at all, but you can use JS to make it needless to reload the page after you send that HTML Form.
- macspoofing 7y ago
  >When you are done designing your Webpage What do you mean by 'webpage'? Because SPAs are really applications that are served over http(s) and executed by the browser. >I may be old fashioned in this regard, but i only see JS as a Add-on You are. People want to build applications served over the web instead of installed locally. In those cases JS is not an add-on. In fact, the DOM is an add-on as it is nothing more than a layout manager and UI component set. Sounds like you just want webpages to be nothing more than a medium for publishing text content in which case CSS and HTML is all you need ... but that ship has sailed in early 2000s.
Raphmedia 7y ago
I've been doing front-end for years and still use jQuery for almost 90% of my projects. It's not because I'm resistant to change, I've done my share of SPA style projects. Simply said, jQuery is still the best plug-n-play solution for most small projects. The numbers are not against jQuery. There's no real gains to skipping it. At 27.77 KB (Minified and Zopflinated file size) it's not as if it's weighting down your pages. On the rare occasions I actually come across something done faster in raw JavaScript (often because jQuery has some heavier polyfills), I simply use the raw JavaScript in my jQuery project.
zackbloom 7y ago
I'm one of the original creators of You Might Not Need jQuery. Most of the examples still date back to 2014, with modern JS they get much simpler and shorter (the fetch API and async/await help tremendously in the first example cited).
- degobah 7y ago
  Thanks for your work. OP maybe didn't read the first two paragraphs of YMNNJ, which clearly states: > jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.
RyanShook 7y ago
Great reminder that old does not equal bad!
losvedir 7y ago
I've seen a few apps that began as vanilla JS or jQuery updated to use react as the requirements grew and the "simple" JS started crumbling under its own weight. So I'm sympathetic to the idea of just starting with a framework from the get-go. That's why I'm excited to see how Phoenix's LiveView turns out. It gives the "server side rendered, sprinkling of JS" approach more room to go in. It won't replace something like Google Maps, but there's a whole class of applications that would previously be on the border of the decision between react and server side that can be pushed into server side.
thrownaway954 7y ago
It's a mature library that takes the pain out of cross browser compatibility (yes... you read that right, cross browser compatibility is still a thing in 2019) and the verboseness of using native JS (yes... you read THAT right, using native JS is verbose), so why wouldn't you want to use it? Oh and on more thing... If you're not using jQuery but instead using native JS with polyfills... YOU ARE A MORON AND DOING IT WRONG and should just you jQuery.
- macspoofing 7y ago
  >yes... you read that right, cross browser compatibility is still a thing in 2019 When it comes to manipulating the DOM, I'm not sure it actually is anymore - especially if you can cut out IE11 (and IE11 isn't too bad). What would be an example of cross-browser compatibility that JQuery takes care of that would be a pain to do with DOM apis.
forgot-my-pw 7y ago
When you don't have to support Internet Explorer, using ES6 (fetch) is nice enough. When you need to support IE, it's best to use jQuery.
- hatch_q 7y ago
  It's not. It's better to use fetch polyfill.
qwerty456127 7y ago
el.insertAdjacentElement('afterend', other) seems a way more intuitive than $(el).after(other). I don't code JavaScript yet the meaning of the first is intuitively obvious to me while I can only know what the second form does because you've told me.
umanage 7y ago
This is pretty much the reason I still use jQuery too. Although JavaScript now offers much of the jQuery functionality as built-ins, the very concise syntax that jQuery offers is more convenient to use.
Existenceblinks 7y ago
Javascript libraries ecosystem in post jquery era is also inefficient. More duplicated efforts on making reusable uis because they (React/Vue/Svelte/Elm/Ember etc) don't mean to integrate well with each other. Mostly they live their own world. Nothing integrates well with server rendering approach because most of them are based on virtual dom or compiler, vm that takes over the whole ui containers. When you change a frontend language/lib/framework, your design system also need to change. All of your branded ui components need to be reinvented although some people just wrap libs such as Sortablejs, Select2 with their favorite js thing. I've experiment Phoenix LiveView with a bunch of mentioned js lib/framework/language (above), nothing really integrates well for production uses. Vanilla js is still best bet for working with server-side rendered html (Unpolyjs or Stimulusjs is nice, but it only serves small purposes) I hope there would be more js that works with good old html that you are already rendering.
jesusthatsgreat 7y ago
If it works for you and is easily maintained by whoever is looking after it, great. In my experience, sooner or later you're gonna want modern functionality / user experience and you're in for a world of pain trying to hack it together with jQuery. These days I'd only use jQuery for sites where I'm the sole developer and the project won't change much over time. Or for legacy projects where the cost of moving everything to an SPA wouldn't be worth it. If you're not the only developer on a project and the project is liable to morph over time, jQuery will be a costly mistake.
degobah 7y ago
> Pages like "You might not need jQuery" try to sell the idea that it’s easy to ditch jQuery. ... good reasons to not use jQuery: if you’re writing code that you want to be re-used by others... Literally the first thing youmightnotneedjquery.com says is: > jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.
drinchev 7y ago
Hardest part to get rid of jQuery was the $.ajax function. Happily now, we can all use the fetch API with some extra polyfills, but pretty much that's it. `el.insertAdjacentElement`, really? Yeah if you carry jQuery thinking with you, you will probably want to translate the code literally and find substitute for everything. No... You can just use to recreate the part of the DOM that needs to be updated and replace it. It's faster to write and easier to read. Anyway most of the arguments are not considering, vanilla JS + webpack / babel es6 + npm packages. In a world where side-effects are not well accepted anymore using jQuery is nightmare to maintain. What's this fuzz about btw, I thought this argument was over?
jb3689 7y ago
I like the progressive enhancement approach using a small amount of JS, and I'm fine with jQuery. The thing is that I don't _use_ very much of jQuery. Rather than pull in all of jQuery you could just define your own `get` and `post` to abstract the XHR verbosity. No need to pull in a giant library to do that
pizza_r0b 7y ago
one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code! Actually those 10 lines are replaced by the entire JQuery library.
Aaron-goshine 7y ago
Fist let me say this thread has turned out to be possible the most important thread in regards to modern web development. Single page Applications (SPA) and frame works that are used to develop such applications are over used which have led to a whole host of problems in the software engineering industry, I truly believe that if you are building software solutions 90% percent of the time you will be building them to solve business problems, so that should be of paramount importance not necessarily the latest shines concept and tools, especially unproven tools. A very high percentage of the developers you will interview will be using front end frame work such as Reactjs, Anuglar, VueJs ... etc as a substitute for truly understanding the the native technologies and standards support by various user agents. The consequences of this is usually very expensive for business while resulting in software products that are convoluted, complex and unstable; I have seen this too many times. The JavaScript eco system at the moment is littered with these kind problems, pseudo stars developers who want to re invent the wheel (without first understanding the existing mechanics), not only is reinventing the wheel already an idea that has been frowned upon for thousands of years, in the context of software development most of the times it turns out to be a much buggier and less efficient solution. I have encountered SPAs that have been built out to be so complicated and convoluted to say the least; in order to support server side rendering, hot module reloading, dynamic DOM refresh, Virtual DOM… etc. speaking as if these concepts are some holy gifts from the gods, and when you ask the most fundamental question what are the business values behind all of these concepts, there are no good answers.
tempodox 7y ago
So, what is a good jQuery replacement nowadays, for just XHR and a bit of CSS manipulation?

457 points by UkiahSmith 7y ago

javinpaul 7y ago

You are not alone mate, I am also using jQuery in 2019 :-) It's one of my favorite JavaScript libraries.

isaidno 7y ago

What a great article.

gchamonlive 7y ago
Well you should elaborate more, you might get downvoted to oblivion yourself. You should at the very least comment on what exactly you found "shitty" about the article, giving the benefit of the doubt and a means for the author to be better. I find HN downvote system many times misused, but your comment is the perfect example of a one deserving of negative feedback
cs02rm0 7y ago
I found it, it's next to your comment.
nkozyra 7y ago
Not at all, it makes fair arguments. I may not agree with modern js+dom manipulation being awkward (it's different, but no more awkward to me than jQuery), but I can see the argument.
Carpetsmoker 7y ago
(author here) Thank you for your kind words and effort to engage in respectful discourse, even though we disagree. It is appreciated.
- deleted 7y ago
  [deleted]
pedrocx486 7y ago
You must be new here on HN, we usually like to discuss things instead of calling them names. Mind sharing your opinions instead of just saying it's shitty?
- deleted 7y ago
  [deleted]
- isaidno 7y ago
  What? I think it's really good!! because it has a lot of good methods and such.
  - simion314 7y ago
    The article is filled with "unnecessary methods and such" , because you reffed to the article. If you mean jQuery , then maybe the functions you don't use others use, give some examples , the most I use daily are attr,css, find, parent, wrap,unwrap,parents,each, filter,toArray, remove, append, after etc (my project gets a ton of possible broken html or html with garbage and I clean it up)
  - DarkWiiPlayer 7y ago
    So now you're editing your comments so they say something completely different, eh? how nice...
    - nextlevelwizard 7y ago
      As of writing this comment the account in question is only 1 hour old. Maybe there should be some kind of time limit before account can comment. Anyway the account is obviously a throwaway created to troll this thread. Just ignore it.

DoctorPenguin 7y ago

I would argue that the comfort of using jQuery comes at the cost of speed and obfuscation. I stopped using jQuery about 2 years ago and for the most part had no problems whatsoever even when I was forced to support IE9. Also I found that searching http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ helps a lot when deciding how to implement certain features.

JanSt 7y ago

If JQuery is all you need to get the job done, go for it. It's still fast, simple and easy to develop. If you need state management, build a very complex app, etc. ... don't.

cyberferret 7y ago
This is pretty much it in a nutshell. About the only use case where I will look at a framework outside of jQuery is if I want complex state management, or be able to handle LOTS of updating hotspots on the screen. I'm a proud user of jQuery from way back in the early days, and still haven't found anything to beat it for writing a quick AJAX call to a back end from a web page.
arp242 7y ago
> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff, etc. On the other hand, I find something like FastMail's web UI to be quite pleasant. So it certainly is possible, but I do think it's a lot harder to get an SPA right than it is to get a classic template-driven app right. It's also a lot more complex, which results in all sorts of problems. I don't think jQuery is the "perfect" way to develop stuff; the lack of structure means things can get messy (we've all seen that), but I'm not convinced that React is the best answer to that (just because A is imperfect doesn't mean B is the answer, a common fallacy in these types of discussions). I'm not quite sure what the best way is, and perhaps it already exists and I'm unaware of it, but in the meanwhile I prefer to stick with the "KISS" solution. If I look at the websites I really like using then they're all classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the only exception that I can think of). Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather than "classic JS vs. modern SPA" (although they're obviously related discussions).
- EugeneOZ 7y ago
  SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

nkozyra 7y ago

I think the most compelling reason to keep JavaScript is "it's already there." I see no reason to yank it out unless you're already doing some front end refactoring

sureaboutthis 7y ago
If you yanked JavaScript out, you wouldn't have jQuery either.
- nkozyra 7y ago
  Slip of the fingers, obviously

dsenkus 7y ago

convenience is the primary reason I still sometimes use jQuery. Sure dropping one more dependency always seems rewarding, but jQuery is just a tool which when used properly saves a lot of time.

JaTochNietDan 7y ago

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I bothered to struggle and waste so much time instead of just including jQuery and making things a bunch easier and less verbose. Sure, there may be other libraries worth using instead but the point against the "vanilla JS is all you need" argument. I actually found the cited website in this post http://youmightnotneedjquery.com http://youmightnotneedjquery.com to be so strange as examples of why you may not need jQuery that it may be satire. I was surprised to find out that it was not satire. So I actually forked it and created https://youmightneedjquery.com https://youmightneedjquery.com, on which I may change some text in the future. It may not load for you yet as the DNS propagates. You can find the fork on my Github account here: https://github.com/JaTochNietDan/youmightnotneedjquery https://github.com/JaTochNietDan/youmightnotneedjquery I'll make some changes later to show the satirical nature of it.

paradoja 7y ago
Getting a > Error code: SSL_ERROR_BAD_CERT_DOMAIN trying to access https://youmightneedjquery.com https://youmightneedjquery.com .
- JaTochNietDan 7y ago
  The Github certificate takes a while to sign so I've turned off enforcement for the time being :).
lampe3 7y ago
So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.
- skizm 7y ago

beders 7y ago

I'd like to introduce a new measure: Expected Complexity (EC) Possible values: --> Static webpage --> There's a Form! --> I can click things and the URL doesn't change! --> I spend a few minutes on this site and click a few things --> I spent a couple hours on this site and click lots of things --> My office hours are spent clicking on things on this site! How to determine at the start of development what EC value will be reached: Using a crystal ball (as usual) Pick your technology according to the value of EC. There's a good chance that (= :jQuery (choose-tech ["There's a Form!", "I can click things and the URL doesn't change!", "I spend a few minutes on this site and click a few things"]) is `true` and that's ok.

gchamonlive 7y ago

I have had my share of grief with jquery, but I'm not quite sure it was jquerys fault or the tools built around it. Many a time I had to reimplement stuff like radio button exclusion when a pop-up would render an HTML string as is. Did anyone have problems like that? What are the jquery limitations I should be aware of? I am asking because I am mainly backend and infrastructure developer and feel like I have little experience with frontend tools

sandreas 7y ago

I'm a bit sceptical about this article... I understand the point... jQuery is a nice place to get started for beginners and see how things have been done in the past and I also HATE the boilerplate with most modern JavaScript-Frameworks, but > I want to build webpages that are fast I don't think that jQuery is fast... Especially the fact, that jQuery hooks in every event handler to control the possibility to remove all Event handlers is something that is slowing down every app... event if jQuery is hardly used. > use the simplest feasible code I don't think that code is simple, when it is ONE single function that takes nearly every type as argument with different outcome... And I don't like that developers could use this article as a justification... especially while modern frameworks like vue.js can also be used without setting up a webpack project... But: If you read between the lines, there is something to learn ;)

LocalPCGuy 7y ago
> is something that is slowing down every app If that is slowing down your app, something was done wrong. This comment reads (and feel free to correct me for a wrong assumption) as written by someone that really hasn't used jQuery in a serious production capacity.

zaro 7y ago

I didn't know about http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ , but to me it seems very convincing that I need jQuery :)

invalidusernam3 7y ago
Exactly. I know I don't need jQuery, but sometimes it's nice to be able to do stuff like make an ajax request as a one liner vs 10+ lines. Peoples gripes with jQuery come from people importing the entire library to do one thing, like add a class to an element. Sure, in that case it's dumb to load the entire library for that single purpose. But if you're using it for 5 things? 10 things? It quickly becomes worthwhile.
- hatch_q 7y ago
  https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch For IE, you can use a polyfill if needed.
jeltz 7y ago
Yeah, that site makes a really good case for using jQuery.
ape4 7y ago
Small detail, what's with the plus in this code from that site: last = +new Date();
- leeoniya 7y ago
  converts the date object to a unix timestamp* (int). a + works for coercing stuff to numbers. e.g. +"0.5" is quicker than paraseFloat("0.5") and also saves you from having to know if you need to use parseFloat or parseInt. coersion to strings can also be done by appending to an empty string: "" + 0.5. * in ms
- lewiscollard 7y ago
  It is a trick to coerce it to an integer. >> new Date() Date 2019-05-27T12:52:41.932Z >> +new Date() 1558961556913 >> +"4" // works on anything else :) 4

thrower123 7y ago

If it's not broke, don't change it. I could write more, but I'd just be echoing the post's points. I think the biggest win would be avoiding all the insane complexity of a modern npm/webpack JS development experience.

robm99x 7y ago

I’m still using jquery and bootstrap for mvp web app using, of all things, PHP and Slim Framework which surprisingly is not horrible.

cdubzzz 7y ago

The thing that really got me to start thinking twice about jQuery, much more than the youmightnotneed... website, was this performance test for selectors — https://jsperf.com/getelementbyid-vs-queryselector/25 https://jsperf.com/getelementbyid-vs-queryselector/25

Carpetsmoker 7y ago
You can build jQuery without the SizzleJS engine and then it'll just use document.querySelectorAll. You can, of course, also still use document.getElementById('foo'), so if you have a specific performance issue you can opt-out for that one function.
marcosdumay 7y ago
The slowest function on that tables gives me 900k ops/second. This will not make any difference in a mostly static page.

drikerf 7y ago

Sure. But as always. It depends. If you're writing a highly interactive app and your jQuery script starts containing a lot of view state, eventually you'll go mad and probably duplicate a lot of logic on server and client too. Seeing your app as a function of a data structure/state is then much simpler. Although it will require a bit more thought initially. App = f(s). Again, it depends. If you're writing static sites and sprinkles will stay sprinkles, jQuery will probably be a solid choice.

scarface74 7y ago
The most enjoyable front end development experience I’ve had is jQuery + HandlebarsJS.
Hendrikto 7y ago
As always, it comes down to: use an appropriate tool for the job. Sadly, that‘s not a nice title for your blog post to go viral, so people make posts like "x is dead, long live y", and "why are you still using x?", or "the era of x is over", in which they present very narrow viewpoints, and try to solve every single problem in the world with the hot new fotm framework.

droptablemain 7y ago

This is all fine and dandy; use what works for you. However, as many of us have learned when trying to aggressively optimize performance, execution time is generally much longer for jQuery than with vanilla JS. So if you're after high PageSpeed scores, for example, jQuery is the damn devil (or at least one of them).

sgift 7y ago

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text. And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web? This is some special kind of madness and I wonder when it will stop.

scrollaway 7y ago
Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using JavaScript, because as it turns out, people develop with JavaScript. Putting aside how useful it is to only have one language to learn in a stack... Typescript is actually incredible to work with. Working on a typescript and react app is the most productive environment I have ever worked with my past 16 years of programming. The JavaScript world has an immense amount of tooling development behind it it's not even funny. So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. Developers are flocking en masse towards the SPA model usually BECAUSE it's easier to develop (both with a single language, and in general having the entire app be self-contained). And it's monumentally easier to maintain at scale, too. EDIT: Clarified that last paragraph.
- 7y ago

geekamongus 7y ago

As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise. /preaching

Carpetsmoker 7y ago
Is this a problem that's worse with jQuery than with other libraries such as vue.js, angular, react? (genuine question, not a comeback)
- deleted 7y ago
  [deleted]
folkhack 7y ago
Just curious what vulns specifically you're referring to?
- geekamongus 7y ago
  https://snyk.io/vuln/npm:jquery https://snyk.io/vuln/npm:jquery
madeofpalk 7y ago
I'm curious - what are the types of vulnerabilities that lie in the client-side jQuery?
- provolone 7y ago
  If you allow unchecked data to be stored & retrieved there are some XSS vulns in older versions. Ideally this would be prevented in a sane environment.

settsu 7y ago

I’d be curious to see how many people have a cached copy of jQuery from one of the popular CDNs and what the overall real world effects are of that. (That got me thinking of another potentially interesting analysis/discussion about the distribution of jQuery versions being used…)

ehnto 7y ago

The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next(); On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing? element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic. The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already. If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.

dmitriid 7y ago
> Had they learned vanilla javascript first Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS. > If you learn jQuery today, you're not learning core JavaScript DOM APIs are not core Javascript.
- ehnto 7y ago
  You are right, but it's kind of beside the point given the context is web libraries. jQuery is built on top of the DOM API, so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from? jQuery will eventually go away while the DOM API is part of the web's core stack. Maybe it changes over time, but there will likely be a DOM API as long as there are HTML based browsers.
  - jmull 7y ago

fareesh 7y ago

Is there a plan (or is it possible) for jQuery to look at going with some kind of modular approach where you can just import the stuff that you / your plugins want? I know there are libraries that claim to have 100% parity with jQuery's selector library. Are there any ones that are making this claim reliably?

lioeters 7y ago
Zepto comes to mind: https://zeptojs.com/#modules https://zeptojs.com/#modules

cptrp2101 7y ago

I think, as with anything else, it's important we understand the tools we are using. I started with jQuery and the problem was (like many others) I learned it before I actually learned javascript. I've since backtracked and dug into vanilla JS so I can have a better understanding of what my code does. Since then, I haven't found a situation where I miss jQuery. However, I don't damn anyone who uses it (beyond jokey arguments with the wordpress dev on my team). It seems like this opinion won't fit in well here, but at this point I find vanilla more than enough for anything where Vue or React will be overkill. However, I'm obviously biased as a front-end app dev and am open to seeing what other people have to say. I'm not sure what to think about the server side vs. client side comments in the article since that fall outside my area of knowledge.

h1d 7y ago
You will soon come back to using jQuery again thinking what the point of just saving 30KB by letting your code become longer.
- Bahamut 7y ago
  Doubtful - 30 kB minified & gzipped is a lot of code, and the fact that jQuery doesn't help with your code organization/keeping code DRY much is a huge negative.

edanm 7y ago

> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery[...] I wasn't aware of http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/, but that's an inaccurate summary of what the website tries to do and really does it a disservice. It very specifically says, in the first sentence on the site, that you should use jQuery for regular development - it's specifically talking about people developing libraries, and encouraging them to not force other people to load jQuery as an extra dependency, which is a very reasonable position. And I don't think it's trying to sell how easy plain JS is, as much as just giving translation code from common jQuery code to plain code, so that if you want to go that route, it'll be easier to do so! Here, I'll just quote the first text on the page (emphasis mine): "jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgot the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."

Chazprime 7y ago

I’m pretty much in agreement with this, to a point. jQuery is a reliable and fast way to make a age do just about anything, except maintaining state. The KISS principle is practically unheard of in web development lately - I see teams using more “hip” technologies like React or Angular for simple sites, but then the complexity of the app increases considerably for not that much in the way of gains. Sometimes simpler really is better

masswerk 7y ago

Something seldom considered while discussing the use of libraries and frameworks: green computing. Mind that you're multiplying any overhead thousandfold or even millionfold when transferring the overhead to each client connecting to the service (including several instances of network infrastructure). So,"how much effort it can be to use vanilla JS", – it may be well worth the extra effort, once, on a single side of the communication chain.

h1d 7y ago
Your assumption that everyone can write more efficient code than jQuery isn't making sense.
- masswerk 7y ago
  It's certainly a matter of balance: if you need just a simple functionality or a single effect, loading (and compiling) the entirety of jQuery may not be the wisest. Similarly, I've seen d3.js loaded just to get a canvas element by 4 lines of code, where a single vanilla line would have done. (Edit: Notably, my argument was about the effort involved.)

sedatk 7y ago

jQuery is an idiomatic DSL but far from intuitive (does “after” imply a DOM modifying action or just a selector?). So I find it okay that browsers have a verbose API as it makes it clearer. Bare DOM API is nowhere close to jQuery in terms of practicality though.

viach 7y ago

Idk in regards of how better the code can be structured with React or Vue, but opening apps based in these frameworks makes similar effect to starting Monero miner locally.

nickjj 7y ago

I still use jquery too and it doesn't have to be a tangled mess of insanity nowadays. Webpack + ES6 modules + jquery is a reasonable option IMO if you like the idea of server rendered templates with sprinkles of Javascript. Plus, with the way things are heading with certain web frameworks (like Phoenix), you can do really interesting things like push the diffs of your server rendered templates over a websocket channel without having to write any user land Javascript yourself, and on the initial page load it just gets served without Javascript using the same templates. It's like the best of both worlds (super fast feeling apps, SEO just works and you don't have to duplicate templates and logic on both the client and server).

unfunco 7y ago

> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery, but the very first example is a good reason to use jQuery: one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code! There's no such thing as one line of jQuery, it's 10K lines before you add your one line to do that one thing that 10 lines of vanilla JS code can do.

rlv-dan 7y ago
True. But it's 9 more lines that you have to write yourself. And some people prefer being productive rather than figuring out how to do it in plain JS for the sake of it.

pier25 7y ago

To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular. I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benefit. Users don't care about SPAs, some of the most successful biggest websites are not SPAs (Amazon, Ebay, Wikipedia, etc). A static site generator like Jekyll with some sprinkled JS offers a much better experience. When that is not enough a good old server side rendered app with sprinkled JS is the next step I will consider. There are some perfectly valid use cases for SPAs but those are rare. And don't get me started on libraries/frameworks figuring it out as they go along. jQuery has had a stable API and methodology like forever. React has made major changes in only 5 years. From createElement, to JSX, to classes, to stateless components, to hooks, and only god knows what they will come up with next year.

deleted 7y ago
[deleted]
noir_lord 7y ago
Vue gets that part pretty right at least, they work hard not to break things unnecessarily across versions and never in version (in my experience). Nothing like jQuery's track record but they don't have the history yet to call on.
- pier25 7y ago
  Yeah, you can still use the component object notation in Vue 2. AFAIK they will keep that in Vue 3 too but the team is moving onto a new hook-like API after cancelling the class based components.
  - noir_lord 7y ago
    I was bummed they cancelled the class based approach as it’s one I use and like but they did it before 3 was released so not the end of the world.

ulisesrmzroche 7y ago

Oh yeah, the current version of HN's Dropbox trope. How many years have we had this argument? Since the birth of SPAs? "You may not need SPAs" is just another "considered harmful" series of cliches fishing for upvotes. These folks always talk about making the site accessible for everyone by: taking out fancy scripts, images, colors, animations, etcetera; but their sites are the ones that get no traffic, nobody wants to read, nobody wants to use, all that. Maybe our customers don't want stupid simple shit, on account that it's stupid simple. Even the hypotethical 3rd world user, which everyone loves to cry big fake croc tears about, is using Whatsapp, is using Facebook, Instagram, etcetera. The only place people know anything about NoScript, let alone convince them, is here. And I hate HH It's one of the worst-looking, hardest-touse to use sites. It is certainly not a paragon of good design, no matter what the ancient neckbeards say. Just look at the size of those voting arrows. It's ridiculous. How many of yall give downvotes by accident? And all this price to pay for nostalgia? P.S: This whole "most sites don't need an SPA" angle is just plain bullshit. Anyone with real experience in our industry knows that.

Asmod4n 7y ago

When you are done designing your Webpage, disable JavaScript, disable CSS (if your browser supports that) and check that you are still able to grasp what you want to present your visitors. If you then don't find the relevant information in the first second, congratulations, you just made a page which is useless to people with old Screen-readers. I may be old fashioned in this regard, but i only see JS as a Add-on to the text you want to get out and only use it to add functionality which would be impossible with html and css alone. e.G. to give a hint when there are new articles to read, or when a article has changed. Comment sections for example don't require JS at all, but you can use JS to make it needless to reload the page after you send that HTML Form.

macspoofing 7y ago
>When you are done designing your Webpage What do you mean by 'webpage'? Because SPAs are really applications that are served over http(s) and executed by the browser. >I may be old fashioned in this regard, but i only see JS as a Add-on You are. People want to build applications served over the web instead of installed locally. In those cases JS is not an add-on. In fact, the DOM is an add-on as it is nothing more than a layout manager and UI component set. Sounds like you just want webpages to be nothing more than a medium for publishing text content in which case CSS and HTML is all you need ... but that ship has sailed in early 2000s.

Raphmedia 7y ago

I've been doing front-end for years and still use jQuery for almost 90% of my projects. It's not because I'm resistant to change, I've done my share of SPA style projects. Simply said, jQuery is still the best plug-n-play solution for most small projects. The numbers are not against jQuery. There's no real gains to skipping it. At 27.77 KB (Minified and Zopflinated file size) it's not as if it's weighting down your pages. On the rare occasions I actually come across something done faster in raw JavaScript (often because jQuery has some heavier polyfills), I simply use the raw JavaScript in my jQuery project.

zackbloom 7y ago

I'm one of the original creators of You Might Not Need jQuery. Most of the examples still date back to 2014, with modern JS they get much simpler and shorter (the fetch API and async/await help tremendously in the first example cited).

degobah 7y ago
Thanks for your work. OP maybe didn't read the first two paragraphs of YMNNJ, which clearly states: > jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.

RyanShook 7y ago

Great reminder that old does not equal bad!

losvedir 7y ago

I've seen a few apps that began as vanilla JS or jQuery updated to use react as the requirements grew and the "simple" JS started crumbling under its own weight. So I'm sympathetic to the idea of just starting with a framework from the get-go. That's why I'm excited to see how Phoenix's LiveView turns out. It gives the "server side rendered, sprinkling of JS" approach more room to go in. It won't replace something like Google Maps, but there's a whole class of applications that would previously be on the border of the decision between react and server side that can be pushed into server side.

thrownaway954 7y ago

It's a mature library that takes the pain out of cross browser compatibility (yes... you read that right, cross browser compatibility is still a thing in 2019) and the verboseness of using native JS (yes... you read THAT right, using native JS is verbose), so why wouldn't you want to use it? Oh and on more thing... If you're not using jQuery but instead using native JS with polyfills... YOU ARE A MORON AND DOING IT WRONG and should just you jQuery.

macspoofing 7y ago
>yes... you read that right, cross browser compatibility is still a thing in 2019 When it comes to manipulating the DOM, I'm not sure it actually is anymore - especially if you can cut out IE11 (and IE11 isn't too bad). What would be an example of cross-browser compatibility that JQuery takes care of that would be a pain to do with DOM apis.

forgot-my-pw 7y ago

When you don't have to support Internet Explorer, using ES6 (fetch) is nice enough. When you need to support IE, it's best to use jQuery.

hatch_q 7y ago
It's not. It's better to use fetch polyfill.

qwerty456127 7y ago

el.insertAdjacentElement('afterend', other) seems a way more intuitive than $(el).after(other). I don't code JavaScript yet the meaning of the first is intuitively obvious to me while I can only know what the second form does because you've told me.

umanage 7y ago

This is pretty much the reason I still use jQuery too. Although JavaScript now offers much of the jQuery functionality as built-ins, the very concise syntax that jQuery offers is more convenient to use.

Existenceblinks 7y ago

Javascript libraries ecosystem in post jquery era is also inefficient. More duplicated efforts on making reusable uis because they (React/Vue/Svelte/Elm/Ember etc) don't mean to integrate well with each other. Mostly they live their own world. Nothing integrates well with server rendering approach because most of them are based on virtual dom or compiler, vm that takes over the whole ui containers. When you change a frontend language/lib/framework, your design system also need to change. All of your branded ui components need to be reinvented although some people just wrap libs such as Sortablejs, Select2 with their favorite js thing. I've experiment Phoenix LiveView with a bunch of mentioned js lib/framework/language (above), nothing really integrates well for production uses. Vanilla js is still best bet for working with server-side rendered html (Unpolyjs or Stimulusjs is nice, but it only serves small purposes) I hope there would be more js that works with good old html that you are already rendering.

jesusthatsgreat 7y ago

If it works for you and is easily maintained by whoever is looking after it, great. In my experience, sooner or later you're gonna want modern functionality / user experience and you're in for a world of pain trying to hack it together with jQuery. These days I'd only use jQuery for sites where I'm the sole developer and the project won't change much over time. Or for legacy projects where the cost of moving everything to an SPA wouldn't be worth it. If you're not the only developer on a project and the project is liable to morph over time, jQuery will be a costly mistake.

degobah 7y ago

> Pages like "You might not need jQuery" try to sell the idea that it’s easy to ditch jQuery. ... good reasons to not use jQuery: if you’re writing code that you want to be re-used by others... Literally the first thing youmightnotneedjquery.com says is: > jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.

drinchev 7y ago

Hardest part to get rid of jQuery was the $.ajax function. Happily now, we can all use the fetch API with some extra polyfills, but pretty much that's it. `el.insertAdjacentElement`, really? Yeah if you carry jQuery thinking with you, you will probably want to translate the code literally and find substitute for everything. No... You can just use to recreate the part of the DOM that needs to be updated and replace it. It's faster to write and easier to read. Anyway most of the arguments are not considering, vanilla JS + webpack / babel es6 + npm packages. In a world where side-effects are not well accepted anymore using jQuery is nightmare to maintain. What's this fuzz about btw, I thought this argument was over?

jb3689 7y ago

I like the progressive enhancement approach using a small amount of JS, and I'm fine with jQuery. The thing is that I don't _use_ very much of jQuery. Rather than pull in all of jQuery you could just define your own `get` and `post` to abstract the XHR verbosity. No need to pull in a giant library to do that

pizza_r0b 7y ago

one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code! Actually those 10 lines are replaced by the entire JQuery library.

Aaron-goshine 7y ago

Fist let me say this thread has turned out to be possible the most important thread in regards to modern web development. Single page Applications (SPA) and frame works that are used to develop such applications are over used which have led to a whole host of problems in the software engineering industry, I truly believe that if you are building software solutions 90% percent of the time you will be building them to solve business problems, so that should be of paramount importance not necessarily the latest shines concept and tools, especially unproven tools. A very high percentage of the developers you will interview will be using front end frame work such as Reactjs, Anuglar, VueJs ... etc as a substitute for truly understanding the the native technologies and standards support by various user agents. The consequences of this is usually very expensive for business while resulting in software products that are convoluted, complex and unstable; I have seen this too many times. The JavaScript eco system at the moment is littered with these kind problems, pseudo stars developers who want to re invent the wheel (without first understanding the existing mechanics), not only is reinventing the wheel already an idea that has been frowned upon for thousands of years, in the context of software development most of the times it turns out to be a much buggier and less efficient solution. I have encountered SPAs that have been built out to be so complicated and convoluted to say the least; in order to support server side rendering, hot module reloading, dynamic DOM refresh, Virtual DOM… etc. speaking as if these concepts are some holy gifts from the gods, and when you ask the most fundamental question what are the business values behind all of these concepts, there are no good answers.

tempodox 7y ago

So, what is a good jQuery replacement nowadays, for just XHR and a bit of CSS manipulation?