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

221–230 of 291 posts

Re: htmx

#221

Post by TekMol »

renerick wrote: post #220
TekMol wrote: post #210

Earlier quoted context omitted.

What would be a simple example of an event that you want to define inline but can't in plain html? Can you give minimal example on jsfiddle so we can compare different approaches?

Here you go: https://plnkr.co/edit/DQJrBWWQFgHtpltf?open=index.html&previ... Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1] Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interd…

Hmm... that does no look like a minimal example to me.

Is this the relevant line?
If so, can you make an example with just that?

Re: htmx

#222

Post by renerick »

TekMol wrote: post #221
renerick wrote: post #220

Earlier quoted context omitted.

Here you go: https://plnkr.co/edit/DQJrBWWQFgHtpltf?open=index.html&previ... Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1] Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interd…

Hmm... that does no look like a minimal example to me. Is this the relevant line? If so, can you make an example with just that?

These are multiple minimal examples, they are completely self contained, independent of each other and separated by h1 tags.

I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4

Also, you may notice there is tag. It's just for the demo [1], it serves as a mock endpoint

[1]: https://htmx.org/docs/#creating-demos

Re: htmx

#223

Post by Nextgrid »

411111111111111 wrote: post #202
cosmojg wrote: post #5

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

A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme... While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variabl…

There's a class of applications where JS-heavy SPAs make perfect sense. HTMX should not be viewed as a general anti-JS movement. It is indeed unmaintainable to deliver the same functionality in HTML as a JS SPA would allow.

The catch is that very few JS SPAs actually deliver that functionality either - the functionality I'm talking about is desktop-app-grade functionality (think a trading terminal for example) that very few JS SPAs actually deliver. Most JS SPAs are just shitty reimplementations of basic browser functionality, and that is reasonably trivial to convert to server-side rendered HTML with HTML or ad-hoc (inline?) JS sprinkled in where necessary.

Keep in mind that server-side-routing doesn't prevent the use of React or similar frameworks either. If you have an application where 90% of the pages would be fine as server-side-rendered HTML but 10% require heavy interactivity, you can have your server return a page that embeds React or your JS framework of choice. (the reverse is also possible - if you have a JS-heavy website but have a few "boring" pages like for example an account details form, you can have your backend serve that as an HTML form and just have your JS iframe it)

Re: htmx

#224

Post by L0stLink »

adamredwoods wrote: post #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.

how do you feel about JSX?

Re: htmx

#225

Post by chatmasta »

alex_lav wrote: post #190
markmark wrote: post #183

Earlier quoted context omitted.

Classes still work fine if you want to keep using them.

This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.

Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.

Re: htmx

#226

Post by chatmasta »

yawaramin wrote: post #108
chatmasta wrote: post #90

Earlier quoted context omitted.

Every site I build works with JavaScript disabled. I use Next.js with server side rendering so that the initial page load is an accessible HTML document that is progressively enhanced for those with JS enabled during hydration by adding interactivity and smooth client side page transitions without full page reloads. None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX i…

> None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaS…

How do you do that if your backend is setup to respond to requests with partial content? You now need to make sure your backend can render both the full page and also individual components of it. That's not functionality that's provided by HTMX itself.

Re: htmx

#227

Post by chatmasta »

L0stLink wrote: post #224
adamredwoods wrote: post #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.

how do you feel about JSX?

JSX is a templating language, not hypertext.

Re: htmx

#228

Post by recursivedoubts »

listenallyall wrote: post #218
yscodes wrote: post #180

Earlier quoted context omitted.

I like your change. Much clearer. Makes me more interested than the current syntax.

Your opinion is totally valid. However, is it really difficult or tricky to recognize that 'click' the default event of a 'button' tag? Isn't 'onclick=' kind of redundant?

we don't specify "click" on anchors or "submit" on forms, do we?

Re: htmx

#229

Post by adamckay »

cpitman wrote: post #19
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). Unpo…

You're correct that it's the general expectation, but it is possible to select certain elements from the response using `hx-select` [1], so it is possible, just not particularly efficient...

[1] https://htmx.org/attributes/hx-select/

Re: htmx

#230

Post by fallat »

jhp123 wrote: post #74
fallat wrote: post #42

Earlier quoted context omitted.

Could you elaborate? Genuinely curious.

let's say that you have an upvote button Upvote Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.

Isn't this comparable to any other situation where you reference something outside a project, even in C with libraries?

(I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.)

If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply grep '#notification-bar' and see where it lives in the project...

I think the goto comparison is somewhat related, because it's about reasoning about control flow (or rather, how it makes it unreasonable) - but isn't this example pretty easy to reason about when you consider you're one search away from finding the notification-bar in the project? You're still creating a tree of components and interactions, and in order for that to happen, you must be able to reference them with confidence in some way.

I still prefer the React way (tree structured components) regardless, but HTMX does seem interesting from a DevX point of view. I think it'll be forgotten about in about 5 years.

Post reply on HN