Comment by hsbauauvhabzb
18 hours ago
These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)].
While presumably jquery is slower than native selectors, maybe that could be pre-computed away.
In case you missed them: check out querySelector and querySelectorAll. They are closer to what the jQuery selector system does, and I think they were inspired by it.
If the verbosity bothers you, you can always define an utility function with a short name (although I'm not personally a fan of this kind of things).
https://developer.mozilla.org/docs/Web/API/Document/querySel...
https://developer.mozilla.org/docs/Web/API/Document/querySel...
https://developer.mozilla.org/docs/Web/API/Element/querySele...
https://developer.mozilla.org/docs/Web/API/Element/querySele...
body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.
Please don't mess with native prototypes though.
4 replies →
The $ (and $$) selector functions live on in chrome/chromium devtools!
const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);
jQuery but gets compiled out like svelte... Not a bad idea at all.
I hate to sound like a webdev stereotype but surely the parsing step of querySelector, which is cached, is not slow enough to warrant maintaining such a build step.
Some things you build not because they are necessary, but because you can.
Very simple jquery implementation with all the easy apis:
const $ = document.querySelectorAll
I usually do
and a similar one for $$.
Probably have to bind the this value.