This doesn't remove the object from the DOM after the animation is over, which the example on the website does. You'll need to add something that removes the element after the transition is over which would be a bunch more code (the eventlistener for transitionend) :)

Thanks for the heads up before the Hacker News edit window closed. +1 LOC

FYI you can set a "delay" in your profile of up to 10 minutes before your comments are shown, giving you more time to edit. May not have helped in this case but it's a cool feature.

thats's a nice tip. Thanks

one can learn a lot from reading the FAQ: https://news.ycombinator.com/newsfaq.html :)

:D that's fitting for HN.

Instead of finding a more descriptive name or adding a short description below, they put it on a completely different site.

Thank you, I'll update the example. I usually stay in es5 for IE11 compatibility (htmx is still supporting IE11) so I tend to write js in a more archaic style.

That 1% market share of IE gets smaller every day, as we wait with bated breath.

:) I know, I am looking forward to using IntersectionObserver in htmx.

But I'm a bit of a contrarian and every time someone tells me to drop IE support I think "Maybe I won't."

Also a heads up, the vanilla fade out demo doesn't work correctly (immediately disappears) as in the actual code it looks to be missing the transition line.

Thanks for reporting, fixed.

I generally agree that practically, focusing on the heavy weight technologies will be the most useful in the long run. In defense of DSLs, I do love them. It's the magic of doing a task specifically as the most intuitive magical incantation. A beginner can pick the DSL up easily and get excited about learning the underlying fundamentals. An expert can code complex scenarios more efficiently.

Still, there's a pretty steep curve to developing them, and that generally translates into a shorter lifetime unless they take off in popularity. For example, tooling support, for things like autocomplete, highlighting, debugging will need to be implemented. There's also a lack of community answering questions, making it difficult to pick up for beginners (no stack overflow, etc).

Won't the arrow function not bind `this` to the DOM element, causing it to refer to the window object? I think you have to use a real `function`, `function(){this.remove()}`

Arrow functions have the same `this` as the scope where they are declared (in this case, an onclick attribute). Both would work in this case.

Yes, I'm sorry but that JavaScript example code is terrible.

I realize this sounds harsh but truthfully, it made me immediately disregard the library. If this is how you would solve these issues in JavaScript I'm not taking you seriously.

The web API offers an elegant separation of content, style and logic and these examples are just stuffing everything into logic. Don't do this

For a trivial example like fading out, you're right, but if you want to make dynamically generated animations, hyperscript's features are very helpful (The Web Animations API is a boon, but browser support isn't there yet).

Separation of HTML/CSS/JS doesn't always mean separation of concerns. Every application has a different definition of a "concern", and if it doesn't align with the separation between languages, you don't get decoupled code, you intensify the symptoms of tight coupling.

Do you remember who said the quote? That's fantastic.

I'm not sure to be honest, but the above quote is the result of me distilling the seed he planted in my mind into as concise a statement as possible. Unless I am mistaken, his original (I think it was a StackOverflow post related to JQuery) was much longer.