Htmx 1.2.0 Release

https://htmx.org/posts/2021-2-13-htmx-1.2.0-is-released/

by crbelaus • 5 years ago

138 25 5 years ago

htmx.org

recursivedoubts2• 5 years ago

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/

arkis22• 5 years ago

thanks for your work!

dzonga• 5 years ago

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

rad_gruchalski• 5 years ago

Really cool, thanks!

catskull• 5 years ago

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!

lordgroff3• 5 years ago

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.

e67f70028a46fba2• 5 years ago

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.

mritchie712• 5 years ago

Curious, why doesn't she use Shopify?

shroom• 5 years ago

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

ourcat3• 5 years ago

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.

jhardy542• 5 years ago

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.

ourcat3• 5 years ago

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.

recursivedoubts2• 5 years ago

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.

intrepidhero• 5 years ago

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/

robertoandred• 5 years ago

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

learc83• 5 years ago

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

e67f70028a46fba2• 5 years ago

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

kowlo• 5 years ago

I noticed this too

dang• 5 years ago

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

wwww4all• 5 years ago

Interesting concepts.

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

Htmx 1.2.0 Release

Related Stories