9 ms·

Every time I use jQuery after helping my friends battle Reactive monsters, I am so eternally grateful that I have such a productive and satisfying tool at my di

Every time I use jQuery after helping my friends battle Reactive monsters, I am so eternally grateful that I have such a productive and satisfying tool at my disposal. It requires zero bike-shedding and almost every imaginable edge-case is solved before I start. If it ends up sucking, it's because I made it suck. Just to abuse metaphors, I believe that jQuery is a "bicycle for the mind" in the true Steve Jobs sense. If you don't love it, please knock yourself out or try an edgier SPA. Spend all of your free time learning how Hooks just made everything you were excited about obsolete. The pool is warm and the weather is lovely, friends.

KajMagnus 8y ago
I migrated from jQuery to React, never going back and I wouldn't use jQuery for a new project. I agree that jQuery is ok for simple things, however I'd probably prefer something more light weight, like Bliss.js instead. jQuery's 30kb bundle size does make pages load slightly slightly slower on mobile phones, in comparison to Bliss (about 3kb last time I checked).
- sebazzz 8y ago
  Migrate from jQuery to React. You make it sound trivial but it is essentially a complete new way of developing the front-end. Not necessarily a SPA, but certainly a front-end with more interactivity than a few buttons and dialogs. In my experience React front-ends are more driven by separate data retrieved and stored at the server, while jQuery front-ends are mostly server-side rendered and jQuery is used for some degree of dynamic flexibility.
  - austincheney 8y ago
    Have you considered authoring code without either of those tools? Then you can independently add in the appropriate tool to adjust for efficiency. Thinking in terms of the tooling first is premature optimization. Focus on the end product first, and the correct tooling (if any) will be clear.
    - Spivak 8y ago
      I honestly don't think that dev workflow is even possible with most frameworks. It's not like you can take an existing website and add interactivity or extend the existing interactivity with React. The current landscape of web tools is pretty much that you have to call your shot from the beginning or suffer a rewrite later.
      - austincheney 8y ago
        That is certainly true once a framework is chosen, but before that you can prototype in many directions and extends in pieces. Extending a site to use a framework is not all or nothing.
- nerdwaller 8y ago
  You seem to assume that jquery isn’t already cached by the client. Given the widespread usage, while granted may be shrinking, the “bundle” may never be downloaded again; Assuming that’s the case, the download is moot, and more favorable, verses the SPA with some cache busting mechanism (that may release once per week or once per hour).
  - jcutrell 8y ago
    This is very rarely true, and often cited. Too many sources to get reasonable gains for cached jQuery. There was a good article breaking down exactly why this is a few years back. Mobile but someone else can probably share.
    - peteforde 8y ago
      As cited elsewhere in this thread, jQuery is in use on >75% of the web. The only way you don't have jQuery cached is if you don't regularly use the web.
      - austincheney 8y ago
        Which version cached?
        DCoder 8y ago
        And from which CDN?
        GordonS 8y ago
        There are only a handful of major CDNs
      - extra88 8y ago
        Other sites' use of jQuery only helps if everyone is loading the same URL, which they're not. There are too many versions in too many places. I think I know the article they were thinking of, where someone tested how common it was for different sites to load libraries from the same place, it was not great. jQuery.com doesn't mention linking to it, only downloading, and references to their CDN and other CDNs is at the bottom of their Download page. They focus on the download option probably because people generally want to have more control of their sites and would rather have "their" jQuery file be loaded from the same CDN as their site's other assets.
- EB66 8y ago
  jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular or React even existed. More recently, we've built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS. We recently open sourced the framework: http://github.com/elliotnb/nimbly http://github.com/elliotnb/nimbly
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - mtzaldo 8y ago
    I mixed jquery + redux. I only use those 2 libs: https://github.com/mtzaldo/jqueryredux https://github.com/mtzaldo/jqueryredux
- hpaavola 8y ago
  Minified jquery (https://code.jquery.com/jquery-3.3.0.min.js https://code.jquery.com/jquery-3.3.0.min.js) is 86 927 bytes and minified bliss (https://blissfuljs.com/bliss.min.js https://blissfuljs.com/bliss.min.js) is 11 823 bytes. After gzipping those with 7-zip (on windows now, too lazy to do anything other) the sizes are 4 035 bytes for bliss and 29 495 bytes for jquery. The same in table: minified min+gzip jquery 86 927 29 495 bliss 11 823 4 035
- baddox 8y ago
  Another vote for React here. I wouldn’t let jQuery anywhere near an app I was responsibility for. It’s a great and really well thought out tool for doing things that I absolutely never ever want to do in any non-trivial app I work on.
rajangdavis 8y ago
I think it's not really needed in today's browser landscape unless you're working on a team that uses it. I prefer fetch, document.querySelectorAll, and animate.css for 90% of what you would need with jQuery.
- peteforde 8y ago
  While I respect that this comment is an expression of your lived experience (after all, I used the word believe so this is fair game) I am compelled to point out that when you say "of what you would need with jQuery", what you really mean is "what I would need with jQuery". You know how there's ~3 kinds of Excel users? You have your formatted rows and columns types, people like me that can use SUM(), call APIs and know what pivot tables are... and then there are those ninjas that can implement ray-traced dungeon renderers in a cell. https://www.youtube.com/watch?v=iCeOEQVUWZ0 https://www.youtube.com/watch?v=iCeOEQVUWZ0 I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. As a final note, I am excited that things which once required jQuery are now being solved by the browser and the evolving EcmaScript standard. Ideally, jQuery continues to get smaller and smaller. However, it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms. Proof: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ I do really like fetch and async/await in general, and working in React has taught me lots of cool tricks to bring back to my real projects. I think everyone should try to build something real with React, just to understand how lucky they are to have the option not to use it.
  - revvx 8y ago
    > I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)
hinkley 8y ago
The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results. More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship. Biggest category of bugs I had to help people with, aside from performance regressions from abusing reflow. As hardships go, I’ve had worse with other frameworks. But if I could g9 back in time or if I were trying to make a workalike...
- masklinn 8y ago
  > The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results. The set-operatic approach of jquery is one I absolutely love about it, though it does lead to unforeseen behaviours in edge cases (sometimes performance concerns running code on nothing or on way more than expected) it's leads to extremely convenient and fluent code, much more so than the explicit iterations of the normal DOM. > More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship. Extending jquery to assert a lower bound (and even an upper bound as well) wouldn't be a hardship either.
  - hinkley 8y ago
    A few years before I encountered jQuery, I found an experimental programming language that tried to do away with the distinction between variables that contained 0-1 values and those that contain 0-n. In this language, all operations were set operations. When your data model changed from 1:1 to 1:n (classic example - user:address is probably the concept I’ve seen mis-modeled the most often). So when I saw jQuery for the first time, I’d already been primed for this concept. I’m a little surprised it’s been used so infrequently.
ramblerman 8y ago
> almost every imaginable edge-case is solved before I start I think you are comparing apples and oranges. Jquery is absolutely awesome for automating parts of your pages, and/or adding substantial interactivity. If you are building an actual SPA, as in application (think gmail and the like) you wouldn't want to use jquery.
- peteforde 8y ago
  Correct: I wouldn't want to use jQuery without also installing Turbolinks 5 and Stimulus.
benbristow 8y ago
How is using jQuery more satisfying and productive than using something like React? You spend 10 times more time writing so much more code having to make the UI 'react' to the changes that you wish to see. With React/Vue/Angular it's just a case of adding a conditional. With jQuery you've gotta do something like jQuery('.this').hide(); jQuery('.that').show(); jQuery('.thisotherthing').show(); Gets really confusing, hard to test and hard to maintain. Then when you want to do things with fancy selects and dynamic option choices and all that good stuff it just gets even more unruly. With modern JS frameworks you declare a state and your UI reflects your state. Rather than with jQuery having to manage both the state and the UI all at the same time. I'm forced to use nothing but jQuery at work so I'm quite competent with it so it's not from lack of experience. It provides nothing but pain and misery.
- romanovcode 8y ago
  So what you are saying is that if you want to show/hide something dynamically on the webpage you should use React? lol Also, maybe it is from lack of experience. Because you can add classes to your elements and depending on them you can hide/show all of them with just $('.toggle-element').toggle();
  - benbristow 8y ago
    Well it gets more complex when there’s more business rules. Like if you have 1 checkbox checked need to show this one bit but if you have 2 need to show all of them. It’s just an example. Trying to scope it all gets a bit unruly too. Your example would target every element on the page. If you have nested components it’s a nightmare.
- labster 8y ago
  For the example above, you could collapse to: $('.this, .that, .thisotherthing').toggle(); Or if you're looking to throw in a conditional, toggle takes a boolean argument: $('.this').toggle( foo === undefined ); Really it depends so much more on whether or not you're designing a single page app or have some interactive elements on an isolated webpage. Use the correct tool for the correct job.
AriaMinaei 8y ago
You're setting a very low bar for accepting something as "bicycle of the mind." The researchers in PL and HCI would vehemently disagree.
kaishiro 8y ago
I find this comment fascinating. I actually love your passion for the lib - I think any tool that makes a person feel productive is a positive thing. But it also makes me realize just how diverse the front end ecosystem is. Since moving to more reactive, state based frameworks I haven't even thought about DOM manipulation in so long - that to see people discussing the merits of one system over another is pretty wild.
- fxbl0i 8y ago
  I assume people who don't think about DOM manipulation and the performance toll it takes are responsible for how slow the web is today and, what's even worse, how that waste of CPU has been pushed from the server to the client.
  - ryanbrunner 8y ago
    There's downsides with every approach though. While taking a "render HTML and manipulate DOM" approach falls down hard when the DOM mutations become frequent or complicated enough that they take a performance toll, the alternative most commonly peddled, "ship JSON and let the client render everything" has increased in massively increased JS bundle sizes and horrendous initial load performance on many sites. I suppose there's the alternative of "ship HTML and forget about Javascript for the most part", but very, very few people are following that nowadays, and besides which, JQuery supports a "Javascript not required" progressive enhancement model far far more than most other front-end frameworks.
    - keanebean86 8y ago
      I wrote a spa at my last job using jQuery. It rendered page fragments on a php backend, detached the current fragment, saved it, then appended the new fragment. If a fragment was already downloaded it would hydrate by ajaxing some json. It was extra work and sometimes brittle but it was also my first "big" web project. Even though it didn't use all the cool new libs and build tools I still learned a lot from it.
deleted 8y ago
[deleted]

KajMagnus 8y ago

I migrated from jQuery to React, never going back and I wouldn't use jQuery for a new project. I agree that jQuery is ok for simple things, however I'd probably prefer something more light weight, like Bliss.js instead. jQuery's 30kb bundle size does make pages load slightly slightly slower on mobile phones, in comparison to Bliss (about 3kb last time I checked).

sebazzz 8y ago
Migrate from jQuery to React. You make it sound trivial but it is essentially a complete new way of developing the front-end. Not necessarily a SPA, but certainly a front-end with more interactivity than a few buttons and dialogs. In my experience React front-ends are more driven by separate data retrieved and stored at the server, while jQuery front-ends are mostly server-side rendered and jQuery is used for some degree of dynamic flexibility.
- austincheney 8y ago
  Have you considered authoring code without either of those tools? Then you can independently add in the appropriate tool to adjust for efficiency. Thinking in terms of the tooling first is premature optimization. Focus on the end product first, and the correct tooling (if any) will be clear.
  - Spivak 8y ago
    I honestly don't think that dev workflow is even possible with most frameworks. It's not like you can take an existing website and add interactivity or extend the existing interactivity with React. The current landscape of web tools is pretty much that you have to call your shot from the beginning or suffer a rewrite later.
    - austincheney 8y ago
      That is certainly true once a framework is chosen, but before that you can prototype in many directions and extends in pieces. Extending a site to use a framework is not all or nothing.
nerdwaller 8y ago
You seem to assume that jquery isn’t already cached by the client. Given the widespread usage, while granted may be shrinking, the “bundle” may never be downloaded again; Assuming that’s the case, the download is moot, and more favorable, verses the SPA with some cache busting mechanism (that may release once per week or once per hour).
- jcutrell 8y ago
  This is very rarely true, and often cited. Too many sources to get reasonable gains for cached jQuery. There was a good article breaking down exactly why this is a few years back. Mobile but someone else can probably share.
  - peteforde 8y ago
    As cited elsewhere in this thread, jQuery is in use on >75% of the web. The only way you don't have jQuery cached is if you don't regularly use the web.
    - austincheney 8y ago
      Which version cached?
      - DCoder 8y ago
        And from which CDN?
        GordonS 8y ago
        There are only a handful of major CDNs
    - extra88 8y ago
      Other sites' use of jQuery only helps if everyone is loading the same URL, which they're not. There are too many versions in too many places. I think I know the article they were thinking of, where someone tested how common it was for different sites to load libraries from the same place, it was not great. jQuery.com doesn't mention linking to it, only downloading, and references to their CDN and other CDNs is at the bottom of their Download page. They focus on the download option probably because people generally want to have more control of their sites and would rather have "their" jQuery file be loaded from the same CDN as their site's other assets.
EB66 8y ago
jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular or React even existed. More recently, we've built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS. We recently open sourced the framework: http://github.com/elliotnb/nimbly http://github.com/elliotnb/nimbly
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- mtzaldo 8y ago
  I mixed jquery + redux. I only use those 2 libs: https://github.com/mtzaldo/jqueryredux https://github.com/mtzaldo/jqueryredux
hpaavola 8y ago
Minified jquery (https://code.jquery.com/jquery-3.3.0.min.js https://code.jquery.com/jquery-3.3.0.min.js) is 86 927 bytes and minified bliss (https://blissfuljs.com/bliss.min.js https://blissfuljs.com/bliss.min.js) is 11 823 bytes. After gzipping those with 7-zip (on windows now, too lazy to do anything other) the sizes are 4 035 bytes for bliss and 29 495 bytes for jquery. The same in table: minified min+gzip jquery 86 927 29 495 bliss 11 823 4 035
baddox 8y ago
Another vote for React here. I wouldn’t let jQuery anywhere near an app I was responsibility for. It’s a great and really well thought out tool for doing things that I absolutely never ever want to do in any non-trivial app I work on.

rajangdavis 8y ago

I think it's not really needed in today's browser landscape unless you're working on a team that uses it. I prefer fetch, document.querySelectorAll, and animate.css for 90% of what you would need with jQuery.

peteforde 8y ago
While I respect that this comment is an expression of your lived experience (after all, I used the word believe so this is fair game) I am compelled to point out that when you say "of what you would need with jQuery", what you really mean is "what I would need with jQuery". You know how there's ~3 kinds of Excel users? You have your formatted rows and columns types, people like me that can use SUM(), call APIs and know what pivot tables are... and then there are those ninjas that can implement ray-traced dungeon renderers in a cell. https://www.youtube.com/watch?v=iCeOEQVUWZ0 https://www.youtube.com/watch?v=iCeOEQVUWZ0 I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. As a final note, I am excited that things which once required jQuery are now being solved by the browser and the evolving EcmaScript standard. Ideally, jQuery continues to get smaller and smaller. However, it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms. Proof: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ I do really like fetch and async/await in general, and working in React has taught me lots of cool tricks to bring back to my real projects. I think everyone should try to build something real with React, just to understand how lucky they are to have the option not to use it.
- revvx 8y ago
  > I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)

hinkley 8y ago

The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results. More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship. Biggest category of bugs I had to help people with, aside from performance regressions from abusing reflow. As hardships go, I’ve had worse with other frameworks. But if I could g9 back in time or if I were trying to make a workalike...

masklinn 8y ago
> The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results. The set-operatic approach of jquery is one I absolutely love about it, though it does lead to unforeseen behaviours in edge cases (sometimes performance concerns running code on nothing or on way more than expected) it's leads to extremely convenient and fluent code, much more so than the explicit iterations of the normal DOM. > More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship. Extending jquery to assert a lower bound (and even an upper bound as well) wouldn't be a hardship either.
- hinkley 8y ago
  A few years before I encountered jQuery, I found an experimental programming language that tried to do away with the distinction between variables that contained 0-1 values and those that contain 0-n. In this language, all operations were set operations. When your data model changed from 1:1 to 1:n (classic example - user:address is probably the concept I’ve seen mis-modeled the most often). So when I saw jQuery for the first time, I’d already been primed for this concept. I’m a little surprised it’s been used so infrequently.

ramblerman 8y ago

> almost every imaginable edge-case is solved before I start I think you are comparing apples and oranges. Jquery is absolutely awesome for automating parts of your pages, and/or adding substantial interactivity. If you are building an actual SPA, as in application (think gmail and the like) you wouldn't want to use jquery.

peteforde 8y ago
Correct: I wouldn't want to use jQuery without also installing Turbolinks 5 and Stimulus.

benbristow 8y ago

How is using jQuery more satisfying and productive than using something like React? You spend 10 times more time writing so much more code having to make the UI 'react' to the changes that you wish to see. With React/Vue/Angular it's just a case of adding a conditional. With jQuery you've gotta do something like jQuery('.this').hide(); jQuery('.that').show(); jQuery('.thisotherthing').show(); Gets really confusing, hard to test and hard to maintain. Then when you want to do things with fancy selects and dynamic option choices and all that good stuff it just gets even more unruly. With modern JS frameworks you declare a state and your UI reflects your state. Rather than with jQuery having to manage both the state and the UI all at the same time. I'm forced to use nothing but jQuery at work so I'm quite competent with it so it's not from lack of experience. It provides nothing but pain and misery.

romanovcode 8y ago
So what you are saying is that if you want to show/hide something dynamically on the webpage you should use React? lol Also, maybe it is from lack of experience. Because you can add classes to your elements and depending on them you can hide/show all of them with just $('.toggle-element').toggle();
- benbristow 8y ago
  Well it gets more complex when there’s more business rules. Like if you have 1 checkbox checked need to show this one bit but if you have 2 need to show all of them. It’s just an example. Trying to scope it all gets a bit unruly too. Your example would target every element on the page. If you have nested components it’s a nightmare.
labster 8y ago
For the example above, you could collapse to: $('.this, .that, .thisotherthing').toggle(); Or if you're looking to throw in a conditional, toggle takes a boolean argument: $('.this').toggle( foo === undefined ); Really it depends so much more on whether or not you're designing a single page app or have some interactive elements on an isolated webpage. Use the correct tool for the correct job.

AriaMinaei 8y ago

You're setting a very low bar for accepting something as "bicycle of the mind." The researchers in PL and HCI would vehemently disagree.

kaishiro 8y ago

I find this comment fascinating. I actually love your passion for the lib - I think any tool that makes a person feel productive is a positive thing. But it also makes me realize just how diverse the front end ecosystem is. Since moving to more reactive, state based frameworks I haven't even thought about DOM manipulation in so long - that to see people discussing the merits of one system over another is pretty wild.

fxbl0i 8y ago
I assume people who don't think about DOM manipulation and the performance toll it takes are responsible for how slow the web is today and, what's even worse, how that waste of CPU has been pushed from the server to the client.
- ryanbrunner 8y ago
  There's downsides with every approach though. While taking a "render HTML and manipulate DOM" approach falls down hard when the DOM mutations become frequent or complicated enough that they take a performance toll, the alternative most commonly peddled, "ship JSON and let the client render everything" has increased in massively increased JS bundle sizes and horrendous initial load performance on many sites. I suppose there's the alternative of "ship HTML and forget about Javascript for the most part", but very, very few people are following that nowadays, and besides which, JQuery supports a "Javascript not required" progressive enhancement model far far more than most other front-end frameworks.
  - keanebean86 8y ago
    I wrote a spa at my last job using jQuery. It rendered page fragments on a php backend, detached the current fragment, saved it, then appended the new fragment. If a fragment was already downloaded it would hydrate by ajaxing some json. It was extra work and sometimes brittle but it was also my first "big" web project. Even though it didn't use all the cool new libs and build tools I still learned a lot from it.

deleted 8y ago

[deleted]