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

51–60 of 291 posts

Re: htmx

#51

Post by quickthrower2 »

benatkin wrote: post #49
listenallyall wrote: post #44

Earlier quoted context omitted.

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX! However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic?…

Here's some code that I don't find especially idiomatic: It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example

Programming languages contain English words like if, self, else, then, function, def, this, exception…

Me/my is rarer: Reminds me of VB

Re: htmx

#52

Post by genmud »

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 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 abstractions that seem to be mercurial and constantly changing.

If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…

How many different tools might you run across?

How easy would it be to take that 6 year old code and bring it up to modern standards?

The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.

Re: htmx

#53

Post by austin-cheney »

0xEFF wrote: post #21
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…

Is it really easier? Yes. The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters. There’s no way I could learn the JavaScript ecosystem in a day. Mayb…

Software developers, especially DOM fearing front developers love using the word easy. It isn’t so much an infatuation but more like a fatal attraction obsession where obstruction means war on a very emotional level. Ironically, people are loathe to confront these feelings openly and thus cannot define the word easy with any kind of clear practical application.

So, I did the world a favor and wrote just such a definition: https://github.com/prettydiff/wisdom/blob/master/Easiness.md...

Re: htmx

#54

Post by recursivedoubts »

candiddevmike wrote: post #20
pphysch wrote: post #14

Earlier quoted context omitted.

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.

HTML is designed to be dynamic via hypermedia controls, that is, elements embedded in documents that communicate some sort of hypermedia interaction to a user agent. The two common hypermedia controls are anchors and forms.

htmx simply generalizes this concept, allowing any element to be a hypermedia control, issuing any sort of HTTP request, in response to any sort of event and replacing any element in the DOM.

I have written an essay on an alternative software design principle to the traditional separation of concerns that we see in web development here:

https://htmx.org/essays/locality-of-behaviour/

Re: htmx

#55

Post by listenallyall »

benatkin wrote: post #49
listenallyall wrote: post #44

Earlier quoted context omitted.

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX! However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic?…

Here's some code that I don't find especially idiomatic: It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example

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.

Re: htmx

#56

Post by recursivedoubts »

benatkin wrote: post #49
listenallyall wrote: post #44

Earlier quoted context omitted.

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX! However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic?…

Here's some code that I don't find especially idiomatic: It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example

the code here is hyperscript, not htmx:

https://hyperscript.org

i use hyperscript because I created it and like it, but the example could just as easily use JavaScript, the point is to show that htmx respects custom validations

Re: htmx

#57

Post by dmix »

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…

Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead.

There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requirements evolve. Although I've seen some highly capable apps built on top of jquery plugins like Select2, which were extended well beyond their initial intent. Things that work is all that matters at the end of the day when it comes to making $$$.

Re: htmx

#58

Post by benatkin »

listenallyall wrote: post #55
benatkin wrote: post #49

Earlier quoted context omitted.

Here's some code that I don't find especially idiomatic: It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example

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/

Re: htmx

#59

Post by recursivedoubts »

quickthrower2 wrote: post #51
benatkin wrote: post #49

Earlier quoted context omitted.

Here's some code that I don't find especially idiomatic: It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example

Programming languages contain English words like if, self, else, then, function, def, this, exception… Me/my is rarer: Reminds me of VB

it's a separate project, hyperscript:

https://hyperscript.org

it's based on HyperTalk, the scripting language of HyperCard:

https://hypercard.org/

with some Web-specific syntax thrown in to make things cleaner:

  add .visible to

Re: htmx

#60

Post by dimatura »

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've used htmx to write some relatively simple internal tools, and it's been really useful for that. I know a little javascript, but my web skills are really outdated - I acquired them back when you rendered HTML on the server and maybe added a little interactivity with jquery. With that background, using htmx to swap out elements (rendered server-side with Jinja templates in flask) has been a lot more productive for me than trying to overcome my unfamiliarity with modern JS. The modular structure of Jinja templates actually works really well the htmx paradigm IMO.
Post reply on HN