I still think that JS is very much not TS. Most TS code assumes you never need to check for errors because the type checker proves they can't happen.

Then, paradoxically, with no error checking at runtime, it becomes fully possible for JS code to call into TS code in a way that breaks the shit out of the TS compiler's assumptions. In philosophy then TS and JS are as incompatible as GPL and EULA

▲

sethaurus 2 days ago | parent | next [-]

It doesn't matter if a library is written in TS or JS; you cannot meaningfully protect against other code calling you incorrectly.

Sure, you can check if they gave you a string instead of a number. But if you receive an array of nested objects, are you going to traverse the whole graph and check every property? If the caller gives you a callback, do you check if it returns the correct value? If that callback itself returns a function, do you check that function's return type too? And will you check these things at every single function boundary?

This kind of paranoid runtime type-checking would completely dominate the code, and nobody does it. Many invariants which exist at compile-time cannot be meaningfully checked at runtime, even if you wanted to. All you can do is offer a type-safe interface, trust your callers to respect it, and check for a few common mistakes at the boundary. You cannot protect your code against other code calling it incorrectly, and in practice nobody does. This is equally true for JS and TS.

▲

md224 2 days ago | parent | prev | next [-]

Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though. Dealing with external input requires type assertions (since Typescript doesn't know what the program is getting at compile-time) and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.

However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.

▲

billyp-rva 2 days ago | parent | next [-]

> Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though.

If it's a service, yes, and that's true no matter what technology the service is using. If it's a library, no, because...

> and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.

That's on whoever is using the library, not the library author. If the library author provides type definitions, and you as the consumer choose to ignore them, then it's on you.

▲

conartist6 2 days ago | parent | prev [-]

TS certainly thinks of external input as a boundary requiring safety, but usually that would mean form input or CLI args parsing or something.

Usually there's little if any protection against a JS caller providing wrong-type args to TS functions.

▲

md224 2 days ago | parent | next [-]

Sure, but if the caller is Javascript then you're running Javascript, not Typescript*, so it makes sense that you're not going to get type safety.

I'm also not sure we're actually disagreeing on anything, so perhaps my reply was pointless. I agree that if you mix JS and TS in the way you describe, you'll have problems. My reply was just to say "yes, and that's not really Typescript's fault", but perhaps you weren't implying that to begin with.

* I'm aware that you can't run Typescript directly, but I hope my point here is clear... you're running a program that wasn't type-checked by TS.

	▲	conartist6 a day ago \| parent [-]
		I don't think we're disagreeing either. I didn't mean to suggest that it was Typescript's fault, just that the relationship between TS and JS in theory is something like "TS is a superset of JS" but once you get down to the practice of writing idiomatic reusable code it's more like TS and JS are fully different languages.

▲

umanwizard 2 days ago | parent | prev [-]

Something similar is true for most statically typed languages.

If you write a C library, nothing stops someone from writing an assembly-language program that calls functions in your library with the wrong types.

▲

epolanski 2 days ago | parent | prev [-]

The type checker can only prove what is known at compile time and only if you're disciplined.

To bridge runtime and compile time (as your application will likely get some external data) you've got to use a proper parser such as zod[1] or if you want to stretch it even further effect-schema[2].

[1] https://zod.dev/

[2] https://effect.website/docs/schema/introduction/

▲

girvo 2 days ago | parent [-]

I’m currently in love with Arktype, and as it supports Standard Schema it plugs into most places that can take Zod schemas too :)

https://arktype.io/

▲

epolanski 2 days ago | parent [-]

That's a validator, not a proper parser, no?

	▲	culi a day ago \| parent \| next [-]
		What's the difference here? I've only used Zod but I typically think of Zod as a runtime validation library. AFAIK arktype is a full-featured replacement for Zod
	▲	girvo 14 hours ago \| parent \| prev [-]
		I don't think I understand the difference you're drawing on here? It parses data and validates its structure, and is a replacement for all my uses of Zod?