Is jQuery still relevant? (2014) | Hacker News Reader

Is jQuery still relevant? (2014)

syntaxsuccess.com

36 pointsthelgevold47 comments

If i had to build an app in a week and my life was on the line, i would use Jquery and ignore any other javascript frameworks.

I think react makes a good case for the `kidnapped by Jeff Bezos to work on applications` situation. I find the simple way that you can just render things and not have to worry about DOM manipulation to be very freeing.

Agreed. Once you know React it's incredibly quick to throw something together (especially if you use Material UI or similar). jQuery is definitely simpler but the props/state model of React means fewer bugs slip through the cracks when you're in a hurry.

(and my usual disclaimer - if you're going to use React for a quick project, you can probably use Preact and save the extra bloat)

Top 100 run-time dependencies of react apps in terms of number of usage : https://airtable.com/shrfmD9l5rAW4Z03N/tbls8DesxQZT7VH0p/viw... jQuery is in 15th position.

Hey, I never said people are doing it right.

React completely removes the need for jQuery if you're using it correctly, because you should rarely if ever touch the DOM, and jQuery is... a DOM manipulation library.

jQuery nowadays is much more than DOM manipulation lib. In the latest version it gives the promises that are compatible with Promises/A+ spec. It has the powerful ajax calls functions.

They all moved on so they have no idea how good it is.

I mean instead of adding polyfills for "fetch" api and "es6 promises" that brings a gazillion dependencies with them, one can simply add jquery package that has ZERO runtime dependencies(https://github.com/jquery/jquery/blob/master/package.json) and have ajax calls, promises and much, much more out of the box. I love jQuery.

Or you could add a fetch polyfill with zero dependencies:

https://github.com/github/fetch/blob/master/package.json

And a Promises library with zero dependencies:

https://github.com/stefanpenner/es6-promise/blob/master/pack...

This is not as difficult as you're making it out to be.

It's still 2 dependencies in your project versus 1 dependency.

1 dependency that's 34.6KB minified. That's a lot more than the two separate dependencies, and besides, once you've gone to the trouble of adding a package.json to add one dependency, adding one more is a very small step.

where 34.6KB size came from? I don't get it

I agree with this so much, but at the same time I acknowledge that his is at least in part due to how quickly the FE landscape changes and my inability to keep 100% up to date and equally effective.

jQuery was simple to use, and that's a big selling point.

I would also use Typescript as well, because, type safety is super helpful when it comes to debugging. Unless you never programmed in a static typed language like C# or Java before, there's not really any good reasons for avoiding it imho.

I think the question these days is "jQuery or vanilla DOM API?" and less "jQuery or JavaScript framework?"

Personally, if I'm working on a project that isn't big enough to warrant a framework, I'm probably not concerned about Internet Explorer either. (And even then my understanding is that IE isn't even that bad these days.)

IE hasn't been bad for a while, or at least not bad in a way that jQuery would fix for you

How bad is IE these days actually? I haven't used it since 2001.

I can totally see your point, you need to manipulate the DOM, make AJAX calls and add some event listeners painlessly for something relatively simple. Its very little boilerplate. I also think its relevant. But just like this is relevant, if you dominate any other framework or library, you may as well be proficient with it to the point where you could put together an app in the same time. Maybe even using code from stuff you've worked before for tasks that are common patterns. I think it comes down to what you dominate the most will still be relevant.

"Long time" React user, still use it on new projects, but I was looking at Vuejs in depth a little bit yesterday, and it augments JS and HTML in a much simpler way. That simplicity - to me - is reminiscent of jQuery to a certain extent. I'm sure it has its own faults, but not having to write a webpack config or download some sort of transpiling monstrocity for once was a nice change.

I think I'd probably agree with you on the "ship it ASAP" premise, but Vue could be a real contender in that category as well.

Nothing cooler for mission critical than

  $(window).on('scroll', function() {
    if ($('.some-class-matching-one-element-in-a-tree-of-one-hundred-thousand').offset().top > $(window).scrollTop()) {
      $('.some-class-matching-one-element-in-a-tree-of-one-hundred-thousand').on('click', function() {
        if ($(this).closest('.some-other-random-class').hasClass('selected')) {
          $(this).closest('.some-other-random-class').addClass('.blue-background');
          $('.some-class-matching-one-element-in-a-tree-of-one-hundred-thousand').removeClass('selected');
        }
      }
    }
  });

Then when you have terrible mobile performance you just tell the stakeholders that if they want good performance they need to pay you more to then make a native app.

jQuery(which was really sizzle) was a plague because it allowed garbage developers to search the entire DOM over and over and over again(aka get shit done bro). This would clobber the performance in mobile devices because JavaScript is single threaded and lead to the idea that JavaScript itself was unsuited for mobile applications.

Sorry, its garbage for anything but spicing up a WordPress site.

I know it's an example app, but your code can be rearranged to not listening to scroll even at all. Or even a little throttle function would do just fine.

Bad program is possible in all framework. One can write a slow React app as well.

jQuery encouraged that behavior everywhere.

The constant traversing of the DOM over and over and over again to re-select jQuery DOM objects. Sure you can write that correctly. But I rarely if ever saw anyone to the point that when I would, most developers who typically worked in jQuery would be confused.

If you did that re-selecting with only a throttle you would kill performance on a decent sized DOM on a mobile device anyway. That is exactly my point about jQuery and developers.

The proper thing to do would be to select that element before the scroll and pass that into the event. Otherwise performance would still be awful.

Obviously that is just a toy example that doesn't really have a point(like you correctly stated), but it was to illustrate the constant riding of sizzle to select things over and over again, killing performance.

EDIT: Downvotes prove the point. Take a look at the sizzle cache for yourself. The fact that so many people misunderstand jQuery enough for this to get significantly downvoted on a site where the average competency of developer is probably a bit higher than in the wild shows you exactly the horror that jQuery was for mobile performance.

Although, maybe that means there really aren't many skilled web developers on this site anyway. Because the people who downvoted this are completely wrong so maybe I shouldn't assume there is much talent around here.

I mean how often have you honestly seen something like this instead?

  (function(window, $) {
    var $some = $(.some-class-matching-one-element-in-a-tree-of-one-hundred-thousand');

    if ($some.length < 1) {
      return;
    }

    var $closest = $some.closest('.some-other-random-class');

    if ($closet.length < 1) {
      return;
    }

    var $window = $(window);

    $window.on('scroll.foo', $.throttle(function() {
      if ($some.offset().top > $window.scrollTop()) {
        $window.off('scroll.foo');
        $some.on('click.foo', function() {
          if ($closest.is('[chosen]')) {
            $closest.addClass('blue');
            $some.removeAttr('chosen');
          }
        });
      }
    }));
  }(window, jQuery));

I think one week is enough for any reasonable MV* framework to eventually pay off and boost productivity

I've moved away from jQuery for most everything, because I was really only using it for selectors, and various other things that can be done in vanilla browser JS. However if you want to play with UI frameworks like Bootstrap and Semantic UI, you're going to be using it, and that's not a bad thing. Time and place for any library. Out of fashion, doesn't mean out of relevance.

I love me some jQuery. While I don't ALWAYS reach for it in a project - I usually do. It can add nice behavior to webpages with just a sprinkling of JS, and not a lot of boilerplate, and not having to worry about browser edge cases.

For the two dozen or so various medium/large sites i've worked on; Jquery, underscore and d3 give me everything I want and then some.

But it's certainly not the "cool" kid anymore. It's an important fundamental that you can use to do a lot with - but sites with more heavy use of JS will probably gravitate towards a more structured framework like angular

Outside the framework, jQuery also has tons of free and powerful plugins that we can't simply overlook in our day to day application development. We used jqgrid for all of our datagrids. It's insanely powerful.

datepicker... for me.

jquery also gives me promises and ajax calls.

Will jQuery ever not be relevant? It's still the easiest way to accomplish most basic tasks, and 90% of the websites out there make use of it in some fashion or another. There are now a plethora of frameworks for building front end web apps, but for basic scripting I don't see anything replacing jQuery anytime soon.

jQuery was built in a time when doing a simple ajax request required 2-3 code paths just for cross-browser compatability, and some of those code paths fairly verbose. Today most basic tasks are short and easy with just standard APIs that every browser understands out of the box. The need for jQuery has certainly diminished (usage not so much).

Not just for cross-browser compatibility, it's other main benefit is a DOM manipulator.

If you are planning to ditch jQuery, make sure you consult this:

https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...

Make sure you also consult browser marketshare numbers and decide exactly what you need to support:

http://caniuse.com/usage-table

Many of the examples in that doc are Android < 4.1 (0.06%), IE < 9 (0.48%), Firefox < 24 (~0.1%), etc. Even IE 9-11 is only 4% of the market these days.

The browser-compatibility story is dramatically different from when JQuery was created in 2006. All of the major browsers have been auto-updating for several years now.

Most of problems pointed by the article are related to javascript and the DOM model, JQuery just provides a very useful function set and interoperability between browsers.

jQuery may not be enough to structure your application. This is actually debatable -- there's many applications for which treating the document as your model is a perfectly acceptable approach, and it can scale just fine assuming some thoughtful discipline -- but some applications don't lend themselves particularly well to the kind of resource-oriented practice involved and having a separate model can make sense too.

jQuery is less necessary than it used to be in order to get reasonable tools for working with the DOM and other browser APIs... but then again, depending on your need for marginal utility and tolerance for personal attention to corner cases, you never really needed it. If you were determined, you could always custom code a micro library that covered most of the overlap between what jQuery did and what your app needed. It's just that it often gave you the gift of not having to pay attention to those cases. It still can.

Things jQuery will always be relevant for: an example.

It might be the single most thoughtful yet pragmatic abstraction that I've had the pleasure of regularly working with in the last decade. The basic idea of using selectors to navigate the DOM was a key jump in productivity, the fluent-chained interface was thoughtful and a massive boost. It almost never leaked -- I can count on one hand the number of times in 10 years something weird was going on underneath the hood that I had to pay attention to (Angular exceeded this measure inside of a few months). And strangely enough, every other library that was its contemporary when it was born seemed to think that the problem with front-end development was JavaScript's lack of classes & traditional OO, if the amount of library that was focused on adding them was any indication. jQuery recognized how much of the pain was really coming from bad browser APIs, and how much productivity could come from building better ones, combined with idioms/concepts from the functional side.

Still seems to be #1 in useage by a long shot https://w3techs.com/technologies/overview/javascript_library...

Although I admit I couldnt be bothered to look at their methodology, it could be the case this is marketing type sites and not web applications. Doesn't make it any less valid, just less valid for SPAs perhaps.

I think a much more relevant (but ultimately completely unmeasurable) metric is the number of websites currently rolling out (i.e. "upgrading to" or building afresh on) jQuery. The vast majority of sites in any statistic like the above are always going to be older no-longer-very-actively-being-updated-beyond-maybe-some-security-patches frontends.

An interesting indicative stat would be number of installs of the very latest jQuery versions.

The thing to note is that just because a large number of sites are still using it, doesn't mean that it is relevant. There are probably tens of thousands of stale sites that don't get regular updates using jQuery, since it's been the "standard" for so long. That will inflate the usage numbers, and competing solutions (Angular, React, Vue, etc.) don't have 5 years worth of free growth under their belts to equalize that inflation. A truer metric of "relevance" would be "How many new sites are showing up with each technology?"

I have a situation where a full framework was overkill but using Jquery was causing an unmaintanable mess when creating a dynamic UI. I took a middle ground. I came in and introduce Handlebars to the work flow. We still use Jquery, but our ui is created with simple intuitive handlebar templates/compiled functions.

When we do start building more complex web apps, we decided on Ember since it uses Handlebars as its templating engine.

I created a library to manipulate the DOM in a simplified way inspired by the question, how would I build jQuery if I had to do it today?

Superdom https://superdom.site/

Perhaps I'm just lazy or missing something... While I don't often use it directly, I do find that adding a ref to it makes my life easier when I'm working in AngularJS.

I don't think so. jQuery was intended to be a cross-browser approach to JavaScript that just works. It does but if you check out MDN docs, you'll find that now days, vanilla just works really well and ES6/7 have great features. Modern browsers have aggressive updates that are simple to apply. It isn't the same anymore. Also, doing actual apps is way easier with React or Vue, even on small scales.

Not to mention that even AngularJS 1.x still bundles jqLite and switches to full jQuery if you include it first.

"None of the popular patterns promote the tight coupling between view and code."

Not sure how relevant this is either. React barely differentiates between view and code, opting to put everything in one place.

Reply on news.ycombinator.com