I totally agree that jQuery is a significant improvement over the native DOM as an API, and that thinking about/profiling what your jQuery code is doing is a be

I totally agree that jQuery is a significant improvement over the native DOM as an API, and that thinking about/profiling what your jQuery code is doing is a better approach than deciding to try to avoid jQuery whenever possible. However, throwing away jQuery for whatever reason (as we have on the iOS-only project I've been on for the last 3 months) doesn't necessarily mean you're stuck in verbosity hell. We just tried to look for the points where it seemed most verbose/painful and wrote thin jQuery-ish wrappers around native stuff... so, for example, there's a short alias for querySelector All which gloms `Array.prototype.forEach` onto the return value, and class manipulation functions, and a handful of other things. Last time I checked, the library fits on one screen and none of the functions are longer than 4 lines. Not necessarily the right approach for every project, but neither has it been a descent into hell. Interestingly, I've never found event binding to be a particular pain point; the thing I'm really getting tired of is writing `e.preventDefault()`, but jQuery isn't going to save me from that anyway.