back

by levkk·2y ago·view on hn ↗
We've been using Turbo for over a year now (similar idea to Htmx). Pretty happy not to be using React anymore. Most of the complexity is offloaded to the backend where we can handle it better with a typed language system and no middle layer (e.g. GraphQL) between our app and the database.

TypeScript is not typed fwiw, e.g. `as any`.

4 comments
> TypeScript is not typed fwiw, e.g. `as any`.

So because it has a feature to disable typing it is not typed? Would you say the same thing for any language that has similar "unsafe" flags, like rust or basically all the others?

           | Static | Dynamic
    -------+--------+---------
    Strong | Rust   | (lisp?)
    Weak   | TS     | JS
TypeScript bolts on a Static type checker onto JS, and the types are erased before running in a real JS runtime. At runtime the types can change out from underneath you for many local and nonlocal reasons. This is simply impossible in Rust in general.
You'd have to try very hard to override a type in Rust when that type comes directly from your database (see SQLx).

Rust unsafe features don't allow you to override type safety, but you can directly manipulate raw pointers if you're so inclined.

TypeScript really does let you bypass the type checking entirely and drop down to just JavaScript.

Yes, typescript allows you to do that. It is entirely voluntary and you can do untypesafe things in almost any typed language.

I'm not sure how that makes typescript "not typed".

I think the parent is simply pointing out that “Typescript’s types are not sound.” That is, the types at runtime may not be what you assumed at compile-time. This happens very often at API boundaries because fetch returns `any`.

Many languages do have sound type systems, and I would argue we should prefer those.

That is certainly one interpretation, but even then within most compile-time but not runtime-checked languages you can usually perform runtime checks. For example I've used Zod (https://zod.dev/) quite a bit in typescript to do runtime typechecks at the boundaries.
I don't know much about Rust, but it has the same problem, doesn't it? As I understand it this is something the serde crate (at least) is often used to solve.

This is reasonable, given that untyped data received at a system boundary is going to need some kind of type checking no matter what the language or type system; I'm not sure that can even be fairly called a 'problem'. But it also would leave the putative line of argument rather footless, in that blaming Typescript for something Rust also requires is incoherent.

Perhaps the originator of the claim under discussion will clarify his meaning.

I think we agree, or maybe you misunderstood what I meant?
The fetch issue (and JSON.parse/localStorage.getItem/etc) can mostly be mitigated by using type guards to “parse” data at the point of ingress.
Sure, that's true. Under the same rule, C also isn't typed because void pointer casts are possible.
What about the empty interface type in Go?[0] Is that just as problematic for you?

[0] https://go.dev/tour/methods/14

Correction: the empty interface is actually analogous to TypeScript's unknown type rather than the any type.