I get it, to be clear I think #1250 is not really extreme, using rollup is a good choice. If you went vite+ts its just an extension of the work that he just did. It looks like I'm in the minority here but with his PR you at least get the output/sourcemaps that I'd like to see. Not a full build/debug workflow but if that's consider out there my ideas are a bridge too far

What's the point of bundling and TS in a ~4k LoC (correct me if wrong) project? To add needless complexity? I see mostly cons here and very little pros...(if any)

size isn't really the point at all Solid.js is tiny but moving to TS has been a net win cause it helps all devs have more context and fast path to understanding the system and intent. every js codebase i've ported to TS has found runtime issues that weren't being handled. i've been on pager duty enough to care about things that may just not matter to most in this context. 4k is plenty to footgun yourself, let alone have someone's PR

I like the idea of typescript, but I don't like sourcemaps

is there any movement towards native type script support in browsers?

but you uglify your CDN stuff already

yeah, but the source source is plain, debuggable js

My swap oob takes 2s and then settle another 1s. Omg. In response I use

hx-swap-oob="morph:#..."

. With regular outerHTML it's 2x slower. It's when I uncheck a checkbox in the header and the rows have to uncheck themselves.

I attached the profile here https://gist.github.com/alexbezhan/df79f476ac8fcf420325fe409fd6daf0

I think that JS is better. More people can read the code. More people can contribute. A ts definition file is kinda ok. But typescript adds extra steps. I am not against TS per se but I don't really see the pros to push it on this project, except that "some people like TS and say that it leads to less bugs" (which I happen to not agree with because I am yet to see a proper study that proves that)

with sourcemaps i don't get it. that's like a browser level thing nowadays. i feel like i'm yelling at the clouds at this point. i don't know about studies, but i can say from my experience being responsible for stuff it matters in production systems. the value in htmx to me is fixing the problems in html, but its still a js framework and having tooling is not a bad thing. I want to pay for what I use and as you go to a more plugin/extension based workflow in 2.0 you'll see the benefits. If you do the same thing in the same way, yes its dumb with more steps. I'll shut up and go back to making stuff.

Thanks for sharing your thoughts!

@mysterious-toddler-20573 I see htmx calls

getRawAttribute()

41k times. Here is the distribution:

@mysterious-toddler-20573 what would be a way to optimize that? attribute lookup takes significant time in the entire swap. The swap takes 2s

First thing I see is that I could get rid of data-*. Tell htmx - I don't use them, don't check for them.

🙂 don't get frustrated with me, my brain moves very very slowly

if this is a really large table, this is probably a problem w/ too many events being triggered on the removal of the initial elements (that's the perf issue I've seen before)

so a couple of options: does the server side need to know about this checkbox being unchecked? If no, can we do a bit of client-side scripting

If yes, are you willing to comment out a line of code in the htmx source and test

Yes server needs to know. It keeps this state in RAM. Depending on that it renders header differently and shows how many rows are selected.

trust, me you are one of my fav people right now. you've solved so much of want out of dev and I'm thankful for it. My guess is you've never seen a project where it makes a difference or worse it got in the way. I don't think htmx is like that. You've hit a critical mass where I believe there is a lot to gain. But no amount of, trust me bro, is gonna help if you aren't ready to accept it. Then again you don't have to change anything but I fear the extension ecosystem is going to suffer long term as the current way is geared toward a single js monolith

@mysterious-toddler-20573 I commented out data-hx attributes lookup. And it turns out I was wrong. They are not taking much time.

comment out that line and see what happens

(are you using the SSE or WS extension?)

mmm, yes. I think htmx 2 is the time to fix all this. And @gorgeous-ghost-95789 promised he would set up a proper extension website so we can get all the extensions out of core, thank u sir, very cool

sse. Commented out that line. swap is 10% slower - 2.2s, Settle takes roughly the same time - 800ms. https://gist.github.com/alexbezhan/ca4a8196c498752bb074866409afe2e6

@mysterious-toddler-20573 I see getExtensions() is being called for every element in swap. I'm thinking to optimize that would be good. If we already got extension for this parent, we can get it from cache. And reset the cache on every request. What do you think?

@mysterious-toddler-20573 I just changed getExtensions() so it goes only 1 level deep, and in combination with commenting out

beforeCleanupElement

line, it is now 4x faster. From 2s to 500ms.

I'm thinking that the right thing to do in

getExtensions()

is to keep looking for extension that we interested in. Let's say we have swapStyle 'morph', then keep looking for an extension that supports that swapStyle. We only need one extension for swap. Otherwise if multiple extensions perform the swap on the same element - it's gonna be a mess, because in what order they work? Nobody knows. But it is not backward compatible change. So I'm looking for other ways to speed this up.