Comment by jollyllama

2 years ago

Indeed, that baggage is all that I avoid by using HTMX.

You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.

  • Have you ever worked with just raw js?

    Anything more than a todo list becomes unwieldy almost instantly.

    Taking a small dependency to avoid that is well worth it.

    Taking a whole “virtual dom” may be overkill though (looking at you, react)

    • > Have you ever worked with just raw js?

      Yes

      > Anything more than a todo list becomes unwieldy almost instantly.

      That's not a fact, just your personal experience

      > Taking a small dependency to avoid that is well worth it.

      Sometimes, yeah. Sometimes, no.

      > Taking a whole “virtual dom” may be overkill though (looking at you, react)

      In most cases, probably yeah. React was created to solve a specific problem a specific company experienced, then the community took that solution and tried to put it everywhere. Results are bound to be "not optimal".

  • It's one small dependency. Worst case, you write the library yourself.

    You send a request to the backend, it then sends you HTML back (all rendered in the backend using a templating language such as Django templating engine, Twig or Liquid), you insert it into a div or so.

    Htmx was Intercooler, worst case you create your own. But no additional scripts needed.

    I've been able to kick out Vue out because Htmx covers my use case.

    • > It's one small dependency. Worst case, you write the library yourself.

      Every abstraction comes with a cost :) I'm not saying it never makes sense to use React, Vue, Htmx or anything else. But that's besides this conversation.

      > You send a request to the backend, it then sends you HTML back

      You're just trading doing stuff in the frontend for doing stuff in the frontend + backend. Might make sense in a lot of cases, while not making sense in other cases.

      1 reply →