Hacker News Reader

Comment by ctvo | Hacker News Reader

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.

View on HN

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.

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.

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

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.

> 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.

https://htmx.org/essays/two-approaches-to-decoupling/

https://htmx.org/essays/splitting-your-apis/

Unfortunately, the more of this I read the more I'm convinced. Especially in the context of rapid prototyping but also in larger projects.

I love serverside templating. I use go templates, asp net razorpages and old laravel blade across various projects. It's hard for me to see the enthusiasm for htmx as anything but an overcorrection from react, and the project itself feels like it chooses ideology over function (nothing wrong with that, just not great for getting things done).

In a year I do think we'll see the typical stream of rewrites.

> I use go templates, asp net razorpages and old laravel blade across various projects.

HTMX + Razor Pages/Views is so freaking nice. It's seriously increased reusability so much for me. HTMX has also greatly reduced the amount of JS I have to write for the same functionality I was getting with Vanilla JS.

Depending on what I need, I find the JS API that HTMX has to be very helpful, albeit I wish a few things were a tad better/more clear in the docs for that area (or I was just too much of an idiot to figure out). None the less, I have no intentions of jumping ship from HTMX anytime soon.

maybe

https://htmx.org/essays/a-real-world-react-to-htmx-port/

> 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.

Modals are driven by database state, so you can't really get rid of that.

How you can call this a breath of fresh air is beyond me. This is insanely ugly to me.

> And is the second one some weird DSL

What's weird about standard CSS selectors? Maybe you should actually see some testimonials before judging, like: https://www.youtube.com/watch?v=3GObi93tjZI

What's weird is it's an untyped string embedded in an HTML template that does things. The API signature is string in magic out. How do I unit test this? How do we know when someone fat fingered something?

YAML IaC roasted to well done levels right here.

How we went from code over configuration to YAML hell á la kubernetes and terraform is still beyond me…

Do you have similar objections about untyped strings when setting the "class" attribute? The class attribute also "does things", like change layout, text styling and even behaviour in CSS animations.

How do you unit test any dynamic behaviour on HTML pages? There are multiple ways depending on what you want to check.

I mean I use tailwind or a framework like Chakra so yeah, my styling is typed or at the very least has robust editor support

"How do I unit test this?"

Playwright should work great for that.

You use Playwright for unit testing? That sounds like an incredibly slow and painful process vs @testing-library.

how do you feel about the href attribute in anchor tags?

Wym? Literally any html attributes/class_names are 'untyped strings that do things'.

How is that any different?

GP probably means business logic, not setting background color on a div. Coupling HTML with business logic inline reminds me of the good old DHTML. I am really glad the industry moved on from that mess.

Business logic must always be executed server-side anyway, so regardless, the client is asking the server "show me the results of this applying business logic".

You can do this by having the business logic return a data structure that the client then renders into UI itself, but now you have a state synchronization problem, ie. you have to keep client data structures in sync with server data structures.

Alternately, you can use the classic REST pattern: hypermedia as the engine of application state (HATEOAS), and let the server literally tell you what to render, so client state trivially matches server state. This is the htmx way.

> 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.

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

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.

> 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).

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

You literally do though, if you want to keep user experience on par.

What alternative are you implying?

> 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.

>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.

You'd end up partly reinventing htmlx to reduce network traffic, just badly. htmlx literally is just dumbly reflecting what the server returns.

Reply on news.ycombinator.com