5 ms·

It's so gross: ... <tag hx-target="closest tr" hx-swap="outerHTML swap:1s" /> ... <button onclick="htmx.trigger('#request-button', 'htmx:abort'

by ctvo 3y ago

It's so gross: ... <tag hx-target="closest tr" hx-swap="outerHTML swap:1s" /> ... <button onclick="htmx.trigger('#request-button', 'htmx:abort')"> Cancel Request </button> ... If you don't want state management at the UI layer, totally understandable, move it to your server. You don't need a new framework with some whacky untyped DSL to do it. The swings in the front-end community move from one extreme to another so violently.

deleted 3y ago
[deleted]
Xeamek 3y ago
You literally do though, if you want to keep user experience on par. What alternative are you implying?
- ctvo 3y ago
  > You literally do though, if you want to keep user experience on par. On par with what? Use any of your existing UI frameworks and instead of keeping state client side, let the server tell you. Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. Dumbly reflect what the server returns. I understand this isn't what the tutorials for React, for example, show and breaks away from all the auxiliary things they've been using with it for state management, but there's nothing stopping you from doing this. You can do all of these things today. You don't need to adopt this. You don't need to move to server side templating and downloading chunks of HTML to inject into elements.
  - naasking 3y ago
    You'd end up partly reinventing htmlx to reduce network traffic, just badly. htmlx literally is just dumbly reflecting what the server returns.
  - Xeamek 3y ago
    >Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. So this literally what htmx does, no? Except You'd be operating on framework-sourced components rather then built in html structures. And the swapping itself would be performed by frameworks code rather then htmx library. Is that what you mean? If so then sure, I get that it would be cleaner then with htmx, but logic is the same and htmx simply let's you expand this logic for core html elements, rather then having to remake all of them into frameworks components that can handle the partial updating.
boredumb 3y ago
Yes I don't understand why using a simple templating engine doesn't suffice.
- grose 3y ago
  htmx isn't supposed to replace templating engines, it's supposed to provide the "last mile" to make your SSR pages (usually rendered with some template engine) more dynamic. I think it's a good idea. I have been writing vanilla JS for SSR'd pages for a while and inevitably reimplement some common patterns over and over (such as "load another page, select part of it, replace part of current page"), of which htmx looks to do a good job of capturing.
  - hirvi74 3y ago
    > it's supposed to provide the "last mile" to make your SSR pages (usually rendered with some template engine) more dynamic. I completely agree. It's basically breathed new life into my job's antiquated .Net SSR [Razor] pages. There is nothing HTMX is doing that I wasn't already able to accomplish with vanilla JS or Jquery, but holy shit has it reduced my need for either (which has also saved me time too).
simonw 3y ago
What's gross about that? I've been dipping more into HTMX recently and finding it to be a really productive way of building things. (Your onclick example there is a bit weird, I've not needed to use handlers like that at all.) Here's some recent HTMX I wrote: <button class="button" hx-post="/shifts/33/edit/" hx-vals='{"target_stewards": "1"}' hx-target="closest .shift-mini" hx-swap="outerHTML">-</button> That gives me a button which, when clicked, POSTs target_stewards=1 to /shifts/33/edit/ and replaces the nearest div class="shift-mini" with the HTML returned by that endpoint.
- ctvo 3y ago
  Oh my example wasn't a working one. I was just picking all the weird syntax I saw. What's gross about it is learning things like: ...hx-vals='{"target_stewards": "1"}' ...hx-target="closest .shift-mini" The fuck is this? Is this a string wrapping JSON in an HTML tag? In 2023?! And is the second one some weird DSL that targets an HTML element by CSS class? Why would I learn this. What does it look like to use in a large code base? I think the main difference between me and the folks who love this is I don't hate Javascript enough yet to explore this life.
  - simonw 3y ago
    It's a DSL in HTML attributes which covers almost all of what I need to build a dynamic web application. https://htmx.org/reference/#attributes https://htmx.org/reference/#attributes When this is clicked, submit this form to this place, then replace this thing with the returned HTML. It's such a breath of fresh air compared to the massive warren of SPA JavaScript I've had to fight with in the past.
    - jddj 3y ago
      > It's a DSL in HTML attributes which covers almost all of what I need to build a dynamic web application. Not quite though right? There's a very tightly coupled (and fairly useless for anything else) sibling endpoint for each of those calls, which exists on a backend somewhere to return the html that you need to progress. The alternative exists. You can spin up a rest API around a database schema in all of 5 minutes (eg. Pocketbase). Put alpinejs on the front end and you have everything htmx can do with no need for the server to get involved in whether or not a modal is open or closed on some client somewhere.
doubleorseven 3y ago
I've switched to htmx entirely but sometimes i do get this long strings that feels like parsing a json object using split(',').
Vinnl 3y ago
> The swings in the front-end community move from one extreme to another so violently. The majority of the front-end community is still programming React applications in their day job, like they have been for years, as far as I know.

by ctvo 3y ago

deleted 3y ago

[deleted]

Xeamek 3y ago

You literally do though, if you want to keep user experience on par. What alternative are you implying?

ctvo 3y ago
> You literally do though, if you want to keep user experience on par. On par with what? Use any of your existing UI frameworks and instead of keeping state client side, let the server tell you. Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. Dumbly reflect what the server returns. I understand this isn't what the tutorials for React, for example, show and breaks away from all the auxiliary things they've been using with it for state management, but there's nothing stopping you from doing this. You can do all of these things today. You don't need to adopt this. You don't need to move to server side templating and downloading chunks of HTML to inject into elements.
- naasking 3y ago
  You'd end up partly reinventing htmlx to reduce network traffic, just badly. htmlx literally is just dumbly reflecting what the server returns.
- Xeamek 3y ago
  >Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. So this literally what htmx does, no? Except You'd be operating on framework-sourced components rather then built in html structures. And the swapping itself would be performed by frameworks code rather then htmx library. Is that what you mean? If so then sure, I get that it would be cleaner then with htmx, but logic is the same and htmx simply let's you expand this logic for core html elements, rather then having to remake all of them into frameworks components that can handle the partial updating.

boredumb 3y ago

Yes I don't understand why using a simple templating engine doesn't suffice.

grose 3y ago
htmx isn't supposed to replace templating engines, it's supposed to provide the "last mile" to make your SSR pages (usually rendered with some template engine) more dynamic. I think it's a good idea. I have been writing vanilla JS for SSR'd pages for a while and inevitably reimplement some common patterns over and over (such as "load another page, select part of it, replace part of current page"), of which htmx looks to do a good job of capturing.
- hirvi74 3y ago
  > it's supposed to provide the "last mile" to make your SSR pages (usually rendered with some template engine) more dynamic. I completely agree. It's basically breathed new life into my job's antiquated .Net SSR [Razor] pages. There is nothing HTMX is doing that I wasn't already able to accomplish with vanilla JS or Jquery, but holy shit has it reduced my need for either (which has also saved me time too).

simonw 3y ago

What's gross about that? I've been dipping more into HTMX recently and finding it to be a really productive way of building things. (Your onclick example there is a bit weird, I've not needed to use handlers like that at all.) Here's some recent HTMX I wrote: <button class="button" hx-post="/shifts/33/edit/" hx-vals='{"target_stewards": "1"}' hx-target="closest .shift-mini" hx-swap="outerHTML">-</button> That gives me a button which, when clicked, POSTs target_stewards=1 to /shifts/33/edit/ and replaces the nearest div class="shift-mini" with the HTML returned by that endpoint.

ctvo 3y ago
Oh my example wasn't a working one. I was just picking all the weird syntax I saw. What's gross about it is learning things like: ...hx-vals='{"target_stewards": "1"}' ...hx-target="closest .shift-mini" The fuck is this? Is this a string wrapping JSON in an HTML tag? In 2023?! And is the second one some weird DSL that targets an HTML element by CSS class? Why would I learn this. What does it look like to use in a large code base? I think the main difference between me and the folks who love this is I don't hate Javascript enough yet to explore this life.
- simonw 3y ago
  It's a DSL in HTML attributes which covers almost all of what I need to build a dynamic web application. https://htmx.org/reference/#attributes https://htmx.org/reference/#attributes When this is clicked, submit this form to this place, then replace this thing with the returned HTML. It's such a breath of fresh air compared to the massive warren of SPA JavaScript I've had to fight with in the past.
  - jddj 3y ago
    > It's a DSL in HTML attributes which covers almost all of what I need to build a dynamic web application. Not quite though right? There's a very tightly coupled (and fairly useless for anything else) sibling endpoint for each of those calls, which exists on a backend somewhere to return the html that you need to progress. The alternative exists. You can spin up a rest API around a database schema in all of 5 minutes (eg. Pocketbase). Put alpinejs on the front end and you have everything htmx can do with no need for the server to get involved in whether or not a modal is open or closed on some client somewhere.

doubleorseven 3y ago

I've switched to htmx entirely but sometimes i do get this long strings that feels like parsing a json object using split(',').

Vinnl 3y ago

> The swings in the front-end community move from one extreme to another so violently. The majority of the front-end community is still programming React applications in their day job, like they have been for years, as far as I know.