I'm not aware of any JS.next-type efforts to do this though :(
I'm not aware of any JS.next-type efforts to do this though :(
[1] http://caniuse.com/queryselector [2] http://sizzlejs.com/
They provide a limited part of the selection function. Altering nodes, creating new nodes (and adding them to the DOM tree) and programmatic DOM tree traversals? Not so much, you get very clumsy and verbose APIs for that in the regular DOM. Same with DOM event handling, jQuery provides nice shortcuts for binding and delegation, the DOM... not so much (even if you limit yourself to IE9 and don't have to handle the garbage that is the oldIE event model)
Also, as usual with the fucking DOM, querySelectorAll returns a NodeList which means you can't trivially use higher-order iterators on it (you've got to use the "generics" version and hope it works correctly everywhere).
Fuck, that makes me angry again, the DOM is such a clusterfuck of an API.
Array.prototype.forEach.call(
document.querySelectorAll('a'), function(el){
console.log(el);
});
But, I agree with the point. If the NodeList isn't live, like it is for the other DOM querying methods, then what is the point in returning a NodeList instead of an array?This is not something you should use in production, but just a quick example:
function setAttr (attr, val) {
return function (elem) { elem.setAttribute(attr, val); };
}
NodeList.prototype.forEach = Array.prototype.forEach;
var $ = document.querySelectorAll.bind(document);
$('.foo').forEach(setAttr('foo', 'bar'));[0] https://github.com/jquery/jquery/blob/master/README.md [1] http://yuilibrary.com/yui/configurator/
[edited with better link to JQuery build documentation]
Your quick example is risky and likely broken to all MSIE <= 8: https://developer.mozilla.org/en-US/docs/DOM/NodeList#Why_ca...
I think that the problems with JavaScript are very obvious to developers who have used multiple languages (aside from PHP). There are far too many unacceptable quirks. It is full of absolutely stupid ideas, like semicolon insertion. Its scoping is poorly designed. In practice, prototype-based OO is inferior to class-based OO. Its type system is not sensible. It lacks proper support for namespacing and modularity (sorry, CommonJS is a hack and nothing more). It does not have a practical standard library. Its development environments and debuggers are quite lacking. And these are just some of its numerous issues.
So for such a small language, it has many critical flaws. This situation is far worse than what we see when dealing with most other languages. And none of those problems that are listed above have to do with the DOM, so disregarding it has absolutely no impact on them.
Actually its scoping is very well defined: javascript has function scoping and a global scope. That's it.
> In practice, prototype-based OO is inferior to class-based OO.
That is plain and simply not true. A shitty object model is inferior to a good object model, but that's got nothing to do with prototypes v classes (as far as I'm concerned, the world would probably be a lot more enjoyable if more language implemented a self-like object model).
> Its development environments and debuggers are quite lacking.
They're already ahead of most non-corporate languages and keep improving at a fast pace.
And ES6 adds block scopes (via `let`, inherited from Mozilla's javascript extensions).
That strays from the original complaint though.
Class-based OO is implementable with prototype-based OO (with some exceptions such as "protected" which are mostly unnecessary when first class functions are available). In practice, this means you need to learn how to use it (unfortunately the quirky way its implemented in JS doesn't help this at all)
CommonJS provides quite excellent namespacing and modularity - its only a hack because it doesn't work in browsers [2]
The standard library is admittedly lacking but there are many libraries that cover this gap, some of them being de facto standard.
Development environment support is pretty good for a dynamic language, with multiple IDEs doing some form of static analysis and completion
Debugging is pretty good, with modern browsers supporting breakpoints, watch expressions, live code editing, logging with object inspection etc. For node you have the v8 debugger and node-inspector providing pretty much the same.
There are far more pressing issues with JS than the ones you mentioned, like the verbose function syntax (mostly fixed in Harmony), lack of coroutines (mostly fixed with Harmony generators), lack of something like ruby's method_missing or python's __getattr__ (fixed with Harmony proxies)...
[1]: an example of a major deal breaker is not having first class functions
[2]: actually, it kind-of does - https://github.com/substack/node-browserify https://github.com/azer/onejs etc.