3 ms·

> And that's a best-case scenario, then you start traversing the DOM tree, adding elements, using events delegation and changing attributes and things go south

> And that's a best-case scenario, then you start traversing the DOM tree, adding elements, using events delegation and changing attributes and things go south fast. Why would things so south? The DOM API, while not very elegant, is very simple and straight forward. So you need some loops because jQuery hides that for you, so what? Why does using the DOM API make you think things go south fast?

masklinn 12y ago
> Why would things so south? The DOM API, while not very elegant It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL. > is very simple and straight forward I completely disagree on both count, the API is neither simple nor straightforward, many tasks remain convoluted even with HTML5's additions of a number of long-awaited APIs (e.g.: repeatedly adding children at the start of a possibly child-less element) and the userland code is made unnecessarily complex not by a simple API but by an insufficient one (e.g. enjoy handrolling element-relative events delegation Element#matches is a pointless waste of API space). And then there's the truly idiotic stuff added on top, such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language. Thank god the WhatWG managed to keep that garbage out of the new APIs they introduced. > So you need some loops because jQuery hides that for you, so what? So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets.
- BinaryIdiot 12y ago
  There are plenty of reasons to not like the DOM API but you're not doing a good job stating your case. > It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL. This is kinda what you already said before but haven't really clarified. What doesn't integrate correctly with the host language? It's certainly inelegant but "horrendously verbose" seems quite extreme. Creating, deleting and modifying elements is easy and straightforward, adding and removing event handlers is easy and straightforward; you rarely need more features than that. Could you provide some insights here? > repeatedly adding children at the start of a possibly child-less element What are you referring to here? insertChild has let you do this and has been part of the standard since 1997. Are you referring to something else or a specific issue? > enjoy handrolling element-relative events delegation What are you referring to when you say "handrolling"? Are you referring to jQuery's ability to set, say, a click event on a parent to target the children so the children can be removed without changing it? I hope that's not all you're referring to because that's dead simple to deal with and using jQuery's event bubbling isn't always very speedy. If you're creating these elements why can't you attach and detact event handlers? > Element#matches is a pointless waste of API space Matches allows you to look to see if a match exists without returning the data. This may provide slightly better performance if all you need to do is a check for something. I agree it's not entirely useful but a "waste of space" is a bit extreme; it can serve a purpose and it's a very small addition. Nit-picking on single methods isn't exactly helpful. > such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language First you complain the DOM API doesn't integrate into the host language and now you complain about live NodeLists when this is using a JavaScript semantic. You need to pick one and not conflate the two. JavaScript passes objects by copy of reference (meaning you can modify the original but not replace). Implementing NodeList to be live makes perfect sense here. Would you prefer the DOM API actually NOT follow standard JavaScript and do something...funny? > So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets. The features you sighted previously allow you to act on multiple NodeList items without iterating through them directly. jQuery is still iterating through them in the background. How a loop is "overly complex" for "no good reason" I do not understand.

masklinn 12y ago

> Why would things so south? The DOM API, while not very elegant It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL. > is very simple and straight forward I completely disagree on both count, the API is neither simple nor straightforward, many tasks remain convoluted even with HTML5's additions of a number of long-awaited APIs (e.g.: repeatedly adding children at the start of a possibly child-less element) and the userland code is made unnecessarily complex not by a simple API but by an insufficient one (e.g. enjoy handrolling element-relative events delegation Element#matches is a pointless waste of API space). And then there's the truly idiotic stuff added on top, such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language. Thank god the WhatWG managed to keep that garbage out of the new APIs they introduced. > So you need some loops because jQuery hides that for you, so what? So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets.

BinaryIdiot 12y ago
There are plenty of reasons to not like the DOM API but you're not doing a good job stating your case. > It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL. This is kinda what you already said before but haven't really clarified. What doesn't integrate correctly with the host language? It's certainly inelegant but "horrendously verbose" seems quite extreme. Creating, deleting and modifying elements is easy and straightforward, adding and removing event handlers is easy and straightforward; you rarely need more features than that. Could you provide some insights here? > repeatedly adding children at the start of a possibly child-less element What are you referring to here? insertChild has let you do this and has been part of the standard since 1997. Are you referring to something else or a specific issue? > enjoy handrolling element-relative events delegation What are you referring to when you say "handrolling"? Are you referring to jQuery's ability to set, say, a click event on a parent to target the children so the children can be removed without changing it? I hope that's not all you're referring to because that's dead simple to deal with and using jQuery's event bubbling isn't always very speedy. If you're creating these elements why can't you attach and detact event handlers? > Element#matches is a pointless waste of API space Matches allows you to look to see if a match exists without returning the data. This may provide slightly better performance if all you need to do is a check for something. I agree it's not entirely useful but a "waste of space" is a bit extreme; it can serve a purpose and it's a very small addition. Nit-picking on single methods isn't exactly helpful. > such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language First you complain the DOM API doesn't integrate into the host language and now you complain about live NodeLists when this is using a JavaScript semantic. You need to pick one and not conflate the two. JavaScript passes objects by copy of reference (meaning you can modify the original but not replace). Implementing NodeList to be live makes perfect sense here. Would you prefer the DOM API actually NOT follow standard JavaScript and do something...funny? > So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets. The features you sighted previously allow you to act on multiple NodeList items without iterating through them directly. jQuery is still iterating through them in the background. How a loop is "overly complex" for "no good reason" I do not understand.