put

hx-boost='false'

on those elements

@User , So simple! Thanks a lot.

@mysterious-toddler-20573 in case you were wondering how I accomplished my goal:

<div hx-get="/upsy" hx-target="#uppp" hx-trigger="load delay:2s" _="on htmx:afterOnLoad wait 10ms then remove .opaque from #upsy then wait 5s then add .faded to #upsy then wait 910ms then remove #upsy"></div>

.opaque

is just

opacity: 0

and

faded

is just an opacity transition from 0 to 1 over 900ms. The "secret sauce" seems to be adding an opacity animation to the element inside the container, which in this case is an SVG.

So now my little hacked popup fades in and fades out. Thanks again for your help, hopefully someday I can pass it on to someone else.

htmx and hyperscript sitting in a tree, K.I.S.S….. errr making sweet webdev magic together

🙂 most importantly: are you having fun?

_hyperscript tip: You can use the

settle

command instead of hardcoded timeouts

Hi guys, I'm new here (but not new to the ideas behind htmx/intercooler/hyperscript).

I've been using very similar approach to htmx/intercooler for a very long time. I was kind of hoping that this thick-client SPA frameworks cargo culting will end, but apparently not.

I recently started writing about those issues and I'm trying to spread as much awareness as I can about htmx (and the underlying issues it's solving). I'll also try to familiarize myself with the codebase, so I can help with occasional pull requests.

Thats great to hear! 👊 I would suggest starting by giving the docs a complete read-through. It’s well-written and easy to read, doesn’t take long to go through and it really helped me understand the basics. The rest comes from looking at the examples, following along/asking questions in this channel and then absolutely looking at the source code if you’re so inclined 👍 I also had fun dabbling with the plugins (I extended the PathDeps plugin a tiny bit), so if you have a killer idea for extending the framework, that might also be a good area to focus on. Most important thing though (to quote @mysterious-toddler-20573): Are you having fun? 😁

Can you perhaps give an example of what that would like like @gorgeous-airport-54386 ?

Sorry, I probably didn't express myself well. I'm new here (on discord), but I've used both intercooler.js and htmx before (and I've had a very similar, custom lib long before I saw intercooler.js on HN). I'll take a quick look at docs if something important has changed in the midtime. btw. thank you all for working on this great lib (and making the web a better place), especially to the author for creating it.

Ah, gotcha 😁👍

(I blame it on not reading properly while standing in a long airport queue🤦🏻‍♂️)

No, it's my fault, should've worded it a bit differently. btw. this is the first time ever I'm using discord 🙂

welcome! I wasn't much of a discord user either a year ago, but I use it quite a bit now.

Hopefully the codebase isn't too hard to follow. I write javascript in an idiosyncratic manner, basically functional with some objects wrapping everything up. We may port to typescript at some point, but not any time soon (sorry @User )

as for where to start, maybe you could help @User on his work pulling SSE and WS out of the core? At least follow along to see the process?

as an aside, I have posted a reworking of the Wikipedia entry on hateoas to, well, actually use a hypermedia: https://htmx.org/essays/hateoas/

@User if you have styling suggestions, I gave it a pretty boomer-tier look 😑

and anyone who has content suggestions, please let me know

A full migration to 100% typescript would be difficult and disruptive. In the past, @mysterious-toddler-20573 has given his blessing to JsDoc comments and *.ts.d files. So if you love typescript, you can still help bring htmx closer by contributing these.

Great article! I wanted to submit a pull request from the dev branch for typo fix, but it seems this essay made it straight into master, as I can’t see it in dev?

you can make a doc fix PR directly against master

I'll soon start to work on the project where I'll need just a bit of functionality from htmx. Including the whole htmx would be an overkill and I'll probably need much more customizability than the current architecture allows. I was thinking about splitting that core functionality into a tiny, more customizable lib (i.e. htmx-lite). In the long run, it may be also useful to someone else as I'll try to stay as close as possible to htmx concepts and terminology. That may give me a good opportunity to explore the codebase and give me a better idea if I can help and how.

Hyperscript has already headed down this path. And, we’re starting to pull some less frequently used pieces out into extensions.

But, there are many dependencies between htmx tags, which makes this modular idea hard to implement in practice.

Fortunately, the whole kitchen sink is only 10k, so you’re not really wasting a lot of bandwidth.