[tshadwell]

Or, you know, use the Javascript DOM APIs? They're really not at all that bad.

  var d = document.createElement("div");
  d.className = "new";
  d.innerHTML = "<p>Hi Sprint</p>";

Skimming through the code I'm not sure the authors really grok Javascript anyway, which might explain why they need a (pretty thin) custom API for the standard APIs. toArray should be simply this:

function toArray(o) { return Array.prototype.slice.call(o) }

Instead it's:

  var toArray = function(obj) {
    var arr = []
    var i = obj.length
    while (i--) {
      arr[i] = obj[i]
    }
    return arr
  }

This is just silly:

    prepend: function() {
      insertHTML.call(this, "afterbegin", arguments)
      return this
    },

  var insertHTML = function(position, args) {
    var argsLen = args.length
    var contents = args

[...]

  var domMethods = {
    afterbegin: function(el) {
      this.insertBefore(el, this.firstChild)
    },

Perhaps this isn't so constructive and I should fork the library and annotate every method with its vanilla Javascript equivalent. I'm sure this post is non-constructive in some respects but I like Javascript, I just wish people would learn how to work with the language it instead of replacing the API wholesale.

[jackmoore]

DOM inconsistencies aside, a big advantage jQuery has over native API is that it is just as easy to work with multiple elements as it is single elements.

Modifying your example:

    var d = document.querySelectorAll('div');
    d = Array.prototype.slice.call(d);
    d.forEach(function(el){ el.classList.add('new') });

Vesus:

    $('div').addClass('new');

[rcgs]

It is possible to do that without the variable assignment in JS...

    [].forEach.call(document.querySelectorAll('div'), function(el) {
        el.classList.add('new');
    });

But I don't disagree that the jQuery example is easier to write/read/remember.

Though with frameworks like Angular or React I'm beginning to question whether we should ever be writing code like this at all.

[jackmoore]

Agreed. I mainly use React these days, and directly modifying the DOM is starting to feel dirty.

[BinaryIdiot]

There is a lot of uses of innerHTML in this code which causes browser reflow; might get better performance creating all of the HTML components via document.createElement() and using document.createTextNode() for all text within a tag itself.

But yeah cherry-picking may not be the most constructive thing however you do have good points. The DOM API is kinda funky (I wish it did some things like chaining) but it's very simple. Half the times I write a very thin wrapper around it JUST to provide some chaining.

[sanderjd]

See, that's why I end up using these libraries. If I found myself doing the three statements for creating a div in your parent's comment, I'd pull that out into a function that does it, then I'd start finding other things to pull out as well, then I'd think "surely somebody has made a library that has these things pulled out nicely", and I'd find one of these libraries. Since I know that would happen, I just start with a library from the beginning.

But I suppose I'd love one that is thinner, like your "very thin wrapper", if anybody has pointers.

[rwaldron]

You're conflating "JavaScript the programming language" with "DOM, the awful sack of shit".

Don't do that.

[benjamindc]

I find it interesting that, because some design decisions seem odd to you at first sight, you immediately conclude that the reason is a poor understanding of JavaScript. The `toArray` function, for example, is just performance optimization: http://jsperf.com/toarray-slice-call-vs-loop

[nicksardo]

Regarding toArray, the creator probably went that route to be more performant. http://jsperf.com/array-prototype-slice-call-vs-slice-call/1...

[jackmoore]

> I should fork the library and annotate every method with its vanilla Javascript equivalent

To save you some work: http://youmightnotneedjquery.com/