From Peru, i can´t recommend them.

I learnt to program from ExpertSexChange.com

Just make sure you never buy hormones from StackOverflow

I wonder how many people got into programming by accident while browsing sex change options in 1999

Resisting new shiny things requires discipline, and wisdom that if you want to ship something worthwhile, you have to pick and stick to this for a while. But I look at what's available, just to be aware of the options.

I’m aghast at the thought of a build step

Wow revolutionary

Truly crazy

Huh? hx-history? What's that

Just making sure I grok this comment and the positive reactions. With what @echoing-dress-67727 and I were talking about there is no build step to use htmx... Any more than there is today. You still get single file drop in. It's more about dev and finding errors. Tried are initial port to TS . Stopped counting after about 30 places where their is null function access, not all conditions return, invalid type casting etc. As a user get you'd actually better guarantees and same drop in. I honestly don't get it other than the memes. Htmx is still a js framework and there is tooling to make that suck less to maintain.

Does TS actually enforce the types? In my experience - no. A few years back, I was in that world (and still am at my day job, if a ticket comes in on it), and while the types are great, and the *piler will tell you if you're calling other TS stuff wrong - it actually doesn't prevent things from still blowing up if a

null

gets introduced via data that isn't expected. This was a surprise, given a) the "look how safe it makes your code!" claims given by its fans; and b) contrasted with Kotlin, which does enforce its nullability checks even when interoperating with Java code. IOW - just because something looks null now doesn't mean you wouldn't encounter it IRL, even if the code thinks it can't be.

if you coerce your types as in

as X

without X being valid it is an escape hatch. It enforce at compile time, not runtime. If you have a runtime invariant, no its not magic. But I'm talking about compile time issues in htmx. You'd have to write 100% code coverage to get the same tests I'm talking about

if you can get nulls in your data, you need your types to match

There's strict mode which honestly should be the default that forces you to write your code as if it were a fully-typed language. E.g.:

document.GetElementById

returns

Element | null

, and if you want to do anything (that would cause a runtime error if it were null like calling a method) on it you have to check if it's not null, otherwise it complains.

that's what I've been doing @orange-umbrella-16693 , unfortunately what I've found is htmx make a lot of assumptions around dom queries that don't match the actual results per the spec

And yeah as @mysterious-car-3675 it's not a magic bullet. If a library's typings are incorrect or you throw in unexpected data it will fail, it's just compile time/dev convenience to save you time from a LOT of errors

but its not too bad because you have things like

?.

that handle it without being obtuse

trust me i want less js shenanigans, but i also want to make extensions that help others.

But the "catch your errors at compile time" pitch is misleading, and I was bitten by it. Staked a bit of my professional reputation on it, and had a nice dish of crow over it. It's helpful, but it isn't as helpful as I was led to believe, IMO. (I'm not bitter, just skeptical.)

There are a lot of places where I took advantage of dynamic typing: using union types (e.g. a string CSS selector or an element itself) and where I used the javascript convention of not returning anything if I want to return null

Isn't

?.

in ES now?

i don't know who is pitching you... catch your build time errors at build time. runtime is still something you need tests for

both of those are expressible in typescript 🤷‍♂️

ts know that, that's not what I'm talking about though

for sure, you just have to know what I was doing to get it right, and it's not obvious

and yeah, typescript doesn't add anything that happens at runtime (unless you're compiling to an older ES version, in which case it emits some polyfills)

we're well aware dude, literal repeat of yesterday. If the technical debt and dependencies were worth it, it would already be in- takes barely any time to add the types and whitespace. Go mess up another project on npm. Many of us do not want to deal with a build step to modify htmx.