Htmx 1.9.3 Released | Hacker News Reader

Htmx 1.9.3 Released

htmx.org

66 pointsvyrotek17 comments

Ooh this looks interesting. I feel like I've re-invented totally half-arsed versions of this a few times because the json api approach just didn't sit right with me, but I've never had the vocabulary to clearly state why and what the alternative could/should be.

While the documentation is great, check out the essays: https://htmx.org/essays/

There’s also their book:

https://hypermedia.systems/

Some shortcomings in larger Projects that maybe my imaginary problems:

- You cannot have reusable components. If you want that, you need to combine server side templating.

- Because rendering HTML is OK and HTML is the UI, if not disciplined enough, your app would be generating shards and shreds of application UI that are highly contextual and not as repeatable or reusable.

- A client other than browser can't consume HTML as easily such as a cron job or Flutter/Android/iOS app .

But other than that, I think htmx is innovative enough that it should be part of the browser natively.

EDIT: About browser implementation

> A client other than browser can't consume HTML as easily such as a cron job or Flutter/Android/iOS app

what you do is to return a json representation of the data if the 'Accept' header is json from the client (which, you control or can direct them to send right?).

Things that make me think we have modern development all wrong First is htmx, second is ape/cosmoc/redbean/fullmoon

I thought they stopped developing htmx and instead moved to full time shit posting

i'm pretty efficient w/ my time, but shitposting has been a focus lately it's true

Damn, why does everything have to be so complex to make a UI

this is actually less complex than the "standard" react frontend frameworks to produce a UI imho.

This is basically the good old days of server side rendering, and html fragments, and you'd used to use jquery to just wholesale replace portions of the dom with the returned value from the server via an ajax request.

it's always less complex when you look at a toy example. Then you get more complex requirements that make the html templates unmanagable or even impossible in html. Then you have to drop some javascript anyway, then more and more of them. Then you wonder why cling on to the futile effort of "programming" in html anyway.

There have been many cycles of doing "everything on the server", then "everything on the client", and back again. Right now, it's swinging back to the doing everything on the server. First it was mainframes, then PCs, then Citrix, then laptops, HTML, client-side rendering, server-side rendering, etc...

Server-side rendering has a huge advantage though: it needs one less "layer". With client-side rendering you have code in the browser, code on the server, and code in the database. You need defined protocols between every layer. With three layers and two hops, that's effectively 5 things you need to develop.

With HTML-based development, the client side code basically doesn't exist any more. You don't need to send the browser JSON via an API to be decoded and converted to HTML. You just send the HTML as-is. Just write the web server and the database, connect them, and you're done. That's 3 things you need to develop.

I've watched developer after developer start trivial web pages -- not even really apps -- with stacks like Angular and get bogged down in the complexity of things like client-side authentication protocols, multi-API security, making sure JSON APIs don't leak information inadvertently, having to batch queries with GraphQL, and on, and on, and on...

None of that is necessary with HTML being generated by the server.

This is where I am after trying htmx out.

Trying to get good user feedback during the automatic inflight ajax seems impossible.

Complex multi target ui is nastier than just using vue/react.

https://htmx.org/docs/#indicators

https://htmx.org/examples/update-other-content/

As you can see on the examples, multi component update requires target expansion or event triggers which means custom js.

In the end complex ui gives me worse code than reactive js. I have to think alot harder about page or htmx dom scope with htmx.

for sure if you have a super complicated UI

but often you don't

https://htmx.org/essays/when-to-use-hypermedia/

i'd de-escalate the whole thing by turning it from an "either/or" into a "sometimes/as well"

htmx & hypermedia is a tool, nothing more

> but often you don't

who are you to say so?

Reply on news.ycombinator.com