Live data from Hacker News

htmx

htmx.org

41–50 of 291 posts

Re: htmx

#41
post #3

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

Why does documentation need any JavaScript at all beyond opening the hamburger menu?

Re: htmx

#42
post #15

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.

Could you elaborate? Genuinely curious.

Re: htmx

#44

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…

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? These are literally the antithesis of HTML.

Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.

Re: htmx

#45
post #34

Earlier quoted context omitted.

> You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just f…

I doubt it – I haven't seen any indication of HTMX being a silver bullet. Here's your list of examples: https://htmx.org/examples/ Here's validation: https://htmx.org/docs/#validation-example It looks kinda like ruby.

I'd argue that neither is any particular JS framework a silver bullet. If HTMX works for their use cases without needing to write any JS then more power to them!

Re: htmx

#46

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 removes abstractions from your web project, by extending the existing abstraction of hypermedia to the point that it can implement many common UI patterns without any other concepts:

https://htmx.org/examples

i have a free book available on the hypermedia approach and how it contrasts with the SPA/thick client approach (both its strengths and weaknesses) here:

https://hypermedia.systems

Re: htmx

#47

Earlier quoted context omitted.

I think you could expand your definition of small projects somewhat. I used to work at a marketing agency many years ago, there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email. Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reserv…

> there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email. You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html. > Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking re…

This response is an excellent example of how, when stating a case or making an argument on HN, you should provide as little concrete information as possible and avoid a specific example if possible.

The point they were making was that for many small single-purpose sites the interactivity needs are low but for various technical or social reasons may be higher than exposed with pure html/css, and htmx meets those needs adequately without adding much additional complexity.

But they used forms as an example, and now you're deep in the nitpicky weeds about the semantics and capabilities of html forms, having missed the point and left it in a ditch miles ago.

Re: htmx

#48

Earlier quoted context omitted.

For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader https://mastodon.social/@UP8/110432673973724419 This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I wan…

You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules. In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too…

That's how I use D3.js. But for the React programs I work on at work we are already committed to a build process, there are bits of Typescript, SCSS, and for production at least tree-shaking and minimization seem a most for something with that many moving parts.

Re: htmx

#49

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…

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

Post reply on HN