4 ms·

Ok I'll just say it, why not use jquery instead ?

eternityforest 3y ago
I haven't personally used htmx(I use Vue and also like Svelte, and try to keep simple content in Markdown), but it seems declarative. I assume the compiler can give warnings at compile time?
- lgas 3y ago
  There's no compiler or compile time.
PetitPrince 3y ago
An early version of Htmx was in fact based on jQuery (https://intercoolerjs.org https://intercoolerjs.org).
brabel 3y ago
With JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. You write HTML which contains some directives like "hx-post='/clicked'" which will make a POST request to the `/clicked` URL path, similar to how HTML forms already work... and then you write the logic to generate more HTML in the server. That is: the server becomes responsible for the logic, not the client. You can still do JS on the client here and there, but that becomes much less needed.
- preommr 3y ago
  > With JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. ...instead write it in htmx, and html partials server-side using a templating library. What could possibly be wrong with splitting up the presentation logic and spreading it throughout the backend instead of just writing a little bit of javascript?
  - bb88 3y ago
    No need to build and maintain a whole api layer? One code base rather than two? Simple pages become simple again?
    - pier25 3y ago
      With jQuery and AJAX you're still sending HTML fragments just like with HTMX.
      - SJC_Hacker 3y ago
        > With jQuery and AJAX you're still sending HTML fragments just like with HTMX. AJAX philosophy was based around client side render - Asynchronous Javascript And XML. XML was JSON before JSON. jQuery is/was just a fetching library. The modern fetch() API as well as Promises/async/await made it largely obsolete, although some people still swear by it (they just released a new version actually). You can fetch raw HTML and dump it into innerHTML, but thats not how most people use it. They would do client-side render based on the XML (later JSON) returned.
  - bruh2 3y ago
    In my case, I already write a considerable amount of presentation logic in my the Django side of my project, merely because of Django's templating language limitations (which is okay, I prefer writing it in a sane language instead of wrangling esoteric features of DTL to get what I want). So adding a view function for an HTMX endpoint isn't really "spreading it around the backend" if your workflow is similar to what I described.
  - alt0_ 3y ago
    Not writing javascript is a good enough reason for me tbh. Makes the world a better place.

I haven't personally used htmx(I use Vue and also like Svelte, and try to keep simple content in Markdown), but it seems declarative. I assume the compiler can give warnings at compile time?

lgas 3y ago
There's no compiler or compile time.

PetitPrince 3y ago

An early version of Htmx was in fact based on jQuery (https://intercoolerjs.org https://intercoolerjs.org).

brabel 3y ago

With JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. You write HTML which contains some directives like "hx-post='/clicked'" which will make a POST request to the `/clicked` URL path, similar to how HTML forms already work... and then you write the logic to generate more HTML in the server. That is: the server becomes responsible for the logic, not the client. You can still do JS on the client here and there, but that becomes much less needed.

preommr 3y ago
> With JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. ...instead write it in htmx, and html partials server-side using a templating library. What could possibly be wrong with splitting up the presentation logic and spreading it throughout the backend instead of just writing a little bit of javascript?
- bb88 3y ago
  No need to build and maintain a whole api layer? One code base rather than two? Simple pages become simple again?
  - pier25 3y ago
    With jQuery and AJAX you're still sending HTML fragments just like with HTMX.
    - SJC_Hacker 3y ago
      > With jQuery and AJAX you're still sending HTML fragments just like with HTMX. AJAX philosophy was based around client side render - Asynchronous Javascript And XML. XML was JSON before JSON. jQuery is/was just a fetching library. The modern fetch() API as well as Promises/async/await made it largely obsolete, although some people still swear by it (they just released a new version actually). You can fetch raw HTML and dump it into innerHTML, but thats not how most people use it. They would do client-side render based on the XML (later JSON) returned.
- bruh2 3y ago
  In my case, I already write a considerable amount of presentation logic in my the Django side of my project, merely because of Django's templating language limitations (which is okay, I prefer writing it in a sane language instead of wrangling esoteric features of DTL to get what I want). So adding a view function for an HTMX endpoint isn't really "spreading it around the backend" if your workflow is similar to what I described.
- alt0_ 3y ago
  Not writing javascript is a good enough reason for me tbh. Makes the world a better place.