var d = document.createElement("div");
d.className = "new";
d.innerHTML = "<p>Hi Sprint</p>";
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
}
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)
},
Modifying your example:
var d = document.querySelectorAll('div');
d = Array.prototype.slice.call(d);
d.forEach(function(el){ el.classList.add('new') });
$('div').addClass('new'); [].forEach.call(document.querySelectorAll('div'), function(el) {
el.classList.add('new');
});
Though with frameworks like Angular or React I'm beginning to question whether we should ever be writing code like this at all.
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.
But I suppose I'd love one that is thinner, like your "very thin wrapper", if anybody has pointers.
Don't do that.
To save you some work: http://youmightnotneedjquery.com/
A tiny, lightning fast jQuery-like library for modern browsers.
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!
Though JQuery still recommends the bigger library for most users (unless you're embedding in a mobile app or stuff like that).
I'm curious if it will take jQuery plugins though. Will try later.
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.
Tests, or it doesn't exist.
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).
I have dropped jQuery completely except for when I need some of its plugins because I end up having to access the internal DOM objects too often and using $el.get(0) all over the place is ugly and a PITA.
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
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
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.
> So, here’s the TL;DR for version 3.0 of the jQuery API:
> * If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
> * If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
from http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-genera...
I personally currently need to support IE9 which I wouldn't class as an "evergreen leading-edge browser". I was hoping for a more in depth compatibility chart that named specific versions.
$('.something').toggleClass('collapsed')
.click(somethingClicked);
(And even the different Webkit ports can't be thrown into the same bag.
Compare e.g. Safari on OSX, Safari on Windows, Midori on Windows and Midori on Linux. Two webkit browsers, crass rendering and behavioural differences between them and on each platform.)
If you want to devote dev time to specialize for the relative handful of folks who run Firefox on their mobile device, that's your call.
jQuery solve problems with the various builtin APIs like DOM etc that are part of either Javascript or the web browser host
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.
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.
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.