"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.

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

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 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 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 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.

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 think one week is enough for any reasonable MV* framework to eventually pay off and boost productivity