configuring tsc to remove the framework-centric assumptions and getting editors to see that configuration can be a pain

JavaScript is remarkable for being the only language that has optional semicolons but does it so badly that people add them anyway

i scatter javascript semicolons about like a farmer, sowing his code

🎉 👑

This conversation about TS is more aimed at htmx2. Delaney (and I) are really trying to feel out an answer for "should htmx2 be in typescript?". Yes, we're evangelizing a bit, but we're also trying to get a fair answer, instead of the reactionary "OMG CAN WE STOP TALKING ABOUT BUILD SYSTEMS AND TYPESCRIPTS". Like, yeah, it's discussed a lot, but maybe that's for a reason. Since it's a running joke here, I assume it's because it's been brought up by more than just us two. If multiple people in the community agree with the idea, maybe there's merit in considering it and having a real conversation, instead of being reactionary. I'm honestly not strongly of either opinion. I'm of the opinion that it's worth taking a good look at it, and whether it'll help the maintenance of htmx. Because as Delaney said, that's the benefit. It changes NOTHING in the end-user dev experience. Everyone should still be able to do

<script src="htmx.js">

and

hx-*

and everything should work correctly. But there are benefits on the library maintenance side. There are bugs it would prevent. It's not a silver-bullet that solves everything, but it does solve some things.

That said, I suppose this convo could move over #1046573806547910677

Do you think that the issues you have found can be solved by introducing a more comprehensive test suite and if so, is a test suite good enough at documenting the assumptions that you are worried about (such as not returning anything, etc)? Also, when you mention that there would not be any more of a build step - are you saying that htmx could be written in typescript and I could simply drop in htmx.ts into my project without having to compile it via tsc? Having done a decent amount of python in the past, I have found type hints to be good at documenting assumptions, but they also force you to write code differently or use a type like any if you don’t want to lose some of the dynamic behavior that makes python a joy. By no means am I patently against typescript. Additionally my opinion doesn’t matter at all lol, I have just found htmx to be a breath of fresh air.

The idea is we would compile it for you and publish htmx.js as usual.

i'm saying you have htmx.js... you now can c/p for dist/htmx.js and its normal es6 code

if you want the ts in your browser you'd c/p the one with sourcemaps, but you don't have to the "normal" dist is just es6 js

Would the htmx.js file that is generated be readable or does it end up mangled?

I think we should just use JSDoc types. The main benefit of a TypeScript port would be rewriting the code with respect to static typing, the syntax difference between TS and JSDoc is not that important.

the es6 version is just regular JS with the static type checking out... the common.js is mangled, but so is any minify dist version of htmx

there is already JSDoc and they are unfortunately wrong from what I'm seeing. They are an assertion, just a static check

C++ terms you have a void* and are casting, not the same as a param being that type at compile time

htmx 2 will (it seems like) be a rewrite, and having typing from the beginning will make a difference from the current types which are tacked on

☝️

@limited-potato-46306 to me TS is a more comprehensive test suite. Its "just" a static analysis test suite. I'm now documenting every place the current version is making a bad assumption.

I'm assuming most of the issues you found are in htmx internals (not the public api or hx attributes behavior), which would be hard to test and easy to typecheck

@mysterious-car-3675 One last question, I believe I remember seeing a proposal that was (is?) being considered for adding type annotations directly to javascript - do you think waiting on such a thing could be worth it? When I google, I come across: https://2ality.com/2022/03/type-annotations-first-look.html

i don't wait on committees' to agree to stuff like that. like waiting for html to add more than post/get

It's still stage 1 (of 0..4), so I wouldn't wait for it. Besides, we'd need to introduce a build step to strip them for older browsers (at which point you might as well use tsc). It'll likely be a couple of years before this proposal is usable.

Is there a known bug using reveal with a delay?

hx-trigger="revealed delay:250ms"

I'm never seeing the triggered request happen. Looks like it's marking the div as

hx-revealed

already, and perhaps that short-circuits the thing from triggering after the delay is up

looks like the

revealed

synthetic event does not respect delay: https://github.com/bigskysoftware/htmx/blob/704739d1f0edcef48d9d7442aa57811d2736ec0b/src/htmx.js#L1425

would you expect it to still issue a request if the element was revealed and then was hidden again before the delay completed?

for our use-case, yes I would expect it to fire after the delay still

i.e. if

hx-trigger="revealed delay:250ms"

then the request should fire 250ms after the element is first revealed, regardless of what else happens to the element

the JSDoc idea is a good one. Keeps the types segregated visually without cluttering the functioning code, and seems like the actual standard is moving towards JSDoc types anyway. No build step required.

🙂