8 ms·

jQuery 3.6.2

195 points by gslin 4y ago

ddmma 4y ago
Feels like Winamp but things eventually evolved on server side. Always welcome on my legacy .net project:)
CM30 4y ago
Sorry if this sounds naive, but... do people still use jQuery for new projects? I was genuinely surprised to see it was getting releases anymore, given how much of its functionality can be done with native JavaScript now.
- amflare 4y ago
  Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the messier and more complicated elements and giving developers a more intuitive set of tools. Some part of this are less necessary today than when jQuery v1 came out (like `querySelectorAll()` vs `$()`), but other parts are still enormously helpful (like `$.ajax()`). So like always, it's a trade off. But it's still one that comes up as worth it as often as not.
  - udp 4y ago
    I’m not sure $.ajax() is a good example now that fetch is widely supported.
  - gabereiser 4y ago
    `$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/
    - amflare 4y ago
      That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
      - duskwuff 4y ago
        You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
      - no_way 4y ago
        You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
        amflare 4y ago
        Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
        LudwigNagasena 4y ago
        Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
      - LudwigNagasena 4y ago
        Babel?
    - Beltalowda 4y ago
      I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
  - ssl232 4y ago
    Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.
- ericb 4y ago
  One thing that gets forgotten about jQuery is that there's a tremendous library of very evolved components in its ecosystem. Sure, "you don't need jQuery" is true, but when you go hunting for components you'd rather not write yourself, man is there still some gravity there. You ask yourself, "do I feel like writing a calendar selector widget today?" Trade some vanity and JavaScript puritanism and the question becomes "what color should I style it?"
- kypro 4y ago
  I've not used it in a new project for a long time, but I often still work on projects with legacy jQuery code. The main reason to still use it imo it is simply that a lot of devs are familiar with the API and they have really good docs. While I prefer vanilla JS for JS-light projects, I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. The nice thing JQuery is that you know it will work as expected on the all browsers it supports so you don't need to worry about cross-browser testing your code. It also makes certain things easier to do like basic JS animations. The main reason care about the latest releases is that they patch security issues from time to time.
  - collyw 4y ago
    > I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. That was the main reason that jQuery got popular if I remember correctly (though I have always been an 85% backend developer). I was under the impression that that isn't really an issue these days, but everyone is building overly complex monstrosities with React or whatever else is flavor of the month.
    - lelandfe 4y ago
      https://webkit.org/blog/12288/working-together-on-interop-2022/ https://webkit.org/blog/12288/working-together-on-interop-20... The various browsers have gotten together and work awfully hard to fix outstanding quirks. You'll still encounter cross-browser oddities here and there, but it's generally more in the order of, "X browser hasn't added this method yet"
    - The_Colonel 4y ago
      Yes, the cross browser weirdness is nothing like it used to be. The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
    - eyelidlessness 4y ago
      I was jQuery’s target audience at its heyday and at least for me, the big thing it brought to the table was $ and what’s now called a “fluent API” ($ methods return $ instances unless they’re getters for primitives; it’s pretty much still my preferred way to explain the general concept of monads to people familiar with the pattern). Browser compatibility was just delicious icing on the cake.
- PrivateButts 4y ago
  jQuery is like, comfort food for me? Used to use jQuery for everything and now the world's moved on. I wouldn't want to do a large project today in jQuery, but I kinda miss the simpler projects that I used to do all the time with a smaller toolbox.
- jrochkind1 4y ago
  i don't intentionally write code using JQuery anymore, and find it not very inconvenient to avoid for the most part, even when writing "jquery style" JS -- which I do. Browser API's in recent browsers are good enough. But I'm still using some dependencies that need jquery. I honestly expect I'll never be able to get rid of it.
- smallmouth 4y ago
  Apology accepted, and absolutely! Myself and two other developers just kicked off a very non-tivial, data-heavy application for a Dow 30 that will be used by a maximum of 12,000 users. Using jquery will help us avoid a lot of thinking and testing time with the whole "gee, how would I do that in vanilla, let me look that up" process.
- deleted 4y ago
  [deleted]
- pier25 4y ago
  jQuery is more popular than React by pretty much any metric you can find
  - collyw 4y ago
    for starting new projects?
    - kbrannigan 4y ago
      Beginers and aspiring sofware developers tends to use the most popular technology, evangelized by the biggest companies. Since they don't know any better, they equate MOST POPULAR with BEST. Sometimes all you need is a wheelbarrow, you don't need a tractor.
      - collyw 4y ago
        BEST is highly subjective. Most popular has a number of advantages- more developers, likely cheaper developers, bigger community but for most cases I am in agreement with you
    - pier25 4y ago
      Yeah. There are probably more new projects started with Wordpress themes that use jQuery than React projects. And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC. If you don't need a super sophisticated frontend, jQuery is still one of the best tools around. People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.
- thejammahimself 4y ago
  Yeah a good few years ago, before I had learnt about frameworks like React, I used JQuery for one of my projects. Once I learned about React, I decided to rewrite this project using that instead, and afterwards I felt that the React version was very obviously the superior version. I just feel like we now have better options, and I still really like React's way of handling state in a moreso functional way.
- tsian2 4y ago
  I find it much quicker to write and neater to read than vanilla JS. I optimise afterwards and might consider swapping it out but it's usually low down the list of performance issues. Although it can be a bigger issue if you don't know how select things and store those selections efficiently with it.
- jabart 4y ago
  Bootstrap 4 uses jquery, bootstrap 5 was released (not beta) May 5, 2021. So, anything started with Bootstrap 4 would use it.
- yokoprime 4y ago
  I only encounter it when maintaining old codebases. Never for anything new
- ww520 4y ago
  Yes. I do still use it.
- Alupis 4y ago
  The API jQuery gives you is still so much nicer than regular javascript, even with modern ECMAScript 7+... While we're at it - Bootstrap (and similar css frameworks) are still much nicer to use than native CSS, even with modern CSS3 and flexbox... It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because.
  - eyelidlessness 4y ago
    > It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle. Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces. More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
    - Alupis 4y ago
      Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
- progmetaldev 4y ago
  I am still using jQuery because I have so many plugins such as calendars, photo galleries, video galleries, and file explorer type trees that are all progressively enhanced, it would be a ton of work to rebuild everything. I think jQuery is still does a great job for progressive enhancement of CMS/informational type websites.
- bigger_cheese 4y ago
  I used jQuery earlier this year. I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it. I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers. One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format. So I just used the JQuery calendar picker took me two seconds and problem solved.
- tambourine_man 4y ago
  It always could be done in JavaScript, jQuery is written on it after all. It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.
- deterministic 4y ago
  Yep. It is the first package I install on a new project. Followed by React.
- PointyFluff 4y ago
irrational 4y ago
I'm aware of "You might not need jQuery", but has anyone created a comprehensive list of everything jQuery offers that is not available through native JS/CSS? I guess I should specify, not available as easy as jQuery. Technically anything that jQuery does can, obviously, be done natively, but I remember there were some things that were much much much easier to do in jQuery than natively. Some of those easy patterns have been adopted into native, but surely not everything.
- whatshisface 4y ago
  It has changed a lot over time. Now native JS even has query selectors!
  - simion314 4y ago
    Still not all selectors that are in jQuery , I think :header is not yet native, not the selectors by attribute value.
    - robgibbons 4y ago
      You can select by attribute value. Even "starts with" selectors eg: document.querySelectorAll('[name^="starts-with-this"]') or "containing" selectors: document.querySelectorAll('[name*="contains-this"]')
    - lycos 4y ago
      I believe querySelector/querySelectorAll supports all native CSS selectors, including attribute selectors. But jQuery does hahve custom selectors as well (at least last I used it, which is over 10 years ago)
- bastawhiz 4y ago
  Anything involving multiple elements in a single operation. $('.foo').hide() requires something silly like Array.from(document.querySelectorAll('.foo')).forEach(el => el.style.display = 'none'); Being able to select something, then chain operations on those nodes is really where jQuery shines, IMO. All of the non-DOM stuff (e.g., AJAX) is fine with vanilla JS these days.
jonotime 4y ago
By day I code in react, but I'm working on a side project where I needed to use a specific already developed calendar widget. Found the one I needed and it was written in jquery. I started trying to get react and jquery to get along, but in the end I ended up scrapping react altogether. This of course was not my initial intention.
- wetpaws 4y ago
  Tbh this is not a problem of react
- duxup 4y ago
  I feel like React and JQuery approach things so differently that it almost never should be a question of “Should I use React or JQuery?”…
  - simion314 4y ago
    JQuery had the ideas of creating independent and reusable components, most of the new frameworks encourage a more ugly architecture IMO, though React (the first versions I used) was also good at promoting the idea of independent components. I prefer the idea where a component has no idea about the parents or global state and can only raise events.
    - no_wizard 4y ago
      you might like web components. Their main communication mechanism is leveraging custom events
- diob 4y ago
  Why couldn't you use both? I've never had issues with them together.
  - tofuahdude 4y ago
    Really depends on how they're being used. If they're independently managing their own parts of the DOM, it can work (though still a dev headache imo). If its a "react app", ie react is managing the entire dom, having two representations of the dom is a v bad idea in that one can make changes that the other is unaware of. Or visa versa.
xwdv 4y ago
Too little too late.
- recursive 4y ago
  There was plenty much earlier too, if you'll recall.
blowski 4y ago
The advantage of Vue, Svelte, and React is the neat decoupling of changing state and responding to those changes. jQuery always seemed to end up in long chains of callback hell.
- jabart 4y ago
  JS in ~20020 - Use onclick handlers to respond to user interaction. JS in ~2004 - Use jQuery to decouple your JS from your HTML in separate files. JS in ~2008 - We invented our own onclick handler, embed your JS in your HTML it's fine now. EDIT Spelling
- pantulis 4y ago
  Because it hails from a different and terrible era. It's easy to forget the impact that jQuery had in front-end development.
- wackget 4y ago
  "Decoupling" is not a phrase I'd personally use to describe a benefit of React. Every React example I've seen is a horrific-looking mixture of JavaScript, XML, and HTML all muddled together into a nasty-looking component system. When I was learning front-end development it was an absolute cardinal sin to mix markup, JavaScript, and styling together. Now that seems like the standard practice and I still can't look past it.
  - agumonkey 4y ago
    it's an object metaphor brought to the UI layer, you used to assemble trees of java widgets updated manually, now it's a tree of dom elements with semi infered update graphs
  - papertokyo 4y ago
    Component-based UI libraries/frameworks and the resulting ability to compartmentalize different parts of the app make that adage irrelevant. I agree with your opinion of React/JSX, but the single file components of Vue and Svelte are an absolute joy to work with.
deleted 4y ago
[deleted]
oefrha 4y ago
Just so happens I translated an old JS library from 2013 to modern TypeScript yesterday. It has jQuery, old-style “classes” with prototypes and everything. The language has changed so much in ten years it’s barely recognizable.
omgomgomgomg 4y ago
Sure jQuery as a selector engine has more or less been replaced, css has advanced etc. But the jQuery UI widgets are battle hardened and easier to deploy, case in point , date pickers, calendaries and well, slideshows. And you can kind of replicate some of reacts behaviour regarding state management. If all you need to do is keep state on a handful of elements, there is no need to develop in react. Infact, just like the jquery heydays, react is often overused, for the most simply web forms, menus, footers. And, no need for router and other state management tools. Might be a bit unpopular, but when its all said and done, its compiled to js either way, I kinda like jquery or vanilla js for the front end and node/express for the back end. The amount of react devs which struggle with css and vanilla js appears to be higher than during the jquery days.
- flatiron 4y ago
  My job has a lot of little customers with little projects and some older ones were made with jquery and we keep on keeping on. Why not? Also if we have to make similar projects we branch from older ones. So some of our current development uses jquery which raises some eyebrows but nothing like using 95% battle hardened code than starting fresh because…
- texxtxxet 4y ago
  Why not components from a React library like Material UI? jQuery UI is "in a maintenance state" and "older long-standing bugs may not get fixed" I'm afraid https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/ https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/
  - mattmanser 4y ago
    Why? Material's dead, adding React is adding a massive amount of bloat and build steps. You need to have a reason to pay the price of React. Otherwise you're just being a sheep. I say this using React and Material UI in a present project, from my perspective development for what is a pretty simple form UI is massively slowed down by using them. Could have knocked out the whole site on my own in 1/2 the time using the 'old' stuff. But now we've got a lovely loading spinner while it downloads everything it needs piecemeal and a bunch of basic browser functionality is broken, we've got 10x the amount of code, have to deal with a whole extra API layer and it's a nightmare to debug sitting there watching network calls instead of being able to step through the code in a proper debugger, brilliant stuff. Completely worth it for that one datepicker we have.
texxtxxet 4y ago
CSS variable values are trimmed of whitespace [according to spec]? > Return undefined for whitespace-only CSS variable values I've gotten in the bad habit using of CSS vars for dynamic text, this will shoot me in the foot some day.
- DaiPlusPlus 4y ago
  > I've gotten in the bad habit of CSS vars for dynamic text Can you elaborate on this trick?
  - texxtxxet 4y ago
    Setting the `content` of a pseudo-element (like :before) to a variable with a text value (--sale-text: '50% off!'). I update the value of `--sale-text` to change all elements with that given classname to "25% off!" instead (for ex).
szundi 4y ago
Main reason to use jQuery for small projects: the learning curve is like a dot.
forthorbor 4y ago
In this thread there is a lot of both "you should use this", and "you shouldn't use this". In the end, everyone should evaluate the options for themselves and use what works best for them.
- Eduard 4y ago
  I disagree. Just today I had headache again because of a legacy jQuery-based codebase. The jQuery version is so old, it is a security risk. A pure JavaScript codebase updates itself with each new browser release, so to say. So my verdict: "you shouldn't use jQuery"
synergy20 4y ago
There is jQuery 4.0 in the works(95% done), not sure what new feature it brings. https://github.com/jquery/jquery/milestone/7 https://github.com/jquery/jquery/milestone/7 it's updated a while ago though. alpine.js could be an alternative to jQuery. wonder if jQuery is still used for new projects these days.
- peterangular 4y ago
  Alpine.js has been a wonderful new tool in my arsenal. I prefer lightweight tools that solve big problems while still staying small/simple. Alpine.js really hits that balance for me. The fact I'm able to drop it in without a single Node.js/etc build tooling is astounding (esbuild, rome, etc). I really prefer how it stays true to vanilla JS/general web development while also bringing modern attribute-driven reactivity to the table.
didip 4y ago
I super love jQuery. As an infrastructure engineer with zero interest in Frontend trends, jQuery simply gets the job done.
- flatiron 4y ago
  Someone just today was complaining that css doesn’t have contains. Something as simple as that makes jquery useful. It’s also not a huge library and extremely powerful. It gets a bad rap.
  - Eduard 4y ago
    https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has
    - flatiron 4y ago
      Has does not have the same functionality as jquery contains.
ei8ths 4y ago
jQuery is awesome, use it in most of my projects. Its easy to read.
tegiddrone 4y ago
One of the senior devs at a place I worked at built his own react-like component system using jQuery and they had a couple apps foundationally upon it. I also wound up on a project to help out with a pretty recent greenfield Angular SPA. Turned out actually they just used the router from angular and ejected into jQuery for nearly all component/dom manipulation. Of course everyone else was rolling with it like it was cool or no big deal. PMs were happy with the team's velocity. Times like that make me highly qustion my career choices; especially when their pay scale is similar.

195 points by gslin 4y ago

Feels like Winamp but things eventually evolved on server side. Always welcome on my legacy .net project:)

CM30 4y ago

Sorry if this sounds naive, but... do people still use jQuery for new projects? I was genuinely surprised to see it was getting releases anymore, given how much of its functionality can be done with native JavaScript now.

amflare 4y ago
Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the messier and more complicated elements and giving developers a more intuitive set of tools. Some part of this are less necessary today than when jQuery v1 came out (like `querySelectorAll()` vs `$()`), but other parts are still enormously helpful (like `$.ajax()`). So like always, it's a trade off. But it's still one that comes up as worth it as often as not.
- udp 4y ago
  I’m not sure $.ajax() is a good example now that fetch is widely supported.
- gabereiser 4y ago
  `$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/
  - amflare 4y ago
    That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
    - duskwuff 4y ago
      You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
    - no_way 4y ago
      You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
      - amflare 4y ago
        Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
        LudwigNagasena 4y ago
        Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
    - LudwigNagasena 4y ago
      Babel?
  - Beltalowda 4y ago
    I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
- ssl232 4y ago
  Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.
ericb 4y ago
One thing that gets forgotten about jQuery is that there's a tremendous library of very evolved components in its ecosystem. Sure, "you don't need jQuery" is true, but when you go hunting for components you'd rather not write yourself, man is there still some gravity there. You ask yourself, "do I feel like writing a calendar selector widget today?" Trade some vanity and JavaScript puritanism and the question becomes "what color should I style it?"
kypro 4y ago
I've not used it in a new project for a long time, but I often still work on projects with legacy jQuery code. The main reason to still use it imo it is simply that a lot of devs are familiar with the API and they have really good docs. While I prefer vanilla JS for JS-light projects, I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. The nice thing JQuery is that you know it will work as expected on the all browsers it supports so you don't need to worry about cross-browser testing your code. It also makes certain things easier to do like basic JS animations. The main reason care about the latest releases is that they patch security issues from time to time.
- collyw 4y ago
  > I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. That was the main reason that jQuery got popular if I remember correctly (though I have always been an 85% backend developer). I was under the impression that that isn't really an issue these days, but everyone is building overly complex monstrosities with React or whatever else is flavor of the month.
  - lelandfe 4y ago
    https://webkit.org/blog/12288/working-together-on-interop-2022/ https://webkit.org/blog/12288/working-together-on-interop-20... The various browsers have gotten together and work awfully hard to fix outstanding quirks. You'll still encounter cross-browser oddities here and there, but it's generally more in the order of, "X browser hasn't added this method yet"
  - The_Colonel 4y ago
    Yes, the cross browser weirdness is nothing like it used to be. The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
  - eyelidlessness 4y ago
    I was jQuery’s target audience at its heyday and at least for me, the big thing it brought to the table was $ and what’s now called a “fluent API” ($ methods return $ instances unless they’re getters for primitives; it’s pretty much still my preferred way to explain the general concept of monads to people familiar with the pattern). Browser compatibility was just delicious icing on the cake.
PrivateButts 4y ago
jQuery is like, comfort food for me? Used to use jQuery for everything and now the world's moved on. I wouldn't want to do a large project today in jQuery, but I kinda miss the simpler projects that I used to do all the time with a smaller toolbox.
jrochkind1 4y ago
i don't intentionally write code using JQuery anymore, and find it not very inconvenient to avoid for the most part, even when writing "jquery style" JS -- which I do. Browser API's in recent browsers are good enough. But I'm still using some dependencies that need jquery. I honestly expect I'll never be able to get rid of it.
smallmouth 4y ago
Apology accepted, and absolutely! Myself and two other developers just kicked off a very non-tivial, data-heavy application for a Dow 30 that will be used by a maximum of 12,000 users. Using jquery will help us avoid a lot of thinking and testing time with the whole "gee, how would I do that in vanilla, let me look that up" process.
deleted 4y ago
[deleted]
pier25 4y ago
jQuery is more popular than React by pretty much any metric you can find
- collyw 4y ago
  for starting new projects?
  - kbrannigan 4y ago
    Beginers and aspiring sofware developers tends to use the most popular technology, evangelized by the biggest companies. Since they don't know any better, they equate MOST POPULAR with BEST. Sometimes all you need is a wheelbarrow, you don't need a tractor.
    - collyw 4y ago
      BEST is highly subjective. Most popular has a number of advantages- more developers, likely cheaper developers, bigger community but for most cases I am in agreement with you
  - pier25 4y ago
    Yeah. There are probably more new projects started with Wordpress themes that use jQuery than React projects. And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC. If you don't need a super sophisticated frontend, jQuery is still one of the best tools around. People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.
thejammahimself 4y ago
Yeah a good few years ago, before I had learnt about frameworks like React, I used JQuery for one of my projects. Once I learned about React, I decided to rewrite this project using that instead, and afterwards I felt that the React version was very obviously the superior version. I just feel like we now have better options, and I still really like React's way of handling state in a moreso functional way.
tsian2 4y ago
I find it much quicker to write and neater to read than vanilla JS. I optimise afterwards and might consider swapping it out but it's usually low down the list of performance issues. Although it can be a bigger issue if you don't know how select things and store those selections efficiently with it.
jabart 4y ago
Bootstrap 4 uses jquery, bootstrap 5 was released (not beta) May 5, 2021. So, anything started with Bootstrap 4 would use it.
yokoprime 4y ago
I only encounter it when maintaining old codebases. Never for anything new
ww520 4y ago
Yes. I do still use it.
Alupis 4y ago
The API jQuery gives you is still so much nicer than regular javascript, even with modern ECMAScript 7+... While we're at it - Bootstrap (and similar css frameworks) are still much nicer to use than native CSS, even with modern CSS3 and flexbox... It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because.
- eyelidlessness 4y ago
  > It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle. Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces. More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
  - Alupis 4y ago
    Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
progmetaldev 4y ago
I am still using jQuery because I have so many plugins such as calendars, photo galleries, video galleries, and file explorer type trees that are all progressively enhanced, it would be a ton of work to rebuild everything. I think jQuery is still does a great job for progressive enhancement of CMS/informational type websites.
bigger_cheese 4y ago
I used jQuery earlier this year. I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it. I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers. One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format. So I just used the JQuery calendar picker took me two seconds and problem solved.
tambourine_man 4y ago
It always could be done in JavaScript, jQuery is written on it after all. It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.
deterministic 4y ago
Yep. It is the first package I install on a new project. Followed by React.
PointyFluff 4y ago

irrational 4y ago

I'm aware of "You might not need jQuery", but has anyone created a comprehensive list of everything jQuery offers that is not available through native JS/CSS? I guess I should specify, not available as easy as jQuery. Technically anything that jQuery does can, obviously, be done natively, but I remember there were some things that were much much much easier to do in jQuery than natively. Some of those easy patterns have been adopted into native, but surely not everything.

whatshisface 4y ago
It has changed a lot over time. Now native JS even has query selectors!
- simion314 4y ago
  Still not all selectors that are in jQuery , I think :header is not yet native, not the selectors by attribute value.
  - robgibbons 4y ago
    You can select by attribute value. Even "starts with" selectors eg: document.querySelectorAll('[name^="starts-with-this"]') or "containing" selectors: document.querySelectorAll('[name*="contains-this"]')
  - lycos 4y ago
    I believe querySelector/querySelectorAll supports all native CSS selectors, including attribute selectors. But jQuery does hahve custom selectors as well (at least last I used it, which is over 10 years ago)
bastawhiz 4y ago
Anything involving multiple elements in a single operation. $('.foo').hide() requires something silly like Array.from(document.querySelectorAll('.foo')).forEach(el => el.style.display = 'none'); Being able to select something, then chain operations on those nodes is really where jQuery shines, IMO. All of the non-DOM stuff (e.g., AJAX) is fine with vanilla JS these days.

jonotime 4y ago

By day I code in react, but I'm working on a side project where I needed to use a specific already developed calendar widget. Found the one I needed and it was written in jquery. I started trying to get react and jquery to get along, but in the end I ended up scrapping react altogether. This of course was not my initial intention.

wetpaws 4y ago
Tbh this is not a problem of react
duxup 4y ago
I feel like React and JQuery approach things so differently that it almost never should be a question of “Should I use React or JQuery?”…
- simion314 4y ago
  JQuery had the ideas of creating independent and reusable components, most of the new frameworks encourage a more ugly architecture IMO, though React (the first versions I used) was also good at promoting the idea of independent components. I prefer the idea where a component has no idea about the parents or global state and can only raise events.
  - no_wizard 4y ago
    you might like web components. Their main communication mechanism is leveraging custom events
diob 4y ago
Why couldn't you use both? I've never had issues with them together.
- tofuahdude 4y ago
  Really depends on how they're being used. If they're independently managing their own parts of the DOM, it can work (though still a dev headache imo). If its a "react app", ie react is managing the entire dom, having two representations of the dom is a v bad idea in that one can make changes that the other is unaware of. Or visa versa.

xwdv 4y ago

Too little too late.

recursive 4y ago
There was plenty much earlier too, if you'll recall.

blowski 4y ago

The advantage of Vue, Svelte, and React is the neat decoupling of changing state and responding to those changes. jQuery always seemed to end up in long chains of callback hell.

jabart 4y ago
JS in ~20020 - Use onclick handlers to respond to user interaction. JS in ~2004 - Use jQuery to decouple your JS from your HTML in separate files. JS in ~2008 - We invented our own onclick handler, embed your JS in your HTML it's fine now. EDIT Spelling
pantulis 4y ago
Because it hails from a different and terrible era. It's easy to forget the impact that jQuery had in front-end development.
wackget 4y ago
"Decoupling" is not a phrase I'd personally use to describe a benefit of React. Every React example I've seen is a horrific-looking mixture of JavaScript, XML, and HTML all muddled together into a nasty-looking component system. When I was learning front-end development it was an absolute cardinal sin to mix markup, JavaScript, and styling together. Now that seems like the standard practice and I still can't look past it.
- agumonkey 4y ago
  it's an object metaphor brought to the UI layer, you used to assemble trees of java widgets updated manually, now it's a tree of dom elements with semi infered update graphs
- papertokyo 4y ago
  Component-based UI libraries/frameworks and the resulting ability to compartmentalize different parts of the app make that adage irrelevant. I agree with your opinion of React/JSX, but the single file components of Vue and Svelte are an absolute joy to work with.

deleted 4y ago

[deleted]

oefrha 4y ago

Just so happens I translated an old JS library from 2013 to modern TypeScript yesterday. It has jQuery, old-style “classes” with prototypes and everything. The language has changed so much in ten years it’s barely recognizable.

omgomgomgomg 4y ago

Sure jQuery as a selector engine has more or less been replaced, css has advanced etc. But the jQuery UI widgets are battle hardened and easier to deploy, case in point , date pickers, calendaries and well, slideshows. And you can kind of replicate some of reacts behaviour regarding state management. If all you need to do is keep state on a handful of elements, there is no need to develop in react. Infact, just like the jquery heydays, react is often overused, for the most simply web forms, menus, footers. And, no need for router and other state management tools. Might be a bit unpopular, but when its all said and done, its compiled to js either way, I kinda like jquery or vanilla js for the front end and node/express for the back end. The amount of react devs which struggle with css and vanilla js appears to be higher than during the jquery days.

flatiron 4y ago
My job has a lot of little customers with little projects and some older ones were made with jquery and we keep on keeping on. Why not? Also if we have to make similar projects we branch from older ones. So some of our current development uses jquery which raises some eyebrows but nothing like using 95% battle hardened code than starting fresh because…
texxtxxet 4y ago
Why not components from a React library like Material UI? jQuery UI is "in a maintenance state" and "older long-standing bugs may not get fixed" I'm afraid https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/ https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/
- mattmanser 4y ago
  Why? Material's dead, adding React is adding a massive amount of bloat and build steps. You need to have a reason to pay the price of React. Otherwise you're just being a sheep. I say this using React and Material UI in a present project, from my perspective development for what is a pretty simple form UI is massively slowed down by using them. Could have knocked out the whole site on my own in 1/2 the time using the 'old' stuff. But now we've got a lovely loading spinner while it downloads everything it needs piecemeal and a bunch of basic browser functionality is broken, we've got 10x the amount of code, have to deal with a whole extra API layer and it's a nightmare to debug sitting there watching network calls instead of being able to step through the code in a proper debugger, brilliant stuff. Completely worth it for that one datepicker we have.

texxtxxet 4y ago

CSS variable values are trimmed of whitespace [according to spec]? > Return undefined for whitespace-only CSS variable values I've gotten in the bad habit using of CSS vars for dynamic text, this will shoot me in the foot some day.

DaiPlusPlus 4y ago
> I've gotten in the bad habit of CSS vars for dynamic text Can you elaborate on this trick?
- texxtxxet 4y ago
  Setting the `content` of a pseudo-element (like :before) to a variable with a text value (--sale-text: '50% off!'). I update the value of `--sale-text` to change all elements with that given classname to "25% off!" instead (for ex).

szundi 4y ago

Main reason to use jQuery for small projects: the learning curve is like a dot.

forthorbor 4y ago

In this thread there is a lot of both "you should use this", and "you shouldn't use this". In the end, everyone should evaluate the options for themselves and use what works best for them.

Eduard 4y ago
I disagree. Just today I had headache again because of a legacy jQuery-based codebase. The jQuery version is so old, it is a security risk. A pure JavaScript codebase updates itself with each new browser release, so to say. So my verdict: "you shouldn't use jQuery"

synergy20 4y ago

There is jQuery 4.0 in the works(95% done), not sure what new feature it brings. https://github.com/jquery/jquery/milestone/7 https://github.com/jquery/jquery/milestone/7 it's updated a while ago though. alpine.js could be an alternative to jQuery. wonder if jQuery is still used for new projects these days.

peterangular 4y ago
Alpine.js has been a wonderful new tool in my arsenal. I prefer lightweight tools that solve big problems while still staying small/simple. Alpine.js really hits that balance for me. The fact I'm able to drop it in without a single Node.js/etc build tooling is astounding (esbuild, rome, etc). I really prefer how it stays true to vanilla JS/general web development while also bringing modern attribute-driven reactivity to the table.

didip 4y ago

I super love jQuery. As an infrastructure engineer with zero interest in Frontend trends, jQuery simply gets the job done.

flatiron 4y ago
Someone just today was complaining that css doesn’t have contains. Something as simple as that makes jquery useful. It’s also not a huge library and extremely powerful. It gets a bad rap.
- Eduard 4y ago
  https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has
  - flatiron 4y ago
    Has does not have the same functionality as jquery contains.

ei8ths 4y ago

jQuery is awesome, use it in most of my projects. Its easy to read.

tegiddrone 4y ago

One of the senior devs at a place I worked at built his own react-like component system using jQuery and they had a couple apps foundationally upon it. I also wound up on a project to help out with a pretty recent greenfield Angular SPA. Turned out actually they just used the router from angular and ejected into jQuery for nearly all component/dom manipulation. Of course everyone else was rolling with it like it was cool or no big deal. PMs were happy with the team's velocity. Times like that make me highly qustion my career choices; especially when their pay scale is similar.