Live data from Hacker News

htmx

htmx.org

91–100 of 291 posts

Re: htmx

#91
post #25

Earlier quoted context omitted.

> HTML is by design not supposed to be dynamic, that's the point of JS. You are putting far too much faith in the design of web standards. Anyways, here's a counterexample to your claim: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

and are older examples. And of course , , annnnnd cough . There was and for some reason still if you wanna consider animations dynamic.

Thanks, yeah, there are lots of examples of standard HTML features that wouldn't make any sense in a true static document DSL like LaTeX, or a paper document.

HTML is interactive and dynamic.

Re: htmx

#92
post #11
post #4

Earlier quoted context omitted.

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 v…

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

Pretty glib take.

The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two applications you own can talk to each other.

Re: htmx

#93
post #91

Earlier quoted context omitted.

and are older examples. And of course , , annnnnd cough . There was and for some reason still if you wanna consider animations dynamic.

Thanks, yeah, there are lots of examples of standard HTML features that wouldn't make any sense in a true static document DSL like LaTeX, or a paper document. HTML is interactive and dynamic.

I was just augmenting your answer as I liked it! It was also sort of a response to my sibling responder as they didn't seem to get what you were saying.

EDIT: Oh wait, maybe they did now that I re-read it... maybe? I think it's time for bed.

Re: htmx

#94
post #70

Does this cause problems for web crawlers indexing sites, since these are not typical js event listeners etc? Even though they must use them in the background, there is an abstraction the crawler must be able to navigate. I had an entire site de-indexed for getting too fancy once, so I worry about this type of thing perpetually now.

It won't matter as long as you are using regular `a` tags for links. You anyway don't want robots to submit forms and perform any actions that are meant for users.

Re: htmx

#95

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…

It makes sense to me that good web developers would be multifunctual enough to implement a solution based on the complexity of the required design. React is conversely way too complicated for a lot of the stuff that's easy to do in HTMX, so you should be able to do both in my opinion.

Re: htmx

#96

Earlier quoted context omitted.

I would likely agree, however this example makes heavy use of hyperscript, which is an associated project by the same author, but is distinct from HTMX.

How do you do validation with custom error messages without it? It seems pretty table stakes for forms to me. Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/

Mostly, you validate on the server and send html with error messages back.

If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.

Re: htmx

#97
I'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.

Re: htmx

#98
post #52

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 might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it. I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstract…

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it.

And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).

I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)

Re: htmx

#99
post #52

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 might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it. I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstract…

htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.

Re: htmx

#100

I personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can. Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.

I'm old fashioned and go out of my way to use as little JS as possible

The point of HTMX is to avoid writing custom JavaScript.

Post reply on HN