Comment by whyileft | Hacker News Reader

Comment by whyileft | Hacker News Reader

Parent Full thread

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));

Reply on news.ycombinator.com