Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

htmx

htmx.org

Post reply on HN
Print view View original

11–20 of 291 posts

Re: htmx

#11

Post by dmix »

vyrotek wrote: post #4
bluedays wrote: post #2

how many times has this been posted here?

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I count about ~6 generic submissions to htmx root domain or direct /docs with upvotes. More generally it's higher if you include blog posts or self-HN posts. The original submission had 728 upvotes: https://news.ycombinator.com/item?id=23330881

react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446

vuejs.org only had about ~1 meaningful root domain submission: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.

Re: htmx

#12

Post by benatkin »

chatmasta wrote: post #6

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…

The community is convinced that their form of HTML attribute salad is hypermedia and others, that look better IMO, are not. That explains some of the excitement over it.

They have a tiny bit of a point, in that the forms are able to work without client-side JavaScript* thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that. Svelte does a better job of explaining it and making it customizable IMHO though. https://learn.svelte.dev/tutorial/progressive-enhancement

Though Svelte has this, I think perhaps most Svelte devs prefer JSON to form data, because it's directly nestable. That in general is good for full-stack development. You don't see very much TOML in the framework written by the author of TOML, but you do see a little. :) https://redwoodjs.com/ form-data is very TOML like in its data model.

* Except nowadays most of them depend on it to be usable.

Re: htmx

#13

Post by jgoodhcg »

chatmasta wrote: post #6

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…

I think there is something to HATEOAS. It gets around the state sync issue of a distributed system in a clever way. As someone who has mostly built React based SPAs it’s like the network is just part of the unidirectional flow of a reactive app. It doesn’t work for all cases but I think it might work for 80% of them. It also feels right to be so close to just html in the browser.

Re: htmx

#14

Post by pphysch »

chatmasta wrote: post #6

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…

htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML

Re: htmx

#15

Post by jhp123 »

My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.

Re: htmx

#16

Post by panic »

"Load HTML from a URL and replace part of the page with it" is a powerful technique for progressive enhancement, even if you don't want to use a framework like this. A button can send users without JavaScript to the URL directly, while users with JavaScript can have that part of the page replaced inline.

Re: htmx

#17

Post by hliyan »

cosmojg wrote: post #5

Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes

I actually found their haiku quite insightful:

    javascript fatigue:
    longing for a hypertext
    already in hand

Re: htmx

#18

Post by qbasic_forever »

chatmasta wrote: post #6

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…

I view it more as server-side first modern app development. If you have a Django app for example htmx is a fast and easy way to make it feel fluid and dynamic like a modern SPA, but still using all your server generated Django logic, templating, etc.

I seriously doubt many people decide they prefer coding up logic in attributes. It's just what HTML gives you as an extension point.

Re: htmx

#19

Post by cpitman »

laex wrote: post #3

Can HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?

I think that unpoly(https://unpoly.com/) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request).

Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.

Re: htmx

#20

Post by candiddevmike »

pphysch wrote: post #14
chatmasta wrote: post #6

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…

htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML

That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS.

As an aside, htmx uses JS under the covers to make HTML dynamic.

Post reply on HN