Htmx 1.2.0 Release | Hacker News Reader

Htmx 1.2.0 Release

htmx.org

138 pointscrbelaus25 comments

I automatically upvote any project that includes a haiku in it's about page.

  javascript fatigue:
  longing for a hypertext
  already in hand

- https://htmx.org/

Not a huge release, but it supports the hx-headers attribute and has some polish.

Ben pate did some cool work with the preload extension, to aggressively load images:

https://htmx.org/extensions/preload/

thanks for your work!

one of the best libraries out there to deal with the modern complexity of making interactive websites. thanks for your work.

I had not previously heard of Htmx but this looks neat. My favorite part about Vue is it’s templating system so it feels just like supercharged html. Htmx reminds me of that, but seems to be nice combined with some other templating system like ERB. I’d love to try this out in a rails app to see how I like it compared to a separate JavaScript front and and rails in api mode!

Web dev is not my daily job but I maintain my wife's e-commerce store on the side.

I've brushed up enough with react and vue to know their idioms, and I agree with you, and this is why I tend to reach for vue if I can use it. It reminds me of the "old" template system, but better because components are much nicer than the spaghetti you could find yourself in with template inheritance. The state tracking is also simple, and while I understand many find this aspect of vue "simplistic" I have never hit a serious limitation for my limited use cases.

So what about htmx? Well, I've tried to like it, but the thing is I could not figure out how to track state server side without quickly devolving into jquery like spaghetti of "this has to update, but also this if that but not if also this, and I need to trigger X if Y". I might be missing the correct pattern in using it, but in the mean time I've gone back to Laravel blade templates (which I rather like for its component system, taking in the best idea from front end) together with vue inspired Alpine JS.

It’s a mindset change. With htmx you should start with the entire body updating and then scale down to achieve the ux you want, rather than thinking in terms of individual components updating. The htmx merge algorithm is pretty good and you often don’t need to target small parts of the ui.

Curious, why doesn't she use Shopify?

Because it's very expensive, she requires a fair amount of customization due to the type of business that would put the price really through the roof, and she has free labour in the form of her husband :)

How expensive would it be? Unless your wife's store is incredibly low volume or has a thin profit margin I don't see how Shopify would be too expensive to justify given the benefit it would bring over a home-grown solution.

And honestly, as I consumer I vastly prefer ordering direct from merchants who use Shopify or a similar platform. The entire experience is just extremely polished.

That being said, did you build the entire thing yourself or are you using one of the many open source options out there like WooCommerce/Prestashop/Nopcommerce/Magento?

I'm using woocommerce with a bunch of home built extras. As for the expense: there's no comparison, we crunched the numbers.

The problem is also there's a bunch of custom functionality needed and Shopify plugins do not cut it. Neither do woocommerce ones, for that matter, but I can code them up easily enough.

I have been using htmx in one project and I must say I’m very happy about it. Take some getting used to but it integrates well. This release fixes some of my biggest issues. Difficult to send different variables om different requests and the need for a form tag. Nice!

Thanks for your hard work I will give this release a try soon. :)

Why did this get pushed to the 2nd page so fast?

Not sure. Happened the last time htmx was on the front page too...

I noticed this too

We usually downweight follow-up posts [1]. Incremental releases of a project usually count as follow-ups when the project has been discussed recently. Since https://news.ycombinator.com/item?id=25232719 was a few months ago and https://news.ycombinator.com/item?id=23330881 a few months before that, we downweighted this one.

Such threads turn out to be quasidupes because they are almost always discussions about the project in general, not the specifics of the incremental release [2]. Incremental releases generally aren't SNI (significant new information) [3], but are rather occasions to talk again about the project as a whole. There's nothing wrong with that! It's great, it's fun, it's perfect. It's just that moderation is oriented towards nudging HN away from repetition. The default drift is strongly towards repetition, i.e. towards collapsing into the same set of popular, repeated topics. That's a failure mode for the site, and moderation's function is to keep nudging the system away from its failure modes.

I get that it's super frustrating when a project that you are interested in gets downweighted off HN's front page. That's why I'm writing such a long explanation. The moderation orientation is basically the opposite of the individual user's (which is why moderation is necessary in the first place). We have to worry about the site globally, while (and so!) individual users can focus on the things they like and care about, as they should.

If we didn't moderate follow-ups this way, HN's front page would be dominated by repeated discussions about the most popular topics. That would be bad for two reasons: repetition goes against curiosity [4], and it would leave less space on the frontpage for other topics—and frontpage space is the scarcest resource we have [5].

When we moderate this way, it's not a judgment against the project itself or how wonderful or interesting it is. It's a global optimization [6]. Unfortunately it ends up with most people feeling that their favorite stories are under-discussed on HN [7], because they are—there's never enough space. The important thing to realize is that people feel that way about every topic on HN. Even Rust hackers probably feel that way.

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

[2] The previous long explanation about this is at https://news.ycombinator.com/item?id=23071428.

[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so.... I'm not saying incremental releases aren't significant—of course they are! But the definition of SNI in this context is a little specialized: it means information capable of sustaining a substantially different HN discussion than the last one.

[4] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

[5] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[6] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

[7] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Their modal and tab examples fail accessibility requirements. Dunno if that's an issue with the examples or the library.

I like the idea and applaud the effort. But surely it's just abstracting and implementing Javascript and thus obfuscating the knowledge of how that works.

I see this happen too often.

But then, some people know how to fix a car. Others don't even know how to pop the hood. And this sort of thing is likely why.

On one hand: sure, anything you can express with an abstraction can be expressed without the abstraction. Some abstractions are unnecessary.

On the other hand: this introduces constraints that let you solve a class of problems without giving you so much rope that you can get tangled in it.

I'm very wary of adding unnecessary abstractions, but I'm very optimistic for solutions like HTMX. Lately I've been trying to build apps without any front-end JS, and there are pain points that make me want to allow JS sometimes. My hope is that HTMX/etc might solve these pain points without opening up Pandora's box and letting contributors write arbitrary JavaScript for managing the front-end.

I agree.

I'm less worried about abstractions than I am about dependencies.

Which is why I use the foundational core knowledge to build my own solutions/modules. If I can.

Would you target the same API, or invent your own?

I've just learned over the years that it can be ultimately painful to rely on a third-party API. For all sorts of reasons.

I used the words "If I can" on purpose. So yes, if I could, I would invent my own.

And the peace of mind, and hopeful reliability that can provide, can go a long way in your creative mindset.

There's more to it than that.

It's an attempt to complete HTML as a hypertext and allow more complete, modern UI programming within the hypertext & REST/HATEOAS paradigm.

Yes, it uses javascript to achieve this, but that's what's available.

Really cool, thanks!

Interesting concepts.

Let’s see if any FAANG companies or standards bodies or top tier open source frameworks adopt the extensions.

Reply on news.ycombinator.com