OP and those who feel a similar sentiment should give C# a shot, it's what they want regardless of whether they know it or not.
TypeScript please give us reflection/runtime types
51–60 of 287 posts
Re: TypeScript please give us reflection/runtime types
#52There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…
But in all seriousness you can gain reflection without a runtime. Just expose the types as data.
Seems foolish to not do something like this. Particularly when you look at the lengths so many devs have gone to try and replicate it.
Re: TypeScript please give us reflection/runtime types
#53There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…
Consider
const fooType = generateTypeInfo!();
Where `generateTypeInfo!` is a macro that expands to a JS object encoding the “Foo” type (e.g. if `Foo` a record type, `fooType` will be a record with its encoded field types). It still compiles to readable JavaScript.What this macro does break is that TS = JavaScript with type annotations, and all you need to do to compile is remove those annotations (excluding enums, but they are all-but-deprecated and obsoleted by string unions) without even type-checking. Since now you also need to expand the `generateTypeInfo!`, which requires actually computing the structural type of `Foo` (and if you want any sort of nominal type metadata, that too).
And that’s still a problem because type-checking is slow, but removing the annotations is fast. If there’s a limited way to resolve types for these annotations which restricts the resolution scope, that would be a good candidate.
—-
There's also more issues with TypeScript having a separate runtime besides it not being JavaScript. TypeScript types are structural, so they currently are available at runtime: to determine an object’s type, inspect its structure. Anything more and you quickly run into non-trivial cases being literally impossible: if you want erased nominal information like whether a string is part of a string union, TypeScript’s type system is Turing complete; and if you want the nominal type name, implicit structural conversions mean that once a value leaves its annotated cast or definition it’s effectively undefined.
Re: TypeScript please give us reflection/runtime types
#54I was perfectly satisfied with using https://zod.dev for some runtime data validation, and found it really cool that I didn't have to define some nominal type off to the side and could instead just say what I meant inline using a fluent API.
Simple one, distinguishing `2` number with `2` currency in your domain.
Re: TypeScript please give us reflection/runtime types
#55There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…
Typescript isn't a runtime on top of JavaScript, but it very much is "a new language that compiles to JavaScript".
Re: TypeScript please give us reflection/runtime types
#56Earlier quoted context omitted.
And that's one of the features of typescript that really sucks. String union types work so much better.
Why does typescript enum really suck?
Re: TypeScript please give us reflection/runtime types
#57Re: TypeScript please give us reflection/runtime types
#58Modern TS code is hard for me to read and reason, and I use Rust, Haskell, C++. Way too complex for my brain
TypeScript's type system is indeed way more verbose than Haskell's.
Re: TypeScript please give us reflection/runtime types
#59... TypeScript may be one exception to my rule of thumb. It's already compiling down to JavaScript, so you're already paying a performance tax in having your code run in an interpreted language. The question should be "how much more of a performance tax are you paying annotating things with type runtime metadata?"
Re: TypeScript please give us reflection/runtime types
#60There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…
> Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Typescript isn't a runtime on top of JavaScript, but it very much is "a new language that compiles to JavaScript".