7 ms·

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 t

• gbalduzzi 9mo ago
  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.
  • deleted 9mo ago
    [deleted]
  • flomo 9mo ago
    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.
    • epolanski 9mo ago
      It's not really about state but dom updates.
      • flomo 9mo ago
        After having some time to think about it, I've seen some really perverse DOM stuff in jquery. Like $(el).next().children(3) type stuff. So I think this stuff really fell-over when there was 'too much state' for the DOM.
        • phatskat 9mo ago
          I think if you want to go high-dom manipulation a la jQuery, and want some form of complex state, storing the state _on_ the DOM might make sense? Things like data attributes and such, but I also feel like that’s itching for something more like htmx or maybe svelte (I’ve not looked into either enough, so I may be completely off base). I do agree with the notion that jQuery is easy to mishandle when logic grows beyond a pretty narrow (mostly stateless) scope. It’s fantastic up until that point, and incredibly easy to footgun beyond it.
          • flomo 9mo ago
            Yeah, that's the thing, it might make sense in some simple 1-dimensional case, but beyond that it turns into spaghetti code (or a homebrew 'framework'). The big thing is that if you want to re-gigger some of the DOM, React is actually a lot nicer than jquery.
            • phatskat 9mo ago
              I’ll die on the “give me Vue over react any day” hill in that case, admittedly because I think React’s template/code mix is atrocious. I also _feel_ like React suffers from “why not do everything” syndrome, and that’s from a very naive perspective so grain or mountain of salt
              • flomo 9mo ago
                Yeah, I'm not hyping react specifically, just point out that vanilla/jquery or even htmx only works well when the state is not that complicated.
  • eloisius 9mo ago
    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.
    • skizm 9mo ago
      Facebook is PHP ironically.
      • ryan_n 9mo ago
        I think in 2026 Facebook is a conglomeration of a bunch of things... Definitely not just PHP anymore.
      • connorgurney 9mo ago
        It was once upon a time, hence them moving to HHVM to interpret it, but it’s been all but replaced with a PHP spinoff named Hacklang now.
• hsbauauvhabzb 9mo 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.
  • egeozcan 9mo ago
    jQuery but gets compiled out like svelte... Not a bad idea at all.
    • efskap 9mo ago
      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 9mo ago
        Some things you build not because they are necessary, but because you can.
  • jraph 9mo ago
    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/querySelector https://developer.mozilla.org/docs/Web/API/Document/querySel... https://developer.mozilla.org/docs/Web/API/Document/querySelectorAll https://developer.mozilla.org/docs/Web/API/Document/querySel... https://developer.mozilla.org/docs/Web/API/Element/querySelector https://developer.mozilla.org/docs/Web/API/Element/querySele... https://developer.mozilla.org/docs/Web/API/Element/querySelectorAll https://developer.mozilla.org/docs/Web/API/Element/querySele...
    • hyperhello 9mo ago
• sgt 9mo ago
  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.
  • tracker1 9mo ago
    I'm mixed on HTMX for going a step beyond interactive forms, it's fine... but much more and I find HTMX and server-side Blazor for that matter really janky... button events with a round trip to the server can just feel wrong. FWIW, also hated the old ASP.Net Webforms round trips (and omg massive event state on anything resembling dialup or less than a few mbps in the early 00's). I just wish that React and other SPA devs kept some awareness of total payload sizes... I'm more tolerant than most, but you start crossing over/into MB of compressed JS, it's too much. Then that starts getting janky.
• recursivedoubts 9mo ago
  yes: htmx grew out of intercooler.js, which was based on jquery and inspired by the jQuery.load() method: https://api.jquery.com/load/ 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
  • rolymath 9mo ago
    Are you Carson?
    • recursivedoubts 9mo ago
      yep