Hacker News Reader

Comment by ctvo | Hacker News Reader

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.

View on HN

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.

maybe

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

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

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

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

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.

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

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…

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

Reply on news.ycombinator.com