Comment by flomo
19 hours ago
Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?"
Anyway, jQuery always did the job, use it forever if it solves your problems.
19 hours ago
Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?"
Anyway, jQuery always did the job, use it forever if it solves your problems.
yes: htmx grew out of intercooler.js, which was based on jquery and inspired by the jQuery.load() method:
https://api.jquery.com/load/
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
deeply respect and love jquery
Are you Carson?
yep
The problem with jQuery is that, being imperative, it quickly becomes complex when you need to handle more than one thing because you need to cover imperatively all cases.
Yeah, that's the other HN koan about "You probably don't need React if..." But if you are using jquery/vanilla to shove state into your HTML, you probably actually do need something like react.
It's not really about state but dom updates.
Part of me feels the same way, and ~2015 me was full on SPA believer, but nowadays I sigh a little sigh of relief when I land on a site with the aesthetic markers of PHP and jQuery and not whatever Facebook Marketplace is made out of. Not saying I’d personally want to code in either of them, but I appreciate that they work (or fail) predictably, and usually don’t grind my browser tab to a halt. Maybe it’s because sites that used jQuery and survived, survived because they didn’t exceed a very low threshold of complexity.
Facebook is PHP ironically.
2 replies →
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.
6 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.
1 reply →
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.
I pretty much use HTMX and vanilla JS to solve most problems, when I use Django at least. Keeps things simple and gives that SPA feel to the app too.