Live data from Hacker News

You might not need jQuery (2014)

youmightnotneedjquery.com

41–50 of 241 posts

Re: You might not need jQuery (2014)

#41

Someone should make a youmightnotneedspringboot.com

Well sure, you could do so much better with a small library like Vert.x (which I love). But getting an entire app framework with config/routing/db connectivity/etc is just so easy with Spring Boot. Plus, you get a vast ecosystem. Now the memory usage and compile times? Yeah, youmightnotneedspringsmemoryoverhead.

If someone can buy this argument but not then immediately understand why a library like jQuery or React is popular, that’s a shame. It’s the exact same reasons: maturity, flexibility, and community/precedent.

Re: You might not need jQuery (2014)

#42

Earlier quoted context omitted.

I think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and…

I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.

document.querySelector was not available in IE 6 and 7.

Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.

Re: You might not need jQuery (2014)

#43

Earlier quoted context omitted.

> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.

In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.

> In the real world... From experience...

Does jQuery (est. 2006) have more bugs in it than your code?

Re: You might not need jQuery (2014)

#44

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery...

For reference:

  // JSON
  const data = await (await fetch('/my-url')).json();

  // Post
  await fetch('/my-url', { method: 'POST', body: data });

  // Request
  try {
    const resp = await fetch('/my-url');
    // ...
  } catch (e) {
    // ...
  }

  // Fade In
  el.animate({ opacity: 1 }, 400);

  // Fade Out
  el.animate({ opacity: 0 }, 400);

  // Hide
  el.hidden = true;

  // Show
  el.hidden = false;

  // After
  target.after(el);

  // Append
  target.append(el);

  // Before
  target.before(el);

  // Each
  for (const el of document.querySelectorAll(selector)) {
    // ...
  }

  // Empty
  el.replaceChildren(); // or el.textContent = '', depending on which you find clearer

  // Filter
  [...document.querySelectorAll(selector)].filter(filterFn);

  // Get Height
  el.clientHeight;

  // Get Width
  el.clientWidth;

  // Matches
  el.matches('.my-class');

  // Remove
  el.remove();

  // Delegate
  document.addEventListener(eventName, e => {
    const match = e.target.closest(elementSelector);
    if (match) {
      handler.call(match, e);
    }
  });

  // Trigger Custom
  el.dispatchEvent(new CustomEvent('my-event', { detail: { some: 'data' } }));

  // Trigger Native
  el.dispatchEvent(new Event('change'));

  // Extend
  Object.assign({}, objA, objB);

  // Parse HTML
  (new DOMParser()).parseFromString(htmlString);

  // Type
  obj[Symbol.toStringTag];

Re: You might not need jQuery (2014)

#45

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

This is all very old javascript to be fair, the modern equivalents are as terse as jquery these days.

Somewhat true, but this was also old jQuery :)

Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO).

jQuery:

    $(".classname").addClass("darktheme")
ES6:

    document.querySelector(".classname").classList.add("darktheme")

Re: You might not need jQuery (2014)

#46

Earlier quoted context omitted.

> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.

In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.

Have fun implementing everything from scratch in assembly.

Re: You might not need jQuery (2014)

#47
post #42

Earlier quoted context omitted.

I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.

document.querySelector was not available in IE 6 and 7. Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.

IE 6. Now that's a name I haven't heard in a long time...

Re: You might not need jQuery (2014)

#48
post #8

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

Yes, absolutely. That's a total no-brainer.

> Hidden complexity you don't control is the most expensive kind I think.

There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your custom implementation of whatever it was than in jQuery.

Re: You might not need jQuery (2014)

#49

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

youmightneedtoreadtheintro
Post reply on HN