
Sprint – A high-performance, DOM library for modern browsers - sebgeelen
https://github.com/bendc/sprint
======
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.

------
kmfrk

        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!

~~~
ZeroGravitas
JQuery themselves have two versions, one with less browser support which is
apparently smaller/faster. So it's weird to say that it's not-JQuery-like.

Though JQuery still recommends the bigger library for most users (unless
you're embedding in a mobile app or stuff like that).

~~~
sjwright
I'd love to have a streamlined but otherwise version of JQuery which I can
serve to known modern web browsers. And serve the 'full' version to non-modern
browsers.

~~~
macNchz
Sounds like Zepto is pretty close to what you're looking for:
[http://zeptojs.com/](http://zeptojs.com/). Otherwise, jQuery 2.x is just
jQuery without support for IE 6, 7 and 8. I'm not sure what kind of
performance improvements it offers, but it shaves off a few kb.

------
apendleton
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).

~~~
leeoniya
agreed. lacking event delegation is a show-stopper.

------
timdaub
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.

~~~
JustSomeNobody
That's the problem with all these JS libraries and frameworks. They are being
written just to be written; only a handful have been vetted in production.

------
arnauddri
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

~~~
emodendroket
Sounds pretty Web-scale.

------
rwaldron
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.

~~~
LocalPCGuy
Better yet, the author should just implement the jQuery test suite, and give a
rundown of what passes and what fails.

~~~
rwaldron
I absolutely agree with this. Several years ago I did the same exercise with
Zepto, which definitively disproved its compatibility claim.

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

~~~
Jgrubb
Not the author, but the API still sucks to write using vanilla JS. There are
also still plenty of inconsistencies in modern browsers (per an article
floating around here in the last day or two).

~~~
smt88
> _the API still sucks_

If you want syntactic sugar, a better alternative to a client-side library
(which has overhead) is to use something like TypeScript (or one of the other
compile-to-JavaScript options).

~~~
anentropic
they solve different problems though... syntactic sugar from TypeScript et al
solve problems with Javascript the language

jQuery solve problems with the various builtin APIs like DOM etc that are part
of either Javascript or the web browser host

~~~
smt88
I just assumed the person I was replying to was complaining about
_document.getElementById( 'whatever')_ (etc.) vs _$( '#whatever')_.

In response to your comment, polyfills are more future-proof solutions to
browser compatibility, which is the only remaining problem that I see jQuery
as solving well.

~~~
Jgrubb
> I just assumed the person I was replying to was complaining about
> document.getElementById('whatever') (etc.) vs $('#whatever')

Actually that _is_ what I was referring to. I must not have given TypeScript
enough of a shake. I couldn't find the section in the early tutorial that
showed me that sugar, and I also couldn't figure out how the typing stuff
would help me working with a bunch of network-y type apps. Obviously this is
my own failing. Inspired now to give it another shot, so thanks.

~~~
smt88
It's entirely my own fault, but this has been a really muddled conversation.

When I mentioned TypeScript, I only meant that it (and other languages that
compile to JavaScript, like Go) is a better syntax overall. I didn't actually
mean that it helps with DOM selection/manipulation.

So if you want short DOM syntax, I'd suggest using vanilla ES6[1] with
polyfills, and then figure out what's _really_ wasting your time. Then, you
can write your own sugar for it.

In my opinion, document.getElementById is something that you end up writing a
lot and is really long, but with autocomplete in a good IDE, it's not a big
deal. Plus, any JS developer who sees it will know exactly what it does and
what it returns.

1\. [https://babeljs.io](https://babeljs.io)

------
vbezhenar
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.

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

~~~
creshal
I ran the first benchmark linked in the readme on my mobile phone (2013 Moto
G, i.e. old mid-end phone) and on my laptop (Thinkpad X230 i5-3320M), both on
Firefox:

    
    
        Sprint (phone):    33.1 kops
        jquery (phone):     8.8 kops
        zepto  (phone):    10.1 kops
    
        Sprint (laptop): 1435.2 kops
        jquery (laptop):   49.2 kops
        zepto  (laptop):   65.9 kops
    

Not bad, if that translates to real world performance.

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

~~~
shawabawa3
Agreed, ajax is usually the reason I just think fuck it and add jQuery

~~~
akx
Or you could just look at, say,
[http://microjs.com/#ajax](http://microjs.com/#ajax) to find a nicer
microlibrary to do exactly what you need.

~~~
untog
I wish microJS had fields for NPM/Bower compatibility. A lot of these micro
libraries don't have it.

------
latch
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](http://minifiedjs.com)

------
malandrew
virtual-dom is all you need: [https://github.com/Matt-Esch/virtual-
dom](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](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](https://github.com/TimBeyer/html-to-vdom)

------
camilo_u
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)"

~~~
hellweaver666
If you read the actual page you will see there are comparisons between Zepto,
Sprint and JQuery for a bunch of it's core functions.

~~~
rwaldron
Yes, performance comparisons, but those could've been measurements of no-op
versions of functions by the same name.

------
igvadaimon
I didn't find any information on browser support.

~~~
shawabawa3
It says IE10+, so I would guess any vaguely recent chrome/firefox/safari as
well

------
SimeVidas
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.

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

------
curiously
Hey guys found this neat little library

[http://vanilla-js.com/](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.

