Or, you know, use the Javascript DOM APIs? They're really not at all that bad.<p><pre><code> var d = document.createElement("div");
d.className = "new";
d.innerHTML = "<p>Hi Sprint</p>";
</code></pre>
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:<p>function toArray(o) { return Array.prototype.slice.call(o) }<p>Instead it's:<p><pre><code> var toArray = function(obj) {
var arr = []
var i = obj.length
while (i--) {
arr[i] = obj[i]
}
return arr
}
</code></pre>
This is just silly:<p><pre><code> prepend: function() {
insertHTML.call(this, "afterbegin", arguments)
return this
},
var insertHTML = function(position, args) {
var argsLen = args.length
var contents = args
</code></pre>
[...]<p><pre><code> var domMethods = {
afterbegin: function(el) {
this.insertBefore(el, this.firstChild)
},
</code></pre>
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 <i>like</i> Javascript, I just wish people would learn how to work with the language it instead of replacing the API wholesale.
<p><pre><code> A tiny, lightning fast jQuery-like library for modern browsers.
</code></pre>
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.<p>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. :)<p>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.<p>But, with every <i>new</i> 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
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've used [the very badly named] minified.js in the past, and I was quite happy. Has optional support for IE6.<p><a href="http://minifiedjs.com" rel="nofollow">http://minifiedjs.com</a>
virtual-dom is all you need:
<a href="https://github.com/Matt-Esch/virtual-dom" rel="nofollow">https://github.com/Matt-Esch/virtual-dom</a><p>There is a reason why both elm and mercury uses virtual-dom under the hood to generate and manipulate the DOM.<p>Plus you can render server-side:
<a href="https://github.com/nthtran/vdom-to-html" rel="nofollow">https://github.com/nthtran/vdom-to-html</a><p>If you still want to work with existing html like templates, there is this project:
<a href="https://github.com/TimBeyer/html-to-vdom" rel="nofollow">https://github.com/TimBeyer/html-to-vdom</a>
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)"
Hey guys found this neat little library<p><a href="http://vanilla-js.com/" rel="nofollow">http://vanilla-js.com/</a><p>I get 12+ million operation (a true master race class) vs advertised 800,000 and peasantry of jQuery's 300,000.<p>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.