Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

Post reply on HN
Print view View original

101–110 of 287 posts

Re: TypeScript please give us reflection/runtime types

#101

Post by benatkin »

orthecreedence wrote: post #83
benatkin wrote: post #66

Please give me an integer type. Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that.

> Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that. This is the direction I'm going. I use rust a LOT these days, and after trying out typescript for a few projects over the course of a few months, I absolutely hate it when comparing it to rust or even any other compiled language. Something about it just rubs me the wrong way...maybe the fact that it has to be J…

I'm curious what you think about Dart/Flutter if you've gotten a chance to dig into them. I am very impressed, but it trades simplicity for being cross platform. It has a nice set of types though. https://dart.dev/language/built-in-types

It also has a WASM compilation target that is under early development. https://docs.flutter.dev/platform-integration/web/wasm

Re: TypeScript please give us reflection/runtime types

#102

Post by vanviegen »

codeflo wrote: post #60
paxys wrote: post #55

Earlier quoted context omitted.

> 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".

Yes, but it's special in that it compiles by erasure. (Mostly -- the cases where it doesn't are considered historical mistakes.)

Ok. And why is that important? So one could meticulously add typing to your JavaScript application, and then strip it all out with a regex in order to deploy? What real-life benefit does 'compile by erasure' offer?

Re: TypeScript please give us reflection/runtime types

#103

Post by adjav »

andix wrote: post #5

There 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…

My understanding has long been that web developers have decided to turn Javascript into C#, one proposal at a time.

Re: TypeScript please give us reflection/runtime types

#104

Post by wvenable »

lolinder wrote: post #97
wvenable wrote: post #68

Earlier quoted context omitted.

Emitting type information to some kind of separate common format wouldn't undermine most of these goals. There are already apparently dozens of tools that people can use for this task in a dozen different ways. Just have TS emit the data. In this way there is no runtime overhead (point #3) -- it's pure data to be optionally consumed. They wouldn't have to prescribe any particular reflection module (point #6). The onl…

It would violate #9 no matter what implementation you use, and #9 is absolutely essential to tools like ESBuild, Deno, and Bun, which all rely on the assumption that they can nearly instantly strip out the type annotations and execute the code as JS.

You'd still be able to execute the code as JS. Your library that uses type reflection wouldn't work anymore but that's true of all these solutions.

Re: TypeScript please give us reflection/runtime types

#105

Post by TheRealPomax »

tylerhou wrote: post #76
paxys wrote: post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime. This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this wou…

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used.

The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your code to JS, because your function calls and data copies and everything else that moves data around was defined in terms of compatible shapes.

And we already have runtime validation libraries to cover that validation step. So many of them.

Re: TypeScript please give us reflection/runtime types

#106

Post by jauntywundrkind »

paxys wrote: post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

Counter to this post, as soon as I read the title I knew what this was, & I knew it was speaking exactly to something we've wanted for a long time. This is asking for more official & better supported https://github.com/rbuckton/reflect-metadata .

TypeScript is a compiler. It has a lot of type information during compilation. We could write that type information out into a file. Instead what we do is throw that information out when the compile ends. Taking all that typing information & throwing it away at the end of compile time is a bad dumb & silly limitation. Especially for a language like JavaScript, which historically could be semi-proud it had such a strong Everything Is An Object philosophy running through it (such as the malleable prototype-based inheritance system); so much type information should be on that Class object. Reflect-metadata for example defined new methods on Reflect to store this metadata.

I could not be more delighted to see the pennon of this website go up. We needed a rallying point for this. We needed a rallying point for keeping class data around. A rallying point for enriching the runtime with good actionable data is a good rallying point.

It's not what's afoot here, but I think you're a bit off-base about the impossibility of adding even some type-safety. We might not be able to get exact TS type safety. But we can definitely build some safety in. Owing to the malleable prototype-based type system in JS, we can add getters/setters to objects to do a lot of type checking. This doesn't even begin to explore the possibility of what we might do with es2015's proxies, which could allow even more interesting checks to be layered in. I also wish JS had an official AST (and renderer), so had more official options for code-rewriting that might let us weave in type checks.

What we can do as programmers is limited by what we have at our disposal. Not throwing out all the typing information, keeping it around at runtime, opens a lot of interesting doors.

Re: TypeScript please give us reflection/runtime types

#107

Post by lolinder »

wvenable wrote: post #104
lolinder wrote: post #97

Earlier quoted context omitted.

It would violate #9 no matter what implementation you use, and #9 is absolutely essential to tools like ESBuild, Deno, and Bun, which all rely on the assumption that they can nearly instantly strip out the type annotations and execute the code as JS.

You'd still be able to execute the code as JS. Your library that uses type reflection wouldn't work anymore but that's true of all these solutions.

No, it's not. I can take a library that uses zod, strip the annotations, and it will execute perfectly anywhere I want to run it.

Re: TypeScript please give us reflection/runtime types

#108

Post by Barrin92 »

twelve40 wrote: post #64
andix wrote: post #5

There 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…

> dynamically typed language, and that's also nice what is nice about a dynamically typed language? like, seriously, can you list some reasons for a dynamically typed language to exist?

Peter Norvig summed it up in one of his presentations https://norvig.com/design-patterns/design-patterns.pdf

"Dynamic Languages have fewer language limitations Less need for bookkeeping objects and classes Less need to get around class-restricted design. Study of the Design Patterns book: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern[...]"

Re: TypeScript please give us reflection/runtime types

#109

Post by RyanCavanaugh »

jxf wrote: post #91
paxys wrote: post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

> This is exactly why simple, concise writing is essential, and their wall of text is...not it. I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy. > They are really asking for a net new product which has very little to d…

You can use the TypeScript API to generate this information at whichever level of detail you want.

The level of detail TS has about types during the checking phase is much higher than you would want in practice for 99% of projects (e.g. 1 + 2 + 3 has 6 different types associated with it).

The level of detail TS has about types during the checking phase is potentially lower than you would want in practice for a lot of projects (which is critical since that makes the whole feature useless if that happens). For example, the list of properties of a particular generic instantiation is lazily computed, but it's possible your program never pulls on the list so it never exists in the first place, yet is something your type-based tool might want to know.

Re: TypeScript please give us reflection/runtime types

#110

Post by mrkeen »

shadowgovt wrote: post #59

Normally I'd say "hard pass." I'm pretty comfortable with static types being a model where the compiler throws the type information away at compile time, so I can type with abandon without worrying that I'm going to impact runtime performance in my generated code. ... 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 yo…

Why not just let the compiler build the deserialiser out of the runtime information during compile time, and then throw out all the types?
Post reply on HN