Hacker News Reader

Comment by seangrogg | Hacker News Reader

So, jQuery instead of just...

  function $(sel) {
    switch (sel[0]) {
      case '#': return document.getElementById(sel.slice(1));
      case '.': return document.getElementsByClassName(sel.slice(1));
      default: return document.getElementsByTagName(sel.slice(0));
    }
  }

I mean... "readability".

View on HN

And in the end, you add 10 of those selectors. Then you create a small library so they are all at the same place and handy. Then few fixes to support that one browser in that case. And in the end you have jquery.

With that you would end up with something more like Sizzle[0], not necessarily jQuery.

[0] https://sizzlejs.com/

I think you're forgetting additional HTTP functionality, rudimentary animations, additional wrappers around existing JavaScript representation of DOM nodes, and a variety of other things that you'll never realistically used but thrown into all your applications for posterity. Because in the end, you had jQuery.

With http2 the additional request is not a problem. If you don't use jquery, you don't care about old browsers/OS not supporting them either. Also, cdn+caching of the library.

Bytes are bytes are bytes, http/2 or no. It's far less intensive to polyfill what features I actually am using than sending down all of jQuery, and that can still be minified, gzipped, cached, delivered via CDN, and cache-controlled and/or placed in the application cache via service workers (where available).

But I can understand that it's less about the user experience and more about the developer experience nowadays.

in HTML5 would be sufficient: const $ = document.querySelectorAll.bind(document);

(but it would be only pseudo jQuery, the way you can have pseudo React just by using functions and ES6 template strings https://jsfiddle.net/vug86rn0/ )

Reply on news.ycombinator.com