Sprint – A high-performance, DOM library for modern browsers (opens in new tab)

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.

    A tiny, lightning fast jQuery-like library for modern browsers.

Respectfully, this entire description is an oxymoron. Every time someone mentions a jQuery-like microlibrary, they just mean a jQuery without wide browser(-quirk) support.

Browser support is a big part of what makes jQuery jQuery, and without it, you definitely get a much smaller library, but it is also very un-jQuery-like. :)

Now for some praise! It makes me really happy to see a comparison - benchmark! - with competitors, which is something everyone should be required to do, when they create software with 40,000 similar offerings. Looking at you, Markdown editors!

Not supporting the selector for .on() and .off() is a pretty serious limitation; catching bubbled events on child DOM elements is a super-common jQuery pattern, and makes event-handling over a DOM that's having stuff added to it much more pleasant to write. It's also pretty fundamental to some third-party libraries that run on top of jQuery, like Backbone (at least if you use its View event handling).

Yeah, its great that there are libraries like this that try to do better than the status quo.

But, with every new library there's always the question about support. And so since there is no involvement perceptible on its Github page (no PRs, no issues and 3months without a commit), I wouldn't want to use this in production.

The readme presents it as a production-ready jquery alternative but there isn't a single test written and it looks like there's no support at all

There isn't a single test for this project. How can its claims of jQuery-alike-ness be supported?

Tests, or it doesn't exist.

This only supports IE10+. Why shouldn't I just use Javascript directly?

I like this approach. I generally tend not to use jQuery, because native DOM API is often good enough for my needs, but it's not fun to write and read code using that API. jQuery for me is shortcuts and wrappers for this code.

I am tired of terribly slow mobile sites. A demo of the difference would help.

It doesn´t seem to support the jQuery .ajax() method, I hope its added soon

I've used [the very badly named] minified.js in the past, and I was quite happy. Has optional support for IE6.

http://minifiedjs.com

virtual-dom is all you need: https://github.com/Matt-Esch/virtual-dom

There is a reason why both elm and mercury uses virtual-dom under the hood to generate and manipulate the DOM.

Plus you can render server-side: https://github.com/nthtran/vdom-to-html

If you still want to work with existing html like templates, there is this project: https://github.com/TimBeyer/html-to-vdom

How this compares to zepto? As far as i know, this is basically the same promise zepto does "A kind-of-jquery but faster (and only modern boys)"

I didn't find any information on browser support.

Finally I can run .css() over 700,000 times per second. Also, the 30 KB saved over the wire means a lot because the average page size is over 1 MB.

I think this needs some text outlining it's differentiation from Zepto. Why would I use this instead of Zepto?

Hey guys found this neat little library

http://vanilla-js.com/

I get 12+ million operation (a true master race class) vs advertised 800,000 and peasantry of jQuery's 300,000.

Not sure if I want to sacrifice performance for aesthetically better looking (debatable ofc) syntax and bother investing time learning how to do something slower.