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.

▲

jraph 2 hours ago | parent | next [-]

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/Element/querySele...

	▲	hyperhello 18 minutes ago \| parent [-]
		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.

▲

egeozcan 2 hours ago | parent | prev [-]

jQuery but gets compiled out like svelte... Not a bad idea at all.

▲

efskap an hour ago | parent [-]

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.

	▲	egeozcan an hour ago \| parent [-]
		Some things you build not because they are necessary, but because you can.