Do you have any examples? In my opinion the DOM API only sucked pre-IE9 because of all the inconsistencies and incompatibilities.
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.
> I would argue that the second half is a little unfair, since that style of coding is entirely influenced by jQuery. You usually don't actually need to trigger a real DOM event there, you just want to execute some callback as if the element was clicked.
Maybe I'm missing something, but the second half is adding an event handler (`somethingClicked` is presumably a function). That seems like a _very_ common thing to do regardless of jQuery.
> This does get a little uglier if the intent is that you have multiple '.something' elements, though. That part of the DOM API will always be pretty gross compared to jQuery, I think.
Well yeah hence my remark. Working on a single node in a single modern browser, the snippet will turn into
var node = document.querySelector('.something');
node.classList.toggle('collapsed')
node.addEventListener('click', somethingClicked);
but if you need multiple nodes, now you have to manually loop and beware your closures.
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.
> 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?
> 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.
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?
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.
