4 ms·

The core jQuery idea - using CSS selectors to find DOM elements and then changing their properties and firing/monitoring events - fits so naturally with the HTM

The core jQuery idea - using CSS selectors to find DOM elements and then changing their properties and firing/monitoring events - fits so naturally with the HTML/CSS model that it feels like it should be part of the standard DOM API. I'm not aware of any JS.next-type efforts to do this though :(

benhowdle89 14y ago
Take the DOM API away and JavaScript is a great experience!
- PommeDeTerre 14y ago
  Except that it isn't. Just because the DOM is indeed horrible it does not mean that JavaScript is not a bad experience, either. 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.
  - masklinn 14y ago
    > Its scoping is poorly designed. 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.
    - ufo 14y ago
      functions scope sucks though :( Writing callbacks inside a loop can be a pain.
      - quarterto 14y ago
        ES6 will have proper block scoping using let. You can use that today in JavaScript 1.8 compliant engines (so far, just SpiderMonkey).
      - masklinn 14y ago
        That's not really an issue of function scope. It's an issue of closing over mutable bindings, though loops + function scope do make it more likely for the issue to arise. And ES6 adds block scopes (via `let`, inherited from Mozilla's javascript extensions). That strays from the original complaint though.
  - spion 14y ago
    Most of the stupid ideas like semicolon insertion are not major deal breakers [1]. Yes, they are annoying, but nothing that can't be fixed with a lint program. You can treat your lint program as a stricter replacement for a syntax error checker. 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/substack/node-browserify https://github.com/azer/onejs https://github.com/azer/onejs etc.
davecardwell 14y ago
element.querySelector and .querySelectorAll [1] provide this functionality. Sizzle [2], the selector engine at the core of jQuery, uses it where available and works around some browser inconsistencies. [1] http://caniuse.com/queryselector http://caniuse.com/queryselector [2] http://sizzlejs.com/ http://sizzlejs.com/
- masklinn 14y ago
  > element.querySelector and .querySelectorAll [1] 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.
  - jackmoore 14y ago
    Iterating a NodeList isn't so bad: 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?
    - masklinn 14y ago
      The DOM WebIDL does not know what an array is. Though an IDL extension/annotation added some time ago allows inheriting IDL interfaces from core language objects or interfaces rather than the root object (http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass), and DOM4 adds this annotation to NodeList http://dom.spec.whatwg.org/#interface-nodelist http://dom.spec.whatwg.org/#interface-nodelist
jacobr 14y ago
To just make the DOM API's a little cleaner is so simple in a language like JavaScript, why not just create the abstractions as you need them? 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'));
- jdavis703 14y ago
  JQuery is slowly moving in that direction [0] and YUI has long let you pick and choose which "abstractions" you need [1]. [0] https://github.com/jquery/jquery/blob/master/README.md https://github.com/jquery/jquery/blob/master/README.md [1] http://yuilibrary.com/yui/configurator/ http://yuilibrary.com/yui/configurator/ [edited with better link to JQuery build documentation]
- masklinn 14y ago
  > This is not something you should use in production, but just a quick example: Your quick example is risky and likely broken to all MSIE <= 8: https://developer.mozilla.org/en-US/docs/DOM/NodeList#Why_cant_I_use_forEach_or_map_on_a_NodeList.3F https://developer.mozilla.org/en-US/docs/DOM/NodeList#Why_ca...
  - mattmanser 14y ago
    There's no forEach in IE8.

benhowdle89 14y ago

Take the DOM API away and JavaScript is a great experience!

PommeDeTerre 14y ago
Except that it isn't. Just because the DOM is indeed horrible it does not mean that JavaScript is not a bad experience, either. 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.
- masklinn 14y ago
  > Its scoping is poorly designed. 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.
  - ufo 14y ago
    functions scope sucks though :( Writing callbacks inside a loop can be a pain.
    - quarterto 14y ago
      ES6 will have proper block scoping using let. You can use that today in JavaScript 1.8 compliant engines (so far, just SpiderMonkey).
    - masklinn 14y ago
      That's not really an issue of function scope. It's an issue of closing over mutable bindings, though loops + function scope do make it more likely for the issue to arise. And ES6 adds block scopes (via `let`, inherited from Mozilla's javascript extensions). That strays from the original complaint though.
- spion 14y ago
  Most of the stupid ideas like semicolon insertion are not major deal breakers [1]. Yes, they are annoying, but nothing that can't be fixed with a lint program. You can treat your lint program as a stricter replacement for a syntax error checker. 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/substack/node-browserify https://github.com/azer/onejs https://github.com/azer/onejs etc.

davecardwell 14y ago

element.querySelector and .querySelectorAll [1] provide this functionality. Sizzle [2], the selector engine at the core of jQuery, uses it where available and works around some browser inconsistencies. [1] http://caniuse.com/queryselector http://caniuse.com/queryselector [2] http://sizzlejs.com/ http://sizzlejs.com/

masklinn 14y ago
> element.querySelector and .querySelectorAll [1] 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.
- jackmoore 14y ago
  Iterating a NodeList isn't so bad: 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?
  - masklinn 14y ago
    The DOM WebIDL does not know what an array is. Though an IDL extension/annotation added some time ago allows inheriting IDL interfaces from core language objects or interfaces rather than the root object (http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass), and DOM4 adds this annotation to NodeList http://dom.spec.whatwg.org/#interface-nodelist http://dom.spec.whatwg.org/#interface-nodelist

jacobr 14y ago

To just make the DOM API's a little cleaner is so simple in a language like JavaScript, why not just create the abstractions as you need them? 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'));

jdavis703 14y ago
JQuery is slowly moving in that direction [0] and YUI has long let you pick and choose which "abstractions" you need [1]. [0] https://github.com/jquery/jquery/blob/master/README.md https://github.com/jquery/jquery/blob/master/README.md [1] http://yuilibrary.com/yui/configurator/ http://yuilibrary.com/yui/configurator/ [edited with better link to JQuery build documentation]
masklinn 14y ago
> This is not something you should use in production, but just a quick example: Your quick example is risky and likely broken to all MSIE <= 8: https://developer.mozilla.org/en-US/docs/DOM/NodeList#Why_cant_I_use_forEach_or_map_on_a_NodeList.3F https://developer.mozilla.org/en-US/docs/DOM/NodeList#Why_ca...
- mattmanser 14y ago
  There's no forEach in IE8.