11 ms·

The history and legacy of jQuery

124 points by blast 7y ago

onion2k 7y ago
... and plenty of developers prefer using its API even when native methods are available. jQuery is great, and it's still a really useful library in some circumstances such as supporting incredibly old browsers, but if you're adding 30kb of weight to a page because you don't want to learn the fetch API then you really need to rethink how you think about users.
- kroboker 7y ago
  Agreed. I've seen numerous times developers include jquery just to make a simple request that can be replaced by XMLHttpRequest. Ref: http://youmightnotneedjquery.com http://youmightnotneedjquery.com
  - yyyk 7y ago
    That site looks more like an secret advert for jQuery than any attempt to remove it. Maybe a comparison using more modern browsers would be more convincing...
    - Carpetsmoker 7y ago
      A friend of mine created a spoof to make exactly this point: https://youmightneedjquery.com/ https://youmightneedjquery.com/
  - cm2187 7y ago
    What strikes me with this youmightnotneedjquery is that half of the examples take many more lines of code than a single jquery instruction.
    - archie2 7y ago
      Especially when it comes to browser support...why would I not use JQuery in those cases? I still use JQuery to this day, but probably because I don't really rely on JS in my applications that much. Unless you're building an "app" from the get-go, it's still my default choice.
  - Silhouette 7y ago
    Even the information on that page is quite dated now, as IE becomes less relevant. As others have said, some of its examples were ironically pretty good adverts for jQuery at the time it was first published. However, you hardly ever need to use an XMLHttpRequest any more, and the native Fetch API is already as simple as jQuery's interface for most day-to-day tasks. The only major browser that doesn't support Fetch is IE, and if you still need to support IE for now, you might be better off with a simple polyfill for the standard Fetch API rather than coding around jQuery. Similarly, there is no need for monstrosities like calling Array.prototype.forEach.call on a NodeList returned by querySelectorAll instead of jQuery's $.each any more. Again, everything except IE supports forEach directly on a NodeList, and if you still need IE support, you can use a simple polyfill. If you need a real array to work with, an ES6 spread operator will build this for you with something like [...document.querySelectorAll('.someClass')] since the NodeList is iterable these days too.
- baxtr 7y ago
  Maybe jQuery should be simply included in browsers.
  - nobleach 7y ago
    What is jQuery though? From the author's standpoint, it was a library built to smooth out the edges of bad browser support. This is a problem that doesn't exist as much these days. If you're looking for a way to select one or more DOM nodes and manipulate or jack content into it/them, browsers already provide an easy way to do that now days. The other abstractions it provides ($.get/$.getJson, $.each) have no reason to exist anymore. What's worse, the entire promise-like ability in jQuery is incorrect. (but has to be maintained for backward compatibility) So we're left with what? The $? One could simply do `const $ = document.querySelectorAll;` and get quite a bit of the functionality (I wouldn't really recommend this as it's not a drop-in replacement) Now if we mean the entire jQuery ecosystem. Please.... NO! Tons of bloated non-performant libraries for things like carousels... when a simple `overflow: scroll` could have worked. It was such a nightmare to deal with on mobile devices!
- goto11 7y ago
  There is more to it than "wanting to learn". You can peruse Can I Use https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch to evaluate if the API is widely enough supported to be viable. Then you have to figure out which bugs and incompatibilities exist across browsers. If you look at http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ you will notice that the native approach is at best similar to jQuery, but in many cases more cumbersome and verbose. 30kb is completely insignificant. Using jQuery is just easier and less risk.
  - davidweatherall 7y ago
    A fetch polyfill can be added to a project for ~500 bytes[1] vs jQuery which is ~30kB [2] - or if you were to import just the ajax element from jQuery it would be 13kB [3] And by correctly using polyfills only on browsers that don't support native fetch, the majority of your users (chrome/safari/firefox) won't have any extra dependencies by using fetch, whereas jQuery will need to be loaded on every browser that hits your site. [1] https://bundlephobia.com/result?p=unfetch@4.1.0 https://bundlephobia.com/result?p=unfetch@4.1.0 [2] https://bundlephobia.com/result?p=jquery@3.4.1 https://bundlephobia.com/result?p=jquery@3.4.1 [3] https://www.telerik.com/blogs/jquery-using-only-what-you-need https://www.telerik.com/blogs/jquery-using-only-what-you-nee...
    - goto11 7y ago
      Just for comparison, the "favicon" for Hacker News is 7.66 KB. Does the size of jQuery really matter for a typical web site? If you have just a typical size logo, it will dwarf the size of jQuery, never mind if you have some illustrations or photos.
      - davidweatherall 7y ago
        I agree there are often more important performance issues on sites, especially with images, but that doesn't mean we should completely ignore javascript bundle sizes. In modern sites if javascript doesn't load sites then become non functional, e.g. navs don't work, some SPAs won't work at all. Whereas an image or favicon taking a long time to load shouldn't stop the user from being able to functionally view most of the site.
- jasim 7y ago
  That might be false economy. Most images in a page would come above 30kb. I've seen 3rd party widgets for chat and support sometimes bundle their own copy of the React framework, not to mention huge chunks of CSS, most of which are unused.
  - yazboo 7y ago
    If you're putting jQuery in your main application bundle then it has to be parsed and executed before you can do anything. That's not the same as an equivalent sized image which just needs to be decoded and painted. If it's a chat widget hopefully you're loading it separately. I agree that CSS can also be a problem.
    - hdfbdtbcdg 7y ago
      Pretty sure serverside rendered html works just fine before JavaScript is parsed and executed..
- iforgotpassword 7y ago
  Tbh, I still prefer a "classic" no-bullshit website that depends on jQuery just because the dev likes it a thousand times over the modern overloaded "just-because" SPA that depends on five dozen Js frameworks that were hip the day that page was created.
  - DanielBMarkham 7y ago
    Yes. We've got an entire generation of front-end guys tooled up with awesome-looking IDEs and six hundred npm packages creating sites that need none of that. Each of these packages has dependencies, bugs, security issues, their own roadmaps, and so on. I believe in brutally low overhead websites, but I'd still use JQuery if I had to. It's one of a very few things that just make sense no matter what you're doing, and combined with CDNs and cache reloads, you're highly unlikely to be pulling even that 30k over the wire when you use it. We're going to make a ton of super-cool websites using the new stuff we have. Meanwhile we're also going to make a ton of messes. The cool kids will move on to more tools and gadgets. The second-string bunch will be left struggling to maintain. At some point there'll have to be a huge clean up. Consultants will make lots of money. Many of these consultants will be the people selling us all this crap we don't need right now. I wish this were some outlier story or a case of crotchety cynicism, but tech has been really consistent about repeating this pattern over and over again, sadly. We keep buying and using things based on the way we feel. Then they don't work out, people get frustrated, make an entirely new layer of stuff designed to make us feel good. Meanwhile, about 1-in-100 of these things turn out to be useful over longer periods of time. I'd give that award to JQuery.
  - rmilejczz 7y ago
    The whole “so many Js frameworks!” thing is ridiculous. The same dominant frameworks have been popular for _years_ now, and while new frameworks do pop up people mostly use these same dominant frameworks, and these dominant frameworks are incredibly _samey_, relying on reactive data concepts, components, and a Fluxlike data store pattern for more complex apps. Going from React to Vue or even to modern Angular is really not a huge context switch anymore. The Js framework ecosystem is incredibly easy to work with in 2019, sorry if I came off a little strong with my rant but that sentiment makes me cringe. It is absurd hyperbole that’s not productive and doesn’t reflect the real state of web development in 2019 in any way. Overall I agree a framework isn’t a requirement for a good web app
- WillPostForFood 7y ago
  Very few people are replacing JQuery with super lite pure native JS implementations, it is getting replaced other libraries like React which is a wash, at best, for users.
- namanyayg 7y ago
  So do you put 'Content Type' and all that other stuff on every fetch call over and over again?
- wolco 7y ago
  the uglyness of document.Selector is something that never gets discussed. The 30k load once for the entire site is rarely an issue unless you are building super light where you would avoid using an image because you feared that extra few k.
- deleted 7y ago
  [deleted]
patsplat 7y ago
babel solves the problem of polyfills in a more elegant manner.
CM30 7y ago
There's another reason to use jQuery not included in the article, albeit one which has lost a bit of relevance in the last few days: jQuery plugins/extensions/libraries/whatever. An awful lot of libraries for things like carousels and masonry type grid systems and other such things are built with jQuery as a dependency, so anyone wanting to use them (especially to avoid rolling out their own version) is stuck relying on it. Fortunately, a lot of these things have either moved to working as standalone vanilla JS type deals, or to NPM modules instead. Unfortunately, the latter is argubaly causing the same dependency hell issue, since many devs will now basically throw in a full JavaScript framework and a bunch of task builders and managers like webpack just to be able to include said modules more easily and save on development time/costs.
- doctorpangloss 7y ago
  There’s a difference in quality between these jQuery and NPM (and react component) things. jQuery plug-ins often have a certain polish to them that works great on desktop browsers and rarely mobile, since it’s from an era where the talented plugin (i.e. component) authors didn’t have mobile browsers as a target. Whereas react-component feels like it’s authored for Chrome targets (iOS safari compatibility by accident) since front end devs kind of live in that DevTools universe nowadays. The npm package community in general is hard to generalize. As far as frameworks facilitate people who care about really fine interactions I’m all for it. It wildly enriched the ecosystem. Like someone had to figure out all the little interactions that Google and Apple industrialize (i.e. clone) into their UI frameworks. We just don’t ever hear about the original authors because they don’t have multi-million dollar developer relations budgets. So while you’re right that there’s a dependency hell or whatever high brow engineering problem, we see that with the privilege that someone at Google is getting paid $250,000 a year to industrialize/copy the good idea.
  - EB66 7y ago
    > There’s a difference in quality between these jQuery and NPM (and react component) things. Yep, you're exactly right, the plugins are from a different era and have less utility today. That said, jQuery itself still has immense utility. It's expressiveness and simplicity are second to none. The author points to youmightnotneedjquery.com as an example of why jQuery is superfluous today, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the YMNNJ example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often much more verbose and less expressive than the jQuery examples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular, React or Vue even existed. Within the past few years we 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 open sourced the framework at https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly and it's state management utility at https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim Our framework core uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, we don't see any reason to rush to rip jQuery out of the framework core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow. Long live jQuery :)
tambourine_man 7y ago
I never understood why browser vendors went to the trouble of agreeing on and creating a native alternative to jQuery. It’s more verbose and everybody has to relearn something they can already do in more readable and compact code. Why haven’t they simply adopted jQuery’s APIs? That ship has long long sailed, but still, I think we would’ve been in a much better situation right now.
- rmilejczz 7y ago
  Edit: I misinterpreted parent comment, please disregard
  - flatline 7y ago
    The implementation is largely independent of the API. A native jquery implementation could be just as performant as the standard query methods on document.
    - rmilejczz 7y ago
      Perhaps I misunderstood the original comment, seemed like they meant implementing identical APIs to jQuery, I thought they meant simply writing an abstraction in JS (I.e. not a native impl). That’s my bad
- charrondev 7y ago
  I appreciate the clearer naming of the built in methods. - `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on` JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
  - tambourine_man 7y ago
    I hate the verbosity of it. The “fun” part of jQuery is important to its success.
amriksohata 7y ago
I get laughed at by typescript devs for using it, I feel jQuery will stand the test of time than these frameworks. However wasm will have the last laugh
dmitriid 7y ago
Counterpoint. “Why I'm still using jQuery in 2019”, https://arp242.net/jquery.html https://arp242.net/jquery.html
- ausjke 7y ago
  jquery is less verbose than native ES6+ js functions, I'm not a frontend developer myself, my understanding is react/vue/etc are for SPAs where you manage lots of states inside the browser locally instead of on the server side, but majority web-related UI actually does not need that ecosystem/complexity at all, a bootstrap+jquery can still serve majority of use cases in my opinion. I just started working on a dashboard for an embedded network device, and bootstrap + jquery seems perfectly fine there, and I don't need spend a month to learn react/vue/webpack/etc and become a js expert before I can do anything productive.
Carpetsmoker 7y ago
> For example, the Fetch API can replace jQuery’s Ajax functions Except that it won't work for ~6% of your visitors (± a few percentage points, based on your locality and audience). Some developers sneer at these kind of numbers and comaplain about old browsers and whatnot. Yeah, it's annoying. But it's also reality, and as a professional you'll have to deal with it. > The querySelector and querySelectorAll methods replicate jQuery’s selection capabilities The jQuery selectors have quite a bit of extra useful functionality though.
- timdorr 7y ago
  You can polyfill it in under 500 bytes: https://github.com/developit/unfetch https://github.com/developit/unfetch
  - Carpetsmoker 7y ago
    And 7 more polyfills later and you've ended up with a hacky and incomplete version of jQuery.
    - timdorr 7y ago
      No, you've ended up with standard web APIs so you can safely drop those polyfills whenever browser support is at an acceptable level.
      - earthboundkid 7y ago
        Yes, there is also polyfill.io, which sniffs user agents and only sends the scripts a particular browser needs.
  - starik36 7y ago
    You still have to polyfill Promise, so it's definitely not under 500 bytes.
- dillonmckay 7y ago
  So, I work with car salespeople at dealerships, and also their customers (car-buying folks). We recently checked our top sending domains (the car-buying customer’s email address), and of course @gmail.com is #1, but @aol.com and @comcast.net are in the top 5. Depending on the dealership, all the PCs can be locked-down on IE9.
FreeHugs 7y ago
I still like to bind $ to querySelector and $$ to querySelectorAll: $ = document.querySelector .bind(document); $$ = document.querySelectorAll.bind(document);
- paulirish 7y ago
  Everyone's got their little snippet but here's my 15-liner that gives you $() and .on() syntax: $('p').on('click', el => /* ... */) https://gist.github.com/paulirish/12fb951a8b893a454b32 https://gist.github.com/paulirish/12fb951a8b893a454b32
HNLurker2 7y ago
Nostalgia When jQuery used to be thing everyone used and wanted to learn.

124 points by blast 7y ago

... and plenty of developers prefer using its API even when native methods are available. jQuery is great, and it's still a really useful library in some circumstances such as supporting incredibly old browsers, but if you're adding 30kb of weight to a page because you don't want to learn the fetch API then you really need to rethink how you think about users.

kroboker 7y ago
Agreed. I've seen numerous times developers include jquery just to make a simple request that can be replaced by XMLHttpRequest. Ref: http://youmightnotneedjquery.com http://youmightnotneedjquery.com
- yyyk 7y ago
  That site looks more like an secret advert for jQuery than any attempt to remove it. Maybe a comparison using more modern browsers would be more convincing...
  - Carpetsmoker 7y ago
    A friend of mine created a spoof to make exactly this point: https://youmightneedjquery.com/ https://youmightneedjquery.com/
- cm2187 7y ago
  What strikes me with this youmightnotneedjquery is that half of the examples take many more lines of code than a single jquery instruction.
  - archie2 7y ago
    Especially when it comes to browser support...why would I not use JQuery in those cases? I still use JQuery to this day, but probably because I don't really rely on JS in my applications that much. Unless you're building an "app" from the get-go, it's still my default choice.
- Silhouette 7y ago
  Even the information on that page is quite dated now, as IE becomes less relevant. As others have said, some of its examples were ironically pretty good adverts for jQuery at the time it was first published. However, you hardly ever need to use an XMLHttpRequest any more, and the native Fetch API is already as simple as jQuery's interface for most day-to-day tasks. The only major browser that doesn't support Fetch is IE, and if you still need to support IE for now, you might be better off with a simple polyfill for the standard Fetch API rather than coding around jQuery. Similarly, there is no need for monstrosities like calling Array.prototype.forEach.call on a NodeList returned by querySelectorAll instead of jQuery's $.each any more. Again, everything except IE supports forEach directly on a NodeList, and if you still need IE support, you can use a simple polyfill. If you need a real array to work with, an ES6 spread operator will build this for you with something like [...document.querySelectorAll('.someClass')] since the NodeList is iterable these days too.
baxtr 7y ago
Maybe jQuery should be simply included in browsers.
- nobleach 7y ago
  What is jQuery though? From the author's standpoint, it was a library built to smooth out the edges of bad browser support. This is a problem that doesn't exist as much these days. If you're looking for a way to select one or more DOM nodes and manipulate or jack content into it/them, browsers already provide an easy way to do that now days. The other abstractions it provides ($.get/$.getJson, $.each) have no reason to exist anymore. What's worse, the entire promise-like ability in jQuery is incorrect. (but has to be maintained for backward compatibility) So we're left with what? The $? One could simply do `const $ = document.querySelectorAll;` and get quite a bit of the functionality (I wouldn't really recommend this as it's not a drop-in replacement) Now if we mean the entire jQuery ecosystem. Please.... NO! Tons of bloated non-performant libraries for things like carousels... when a simple `overflow: scroll` could have worked. It was such a nightmare to deal with on mobile devices!
goto11 7y ago
There is more to it than "wanting to learn". You can peruse Can I Use https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch to evaluate if the API is widely enough supported to be viable. Then you have to figure out which bugs and incompatibilities exist across browsers. If you look at http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ you will notice that the native approach is at best similar to jQuery, but in many cases more cumbersome and verbose. 30kb is completely insignificant. Using jQuery is just easier and less risk.
- davidweatherall 7y ago
  A fetch polyfill can be added to a project for ~500 bytes[1] vs jQuery which is ~30kB [2] - or if you were to import just the ajax element from jQuery it would be 13kB [3] And by correctly using polyfills only on browsers that don't support native fetch, the majority of your users (chrome/safari/firefox) won't have any extra dependencies by using fetch, whereas jQuery will need to be loaded on every browser that hits your site. [1] https://bundlephobia.com/result?p=unfetch@4.1.0 https://bundlephobia.com/result?p=unfetch@4.1.0 [2] https://bundlephobia.com/result?p=jquery@3.4.1 https://bundlephobia.com/result?p=jquery@3.4.1 [3] https://www.telerik.com/blogs/jquery-using-only-what-you-need https://www.telerik.com/blogs/jquery-using-only-what-you-nee...
  - goto11 7y ago
    Just for comparison, the "favicon" for Hacker News is 7.66 KB. Does the size of jQuery really matter for a typical web site? If you have just a typical size logo, it will dwarf the size of jQuery, never mind if you have some illustrations or photos.
    - davidweatherall 7y ago
      I agree there are often more important performance issues on sites, especially with images, but that doesn't mean we should completely ignore javascript bundle sizes. In modern sites if javascript doesn't load sites then become non functional, e.g. navs don't work, some SPAs won't work at all. Whereas an image or favicon taking a long time to load shouldn't stop the user from being able to functionally view most of the site.
jasim 7y ago
That might be false economy. Most images in a page would come above 30kb. I've seen 3rd party widgets for chat and support sometimes bundle their own copy of the React framework, not to mention huge chunks of CSS, most of which are unused.
- yazboo 7y ago
  If you're putting jQuery in your main application bundle then it has to be parsed and executed before you can do anything. That's not the same as an equivalent sized image which just needs to be decoded and painted. If it's a chat widget hopefully you're loading it separately. I agree that CSS can also be a problem.
  - hdfbdtbcdg 7y ago
    Pretty sure serverside rendered html works just fine before JavaScript is parsed and executed..
iforgotpassword 7y ago
Tbh, I still prefer a "classic" no-bullshit website that depends on jQuery just because the dev likes it a thousand times over the modern overloaded "just-because" SPA that depends on five dozen Js frameworks that were hip the day that page was created.
- DanielBMarkham 7y ago
  Yes. We've got an entire generation of front-end guys tooled up with awesome-looking IDEs and six hundred npm packages creating sites that need none of that. Each of these packages has dependencies, bugs, security issues, their own roadmaps, and so on. I believe in brutally low overhead websites, but I'd still use JQuery if I had to. It's one of a very few things that just make sense no matter what you're doing, and combined with CDNs and cache reloads, you're highly unlikely to be pulling even that 30k over the wire when you use it. We're going to make a ton of super-cool websites using the new stuff we have. Meanwhile we're also going to make a ton of messes. The cool kids will move on to more tools and gadgets. The second-string bunch will be left struggling to maintain. At some point there'll have to be a huge clean up. Consultants will make lots of money. Many of these consultants will be the people selling us all this crap we don't need right now. I wish this were some outlier story or a case of crotchety cynicism, but tech has been really consistent about repeating this pattern over and over again, sadly. We keep buying and using things based on the way we feel. Then they don't work out, people get frustrated, make an entirely new layer of stuff designed to make us feel good. Meanwhile, about 1-in-100 of these things turn out to be useful over longer periods of time. I'd give that award to JQuery.
- rmilejczz 7y ago
  The whole “so many Js frameworks!” thing is ridiculous. The same dominant frameworks have been popular for _years_ now, and while new frameworks do pop up people mostly use these same dominant frameworks, and these dominant frameworks are incredibly _samey_, relying on reactive data concepts, components, and a Fluxlike data store pattern for more complex apps. Going from React to Vue or even to modern Angular is really not a huge context switch anymore. The Js framework ecosystem is incredibly easy to work with in 2019, sorry if I came off a little strong with my rant but that sentiment makes me cringe. It is absurd hyperbole that’s not productive and doesn’t reflect the real state of web development in 2019 in any way. Overall I agree a framework isn’t a requirement for a good web app
WillPostForFood 7y ago
Very few people are replacing JQuery with super lite pure native JS implementations, it is getting replaced other libraries like React which is a wash, at best, for users.
namanyayg 7y ago
So do you put 'Content Type' and all that other stuff on every fetch call over and over again?
wolco 7y ago
the uglyness of document.Selector is something that never gets discussed. The 30k load once for the entire site is rarely an issue unless you are building super light where you would avoid using an image because you feared that extra few k.
deleted 7y ago
[deleted]

patsplat 7y ago

babel solves the problem of polyfills in a more elegant manner.

CM30 7y ago

There's another reason to use jQuery not included in the article, albeit one which has lost a bit of relevance in the last few days: jQuery plugins/extensions/libraries/whatever. An awful lot of libraries for things like carousels and masonry type grid systems and other such things are built with jQuery as a dependency, so anyone wanting to use them (especially to avoid rolling out their own version) is stuck relying on it. Fortunately, a lot of these things have either moved to working as standalone vanilla JS type deals, or to NPM modules instead. Unfortunately, the latter is argubaly causing the same dependency hell issue, since many devs will now basically throw in a full JavaScript framework and a bunch of task builders and managers like webpack just to be able to include said modules more easily and save on development time/costs.

doctorpangloss 7y ago
There’s a difference in quality between these jQuery and NPM (and react component) things. jQuery plug-ins often have a certain polish to them that works great on desktop browsers and rarely mobile, since it’s from an era where the talented plugin (i.e. component) authors didn’t have mobile browsers as a target. Whereas react-component feels like it’s authored for Chrome targets (iOS safari compatibility by accident) since front end devs kind of live in that DevTools universe nowadays. The npm package community in general is hard to generalize. As far as frameworks facilitate people who care about really fine interactions I’m all for it. It wildly enriched the ecosystem. Like someone had to figure out all the little interactions that Google and Apple industrialize (i.e. clone) into their UI frameworks. We just don’t ever hear about the original authors because they don’t have multi-million dollar developer relations budgets. So while you’re right that there’s a dependency hell or whatever high brow engineering problem, we see that with the privilege that someone at Google is getting paid $250,000 a year to industrialize/copy the good idea.
- EB66 7y ago
  > There’s a difference in quality between these jQuery and NPM (and react component) things. Yep, you're exactly right, the plugins are from a different era and have less utility today. That said, jQuery itself still has immense utility. It's expressiveness and simplicity are second to none. The author points to youmightnotneedjquery.com as an example of why jQuery is superfluous today, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the YMNNJ example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often much more verbose and less expressive than the jQuery examples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular, React or Vue even existed. Within the past few years we 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 open sourced the framework at https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly and it's state management utility at https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim Our framework core uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, we don't see any reason to rush to rip jQuery out of the framework core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow. Long live jQuery :)

tambourine_man 7y ago

I never understood why browser vendors went to the trouble of agreeing on and creating a native alternative to jQuery. It’s more verbose and everybody has to relearn something they can already do in more readable and compact code. Why haven’t they simply adopted jQuery’s APIs? That ship has long long sailed, but still, I think we would’ve been in a much better situation right now.

rmilejczz 7y ago
Edit: I misinterpreted parent comment, please disregard
- flatline 7y ago
  The implementation is largely independent of the API. A native jquery implementation could be just as performant as the standard query methods on document.
  - rmilejczz 7y ago
    Perhaps I misunderstood the original comment, seemed like they meant implementing identical APIs to jQuery, I thought they meant simply writing an abstraction in JS (I.e. not a native impl). That’s my bad
charrondev 7y ago
I appreciate the clearer naming of the built in methods. - `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on` JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
- tambourine_man 7y ago
  I hate the verbosity of it. The “fun” part of jQuery is important to its success.

amriksohata 7y ago

I get laughed at by typescript devs for using it, I feel jQuery will stand the test of time than these frameworks. However wasm will have the last laugh

dmitriid 7y ago

Counterpoint. “Why I'm still using jQuery in 2019”, https://arp242.net/jquery.html https://arp242.net/jquery.html

ausjke 7y ago
jquery is less verbose than native ES6+ js functions, I'm not a frontend developer myself, my understanding is react/vue/etc are for SPAs where you manage lots of states inside the browser locally instead of on the server side, but majority web-related UI actually does not need that ecosystem/complexity at all, a bootstrap+jquery can still serve majority of use cases in my opinion. I just started working on a dashboard for an embedded network device, and bootstrap + jquery seems perfectly fine there, and I don't need spend a month to learn react/vue/webpack/etc and become a js expert before I can do anything productive.

Carpetsmoker 7y ago

> For example, the Fetch API can replace jQuery’s Ajax functions Except that it won't work for ~6% of your visitors (± a few percentage points, based on your locality and audience). Some developers sneer at these kind of numbers and comaplain about old browsers and whatnot. Yeah, it's annoying. But it's also reality, and as a professional you'll have to deal with it. > The querySelector and querySelectorAll methods replicate jQuery’s selection capabilities The jQuery selectors have quite a bit of extra useful functionality though.

timdorr 7y ago
You can polyfill it in under 500 bytes: https://github.com/developit/unfetch https://github.com/developit/unfetch
- Carpetsmoker 7y ago
  And 7 more polyfills later and you've ended up with a hacky and incomplete version of jQuery.
  - timdorr 7y ago
    No, you've ended up with standard web APIs so you can safely drop those polyfills whenever browser support is at an acceptable level.
    - earthboundkid 7y ago
      Yes, there is also polyfill.io, which sniffs user agents and only sends the scripts a particular browser needs.
- starik36 7y ago
  You still have to polyfill Promise, so it's definitely not under 500 bytes.
dillonmckay 7y ago
So, I work with car salespeople at dealerships, and also their customers (car-buying folks). We recently checked our top sending domains (the car-buying customer’s email address), and of course @gmail.com is #1, but @aol.com and @comcast.net are in the top 5. Depending on the dealership, all the PCs can be locked-down on IE9.

FreeHugs 7y ago

I still like to bind $ to querySelector and $$ to querySelectorAll: $ = document.querySelector .bind(document); $$ = document.querySelectorAll.bind(document);

paulirish 7y ago
Everyone's got their little snippet but here's my 15-liner that gives you $() and .on() syntax: $('p').on('click', el => /* ... */) https://gist.github.com/paulirish/12fb951a8b893a454b32 https://gist.github.com/paulirish/12fb951a8b893a454b32

HNLurker2 7y ago

Nostalgia When jQuery used to be thing everyone used and wanted to learn.