1. they tend not to be chainable/expression-oriented, you can't just `classList.add('foo').remove('bar').toggle('qux')` because the first two methods return `undefined` and the last one a boolean
2. they don't support set-oriented operations at all, it's a chore of manual iterations
Spot on! Those are probably the two most important blunt-sides of native APIs.
The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days"
I'd be happy if there's a jquery like polyfill library for DOM manipulation, but again - why not just custom jQuery builds and sizzle.js instead of re-inventing jQuery?
IE11 supports classList just fine, except for an argument to toggle. Nothing a little DOMTokenList.prototype change can't fix.
> The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days"
That will only happen if you're incompetent and will not write a few simple helper functions. And probably not even then. Plain DOM API is not that verbose over jQuery. Anyway, just look at what subset of jQuery you use the most and write helpers for that.
Your codebase is already grown by 1000s of lines by using jQuery, so you have quite a head start sizewise if you drop jQuery.
It was me, who asked him the question. The answer though isn't satisfactory enough. But again 140 chars is not a good bandwidth for meaningful conversations.
The claim is interesting, but isn't evident enough.
For example, how exactly is
var element = document.querySelectorAll('.container')
element.style.paddingTop = "50px";
element.className = element.className + 'header';
While I do agree in your comparison the second version looks better. At the same time, and this might be a tad too subjective to have much merit, it feels out of place to me.
Instead, I'd use one of the various approaches where I can create a style = {} object and then apply it to the element, which would just fit better within the rest of my javascript.
(which particular approach to use, .cssText, looping through props, or Object.assign, I'm not sure, but my point is any approach that applies a POJO to the node instead of chaining strikes me as more idiomatic. this is not a hill I'd die on though...)
Fair point, though for dynamic and large DOMs I dislike having to go and check whether I’m touching more than one element sometimes — not always though, sometimes it great to just $(‘#bleh’).hide() or what have you! Depends really
That's completely fair, and there are cases where unknowingly selecting and applying complex operations to many nodes is problematic but I think it's a great baseline/default regardless.
1. they tend not to be chainable/expression-oriented, you can't just `classList.add('foo').remove('bar').toggle('qux')` because the first two methods return `undefined` and the last one a boolean
2. they don't support set-oriented operations at all, it's a chore of manual iterations