TypeScript please give us reflection/runtime types
github.com
github.com
> 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 and mire of a world where we are doomed to endlessly crawl on our bellies through the alleys of Github seeking the one true npm. We will forever wonder in the dark, until we have a type reflection model.
What even are they getting at?
As for their actual ask (runtime type safety), it is probably not going to happen because the TypeScript project has drawn the line at not being an alternate or additive runtime for JavaScript. Their job is simply to compile down to JS code and exit the picture. Whatever happens after that (in V8 or elsewhere) is your own business.
> TypeScript Needs to Emit Runtime Type Information
This is not possible at all because TypeScript is a compiler. They are really asking for a net new product which has very little to do with the TypeScript that exists today.
> This is not possible at all because TypeScript is a compiler.
Sorry, can you clarify? Many compilers exist in other languages that support RTTI, so it's not clear to me what you mean by this.
That's exactly it, it doesn't. That project you linked (typescript-rtti) mentions in the README that you must install and use it via ttypescript, a typescript wrapper that patches the compilation process to expose compilation details to plugins. Except that plugin API is unofficial and changes break the ecosystem built on it. For example, ttypescript doesn't work for TS 5 and the dev doesn't want to spend time on it. ts-patch has stepped in to provide a source transformer API for TS 5.
There's no way I can recommend libraries like typescript-rtti in commercial projects until something changes. I hope the ts-patch folks don't burn out.
Not sure if this supports your point. Lots of compilers emit runtime type information, e.g. Golang, Java.
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 would be to use /compile time/ reflection to generate code (TS code hypothetical, because I write C++ nowadays):
function validate<T>(obj: Any): T | null {
switch constexpr (T) {
case String:
return typeof obj == "string" ? obj : null;
case Array<U>
if (!Array.isArray(obj)) {
return null;
}
for (const u of obj) {
if (validate<U>(u) == null) {
return null;
}
}
return obj;
// ... more base cases
}
for (const prop: (keyof T) of Reflect<T>.Properties()) {
if (validate<T[prop]>(obj[prop]) == null) {
return null;
}
}
return obj;
}
interface Date {
year: String;
month: String;
day: String;
}
function validate__String__(obj) {
return typeof obj == "string" ? obj : null;
}
function validate__Array$Date$__(obj) {
if (!Array.isArray(obj)) {
return null;
}
for (const u of obj) {
if (validate__Date__(u) == null) {
return null;
}
}
return obj;
}
function validate__Date__(obj) {
for (const prop of ["year", "month", "day"])) {
if (validate__String__(obj[prop]) == null) {
return null;
}
}
return obj;
}
(The above example is a hypothetical TypeScript compiler that might support "templated" generic functions; with just RTTI TypeScript could accomplish the same thing in a non-templated function by passing in `T` as a function parameter at runtime and doing runtime comparisons on `T`.)
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.
And even if you are--that might also involve ensuring their tsconfig.json is compatibly similar to yours. Otherwise the compiler might allow them to return null instead of the object they say they return, among potentially many other "gotchas" that are bound to appear.
EDIT: Though I think I do agree with you, ultimately. Runtime type checking imposes non-negligible costs and complexity that still theoretically should be able to be guaranteed at compile time for cases where one isn't validating untrusted user input.
Well that, and getting rid of the silly "must be able to strip types without processing them" design ideology would also enable stuff like typeclasses.
Did you read the article? I think that's the point. The premise is Typescript should be responsible for solution to runtime validation against Typescript not third party hacks.
Alternatively, use a runtime validator the provides good type inference out of the box so you're still only declaring your types once.
If typescript emitted type information, we'd be able to automatically get runtime validation at the boundaries of our apps.
Right, but now my type information for inbound data must be in two places: the typescript type, and the validation schema. And heaven forbid I make a mistake and those two become out of sync.
Yes, I can use something like zod to define a schema then infer the type from it, but those inferred types are often … suboptimal to work with.
When I produce a type definition for a nested schema, I'll produce types for individual pieces.
So
type Schema = { foo: Foo; bar: Bar; baz: Baz[]; }
type Foo = { red: Color; white: Color; blue: Color; }
type Color = { r: number; g: number; b: number; }
type Bar = {...} type Baz = {...}
I couldn't find a clean way to decompose the type that z.infer<Schema> produced. It would give me a single type object that was deeply structured. For a pretty flat-simple small schema, z.infer<> was totally fine.
For the more complicated schema it wasn't _terrible_, I still used it. I made it work, but it definitely wasn't the dev experience I was hoping for.
I think something that went the other way would be much preferable for me. I'd rather define the typescript type, then have some validate<Schema>() function that was available to me.
Basically, I think it's _easier_ to get a generated validate() function to play nicely with the rest of my code, than it is to get the inferred type to play nicely with the rest of my code.
It is also the most frequent thing where junior developers get stuck. TS tooling doesn't make it very easy to work with large extracted types though it is head and shoulders above other mainstream languages. The error messages often become incomprehensible walls of text once your types are Complex enough, and then tsserver will just truncate the type info in pop overs making them useless.
I am personally OK to live with all of the above. My single issue with zod is that it is not easy to use if you don't own your types. If your types are coming from a third party lib you don't have an easy path to derive runtypes from them. If the concept of runtypes was supported by the compiler itself, this could have been possible but as a userland library zod can't handle this easily.
Imagine a Zod schema like:
const UserLocation = z.object({ address: Address, coords: Coords })
where Address, Coords are other zod schemas.
Now if I infer a type like:
type IUserLocation = z.infer<typeof UserLocation>
Th inferred IUserLocation is something like:
type IUserLocation = { address: { city: string, country: string, ... }, coords: { lat: string, long: string } }
The extracted type does not refer to separate Address, Coords type, it is a single complex type that represents the complete nested structure.
So if I do something like:
const userLocation: IUserLocation = { address: { ... }, coords: { lat: 0, long: 0 }}
The error message is complex because it (effectively) says that coords.lat was expected to be a string from IUserLocation["coords"]["lat"] but it was number
However, if I define a ts interface directly:
interface IUserLocation { address: IAddress coords: ICoords }
now any errors reported against this interface will be more comprehensible because they will (effectively) say that coords I am providing does not comply with ICoords.
This is a contrived example, but this becomes more complex when you have deep compositions of zod types.
This issue of typescript not using well named intermediate types when types are "extracted" from schema definitions like zod is what makes the error messages complex.
This would not apply if typescript was to provide runtime type checking for interfaces defined in typescript (as opposed to them being inferred) because ts will have a way to "know" about these intermediate types. Then the type errors would not have to be always reported against the complex top level type.
I just realized that I am working around this problem by explicitly setting a `z.Schema<...>` type: [link redacted]. The reason was to retain JSDoc comments on the types, but I guess this was another positive side effect.
In any case, I agree with you that there is room for improvement.
Thanks for maintaining kanel btw. We used to use this in a previous role alongside knex. It was very useful.
[1] https://lorefnon.me/2022/06/25/generating-api-docs-for-zod-t...
interface Person { firstName: string; lastName: string; }
const PersonSchema = z.object({ firstName: z.string(), lastName: z.string(), }) satisfies z.Schema<Person>;
My complaint about writing the schemas twice isn't the busywork (which is, like, annoying, but whatever I'll live). But the concern about small discrepancies between the two causing problems later.
I'll definitely use this going forward.
To the extend that TS's type-system is unsound, and everything may crash at runtime at random anytime.
schema Example { ... }
cosnt example: Example = new Example(unkonwnData)
So type script more or less supports the feature they asked for. Just not bundled with the main package, but they provide the interface to get it done with 3rd party transformers.
At which point it makes a lot of sense to ask why that feature shouldn't be merged.
They just serve burgers and fries. And they are doing very well with that strategy. Same goes for TypeScript.
There are dozens of questions you can throw at this code: What if the input's a union? What if it's a nested union -- how do you avoid combinatorial explosion? What if the input is a function -- how do you validate its parameter types using runtime information? What if the input is a conditional type? What if you're inside a generic function? The list is enormous and it quickly gets into "you've dug too deep and unleashed a Balrog" territory once you get beyond the primitives.
Typescript is mature. There is no low hanging fruit to be develop.
I don't necessarily think it needs this but this is hardly the right grounds to dismiss it.
I've got a fully functional compile-time dependency injection container that I've been sitting on for literal years because the transformer API isn't public.
(So as it turns out having thought about it a bit, I am vehemently against this idea.)
Type reflection at runtime would require polluting the JS environment with a lot of cruft.
That might be a global object and lots of helper functions to query types. It might also be tagging objects and fields with additional properties that need to be treated as reserved.
There is certainly no way to do this that doesn't make assumptions about the runtime environment in a way that will cause a mountain of issues further down the line.
The other reason for my disdain is: the need to infer types at runtime is almost certainly indicative of an architectural issue with your code. If you aren't able to write viable code in a given context without requiring runtime type querying then you should step back from your intent and re-evaluate your code structure.
For example suppose I have a web request coming in and I have essentially just a string of input coming in on the body. I have an expectation of what it needs to be but there is a step where it is of type `unknown` and I need to convert it into `IMyHandlerInput`. Just casting it is obviously a bad idea and so now I need to essentially use some kind of library such as ajv to do json schema or jtd validation, _then_ I can cast it into my interface.
This is all fine but it definitely feels redundant to me. It would be a cool _ecmascript_ feature to essentially support, not runtime types per-se but syntactic _validation_ which can also be used by typescript to derive types automatically.
This is totally hypothetical but I'm imagining something like this for example:
```ts schema Example { @min 0 id: number
@pattern /^\w+ \w+$/
name: string
@future
expiresAt: Dateconst data: Example = new Example(JSON.parse(body)) ```
Something that the JS runtime can use to allow developers to opt-in to extensible validation which can also be used by the typescript interpreter to essentially derive types.
I write one of them (typedload).
If it's a union, it has a bunch of heuristics to guess right at the 1st try, but otherwise it will just try them all.
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 do with the TypeScript that exists today.
This is information TypeScript already has today but which it discards. It wouldn't take a "net new product".
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.
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.
Some people have very tight constraints for payload size, and types could blow up payloads
Conceptually it feels like there should be/needs to be some buy in on high, a shared vision that tsc is not the one, only & singular tool in the typescript-verse that ever can or will care about types. Trying to constantly break in & exfiltrate the data isn't ever going to get a position where the world takes this seriously; typescript needs really should gladly be opening the gates.
As for whether the type information is in fact part of the payload, that's a separate question, and one that should ideally be configurable. It's definitely a bit of a complex situation in general; ideally we'd have good/easy ways for libraries to include this information but then we also want want to be able to strip it out easily.
Maybe we just regenerate it as needed from ts source of libraries when we need it. But that implies not running a single typescript compile with one set of settings but running many compiles, as each library has its own tsconfig it'll need that informs how files are laid out & other sundry details. I might be overcomplicating. Perhaps we could just generate a foo.reflect.js, that has all the reflection data? There's options.
That's not correct. All you would really need to do is output type information as JS objects and then support reflection libraries that looked up information at runtime. Two examples where this already happens:
1. TS enums are output as JS objects, as opposed to, for example, string literal union types. That is, "enum Foo { Bar = 'BAR', Baz = 'BAZ }" outputs information that can be queried at runtime, while "type Foo = 'BAR' | 'BAZ'" does not.
2. TS already supports runtime type guards functions, https://www.typescriptlang.org/docs/handbook/2/narrowing.htm.... It wouldn't be hard to generate those functions automatically using information already in the type system.
1. I was responding to the point that seemed to be arguing that just because TS is a compiler (to JS), that it couldn't support runtime type info. That's incorrect, and different from the current philosophy of "TS should really only use type erasure when outputting JS code".
2. After many years I've come to the conclusion that there is huge benefit for an ecosystem to either (a) have a "batteries included" mindset, or (b) have a way to "semi-officially" designate associate libraries as being supported. I think Java really excelled here. For example, the Java Collections library was/is excellent, and for a long time (not sure if it still is, I've been out of the Java ecosystem for some time now) Apache Commons were the go to place for libraries everyone used. Contrast that with the Node/JS ecosystem, where basically "whatever gets the most popular in NPM" becomes a semi-standard, but there are still often 5 competing libraries, and until the module owner decides to delete a widely used library or just stop releasing updates - besides leftpad infamy, there was also an issue where lodash basically went unreleased for a long time despite needs for critical security patches.
When it comes to TS, I understand the guiding principle of "we only implement type erasure", but I wish there at least a way to e.g. set a tsconfig flag if you wanted to allow runtime data, or to have the equivalent of Apache Commons for TS.
I do think theres room in the world for typescript to be able to emit runtime code from its types, but I don’t think it should be in the business of writing validation libraries.
Closest they should get to this work is writing an interface to export types types into runtime code that another lib can pick up and write validators with.
The only missing link is then that Javascript objects don't know their original Typescript type, that would need to be magically injected by the TS compiler as a custom property.
How useful that would be in practice, no idea... I can pretty much only see downsides (mainly increasing bloat).
Also the same thing can probably be implemented in 'user space' by a tool which parses .d.ts files and code-generates such type-database modules from that information.
I don't understand. Go is a compiler too, but here's https://pkg.go.dev/reflect
I understand the desire here. Runtime type checking is often necessary for data validation, and we can see lots of libraries developed to help fill the gap here. But I think the fact that there are so many libraries with different design decisions is pretty indicative that this is not a solved problem with an obvious solution. We knew this going into the early design of TypeScript, and it's a principle that's held up very well.
What have been happy to find is that we've grown TypeScript to be powerful enough to communicate precisely what runtime type-checking libraries are actually doing, so that we can derive the types directly. The dual of this is that people have the tools they need to build up runtime type validation logic out of types by using our APIs. That feels like a reasonable level of flexibility.
I understand that everybody who needs it can already put their own preprocessor that generates runtime objects from type information before the code is passed to tsc for compilation.
But the effort is inconsistent and distributed.
If TypeScript officially supported pluggable preprocessor and plugin ecosystem for it some good solutions might get discovered.
Generating code based on type annotations is frequently requested feature directly related to the core feature of TypeScript which is type system.
Until they hit a roadblock caused by a leaky abstraction, that proves them otherwise.
And I think that's actually the reason why it won the competition against Googles Dart. They even used Microsofts TypeScript for Angular instead of their own language Dart.
I'm imagining a language where I could define a custom data type with a regular function. For instance, I could have a method that the compiler would use to verify the validity of what I input, as shown below:
function PercentType(value: number) { if (value > 100 || value < 0) throw new Error();
return true;Is the lack of such a feature in TypeScript (or any language) a deliberate design decision to avoid unnecessary complexity, or due to technical constraints such as performance considerations?
type Enumerate<N extends number, Acc extends number[] = []> = Acc['length'] extends N
? Acc[number]
: Enumerate<N, [...Acc, Acc['length']]>
type NumberRange<F extends number, T extends number> = Exclude<Enumerate<T>, Enumerate<F>>
type ZeroToOneHundred = NumberRange<0, 100>
Similarly for zip codes you could create a union of all possible zip codes like this:
type USZipCodes = '90210' | ...
In functional programming this is often handled with the Option which can be thought of as an array with exactly 0 or 1 elements always. 0 elements when a constraint is not met and 1 element when all constraints are met.
This [0] is a library I wrote for JS/TS that provides an implementation of Options. Many others exist and other languages like Rust and Scala support the Option data structure natively.
It makes a lot of things impossible. For example, if you defined two different types of ranges, OneToFifty and OneToHundred similarly to your PercentType above, the following code would be problematic:
let x: OneToFifty = <...>;
let y: OneToHundred = <...>;
y = x;
In other words, any two custom-defined types like that would be unassignable from and to each other, making the language much less usable. Now add generics, co-/contravariance, type deduction, etc., and suddenly it becomes clear how much work adding a new type to the type system is; much more than just a boolean function.
That said, TypeScript has a lot of primitives, for example, template string types for five-digit zip codes:
type Digit = '0' | '1' | '2' | '3' | <...> | '9';
type FiveDigitZipCode = `${Digit}${Digit}${Digit}${Digit}${Digit}`;
There's sort of a meme where you should never ask why someone doesn't "just" do something, and of all the people you shouldn't ask that of, programming language designers are way, way up there. Every feature interacts not just with itself, not just with every other feature in the language, but also in every other possible combination of those features at arbitrary levels of complexity, and you can be assured that someone, somewhere out there is using that exact combination, either deliberately for some purpose, or without even realizing it.
This is somewhat supported with template literal types, https://www.typescriptlang.org/docs/handbook/2/template-lite.... However, there are good technical/performance reasons they don't support, for example, plain regexes - there is a HUGE discussion on this topic here, https://github.com/microsoft/TypeScript/issues/6579.
Another interesting point of reference are "refinement types", which allow you to specify things like ranges to "refine" a type; the various constraints are then run through a kind of automated reasoning system called an SMT solver to ensure they're all compatible with each other.
type PostalCode = `${Digit}${Digit}${Digit}${Digit}${Digit}`;
type Digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';
Ranges like percent are much trickier—TypeScript would need to compute the return type of `Percent + Percent` (0 <= T <= 200), `Percent / Percent` (indeterminate because of division by zero or near-zero values), and so on for all the main operators. In the best case scenario this computation is very expensive and complicates the compiler, but in the worst case there's no clear correct answer for all use cases (should we just return `number` for percent division or should we return `[0, Infinity]`?).
In most mainstream programming languages the solution to this problem is to define a class that enforces the invariants that you care about—Percent would be a class that defines only the operators you need (do you really need to divide Percent by Percent?) and that throws an exception if it's constructed with an invalid value.
You just need to spark it, community will help maintaining it.
It would solve all codegen needs from generating clients to runtime type assertions and many interesting problems in between.
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 JavaScript. But JavaScript is a dynamically typed language, and that's also nice. Be happy with what you have!
I just finished removing them from a major project. Here’s a few of my personal notes:
1. They don’t play well with duck typing. (Eg. show me a subset of an enum)
2. They require an import every time you want to utilize them.
3. They are pretty wordy compared to union strings.
4. Their string value version encourages misuse as a key-value pair.
5. Unless you use the string value version, they suck to debug because logs just show 0,1,2,3.
There are too many ways to accidentally import/redeclare/rescope the Type of an enum so that TS "knows" the Type, but because that type (generally) has the same "name" as the most likely (Locator) Instance it assumes the same access applies leaving runtime errors behind when that Instance isn't actually imported/available. Typescript has no easy way to tell the difference between access to the Type isn't access to the (Locator) Instance (nor vice versa). Reasoning about those runtime errors or preventing them is additionally tough for people too because of the same "name" problem for two different things.
This is something that's painfully hard to avoid in cases where you are trying to encapsulate an API's Types separate from its imports/exports because they might be introduced or manipulated at runtime (plugins, sandboxes, proxies, etc). Unfortunately, this is also too easy to accidentally do even when you aren't intentionally doing something complicated like that (trying to generate automated .d.ts files in a bundling toolchain, for example, when APIs are in the boundary space between unintentional public API and internal tree-shaking or optimized symbol renaming).
enum CheckboxState { On; ParentOn; Off; }
Becomes
{ [0]: “On”, “On”: 0, [1]: “ParentOn”, “ParentOn”: 1, [2]: “Off”, “Off”: 2 }
So things like Object.keys give bizarre results. It’s done this way so you can use the name or the value as an index.
IME, most of the complaints about enums apply only to numeric ones.
The major exception to that AFAIK is the fact that enum members of any type are treated as nominally typed (as in A.Foo is not assignable to B.Foo even if they resolve to the same static value). I am among the minority who consider this a good thing, but I recognize that it violates expectations and so I understand why my position isn’t widely shared.
In every workflow I've seen, TypeScript is already a language that gets compiled to JS. It might as well take full advantage.
To make dynamically typed languages nice for bigger projects we have typescript for type annotations (it's does not make it a statically typed language!). It is there, it is used, it scales and it works. If your type script project "collapses entirely", it's probably not the languages fault.
For instance with Generics in Java a List<String> is the same as a List<Integer> at run time, the compiler can enforce rules that let you add a String to one but not add a String to the other but the runtime has no idea. This has various negative consequences but it also let them retrofit generic collections on top of the old collection implementation in Java unlike the disaster in .NET where both had to coexist for years.
Similarly C compiles to machine code and in machine code there are just memory locations and registers, types are implicit in how you use those things but not spelled out explicitly. C++ does have RTTI but is one of the many open pits, like Exceptions, in C++.
Typescript types are the same way, once the compiler has done its type checking you know the code is going to behave according to the type system even if the types have been "erased".
If you make an ArrayListX that is not generic but extends ArrayList<X> it is possible to see the type parameter that was extended, the same is true for implementations.
There are other kinds of type unerasure that you can use w/o the language supporting it explictly, such as you could pass the type parameter X.class into the constructor and put it in a field so that you could call some method like getContainedClass() and get a copy of X.
Now the introspection/reflection API does have support for talking about parameterized generic types that doesn't mean that information always exists at runtime.
I worked on a crazy project where I did a lot of fighting with ordinary types and parameterized types and unerasing types by rewriting the names of methods to avoid conflicts, if you have methods like
A doSomethingTo(B)
A doSomethingTo(C)
Expression<A> doSomethingToB(Expression<B>)
Expression<A> doSomethingToC(Expression<C>)
https://github.com/paulhoule/ferocity/blob/main/ferocity-std...
that project got me thinking a lot about the various ways types manifest in Java and I made the discovery that when you add Expression types you practically discover an extended type systems where there are many things that are implied by the existence of ordinary Java types.
I like Venkat's presentations: https://www.youtube.com/watch?v=34oiEq9nD0M
BTW. I do not agree with the opinion in the topic. Since Typescript is compiled to something else (usually JS), I'd prefer Typescript to have proper annotations (there are "decorators") and compiler hooks and just use code generation for concerns like (de)serialization.
Yes, but also no. The point is that it doesn't really add more semantics over plain JS. You can erase all the type annotations (well, replace with "any") and it'll do the same thing if you ignore the type checking.
If there's any "transformation" from TS to different-looking JS[0], it's mostly just syntactic embellishment (think LISP macros and such), not semantic.
[0] Not sure if there is, tbh
> 3. Impose no runtime overhead on emitted programs.
> 9. Use a consistent, fully erasable, structural type system.
It's also explicitly called out as a non-goal in that doc:
> 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.
> 6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.
[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
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 only point this would violate is #5 but that is, of course, the point. We want them to reconsider because it's such a powerfully useful feature. And people are doing it on top of and outside of TypeScript where TypeScript would be best tool to give this information for TS users.
Today, you can already write a program using the TypeScript API to inspect all of this information to accomplish whichever scenario is at hand. The existence of all these tools, each with different opinions on design direction and implementation trade-offs, demonstrate that this is possible. Yet it's not demonstrated how those tools would benefit from reading from a data file as opposed to using the TypeScript API.
Something like api-extractor has different constraints from io-ts which has different constraints from typescript-schema. The API exists today and is apparently sufficient to meet all these tools' needs, yet what's proposed is a data file that can encapsulate any possible operation you might perform with that API.
Having TypeScript try to imagine, implement, and maintain a data file format that can satisfy _all_ of these tools' use cases, plus any future tool's use case, is a tremendous effort with no clear upside over using the existing API.
It's easy to gain support for the idea of "put the types in a file" because anyone reading that can imagine a straightforward implementation that just achieves their particular goals, but everyone's goals are different and the amount of overlap is not actually all that high when you look at the wide breadth of tools in the list. There's a very different amount of information you'd need to enable a type-aware linter (which is basically type info on every expression in the program!), as compared to a simple documentation generator (which might only need top-level declaration info).
TypeScript: We can write our own type file format!
Situation: There are 15 competing type representation formats
Though while there's a lot of type-data tools, are there actually a lot of type-data formats out there right now? I've been using zod, and it doesn't have one. You have to use code to tell it about a type. Someone did make a library to let zod load types from pure data, but the format used there is... typescript source code.
The fp-ts, io-ts author Giulio Canti has decided that the best way to proceed was to merge the two communities of fp-ts and effect, even though it's his work that is mostly known with effect being much more niche.
It's essentially io-ts squared in its powers. The amount of things you get from schemas are endless, not just decoders and encoders but also apis, lenses, constructors, and many other things.
It's obviously heavily fp-leaning, albeit I would say effect systems such as effect, based on Scala's ZIO, are much more approachable than haskell/purescript-like languages.
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.
Consider
const fooType = generateTypeInfo!<Foo>();
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.
However, such a preprocessor will basically need to re-implement TypeScript's type checking. So either TypeScript must expose it via an API, or the preprocessor needs to itself implement a subset (which as mentioned, could also be faster)
const fooType = getType<Foo>();
Typescript isn't a runtime on top of JavaScript, but it very much is "a new language that compiles to JavaScript".
This means that you can run and test code that doesn't typecheck yet -- very useful during development. Also, production builds can run the typechecker in parallel with other build steps. That's how we optimized our build system at work.
But essentially, it's a design choice by the TypeScript team. They've decided that TypeScript shouldn't add runtime features on top of JavaScript, but instead should simply type JavaScript, and I think this has contributed to the success of TypeScript.
what is nice about a dynamically typed language? like, seriously, can you list some reasons for a dynamically typed language to exist?
With dynamic languages you can just code, without being held back by a OOP type system, but it can get very complicated to understand what the typed of you parameters and return values actually are.
Typescript gives you the best of both worlds.
"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[...]"
If you want a statically and runtime typed language in the browser, you should not use typescript. Use Kotlin, Rescript, …
As such, RTTI would make typescript go from a compromise language (we use it because we are stuck in the JS ecosystem, not because it's a good tool) to a legitimately useful backend language (We use it because it has the right features for the use-case)
If I could choose what language we use on the backend, I would leave the JS ecosystem entirely and write everything in .Net. But it's difficult to find .Net developers since every bootcamp these days produces react developers
It would be best to abandon javascript and typescript as backend languages. I don't mind them on the frontend because a typescript compiler is useful when the application you're writing is originating data and not receiving it. And javascript does DOM manipulation admirably. However, we live in a world where humans are more expensive than computers. If I had my way, we'd write C# backends and Angular/Typescript frontends, but that's not the world we live in. Everything has to be JS because most people employed as "software engineers" are not truly very good at their jobs
TypeScript is an entirely optional layer on top of JavaScript, with the exception of `Enum` that emits an object, many of which see as a mistake. You don't even have to "transform" TS code to get JS: you just have to delete the typings. The rest is just JS.
Unless you want to depart heavily from this principle, which I think is crucially important so long as there's still human-maintained JS code out there, what I think they're asking for is a library to take the types and write serializers/validators for. Which there are many of. So I think the real request is to make the one canonical choice out of a field of many choices, which I also agree with the spirit of. But is that really in scope for the TypeScript project?
What I personally don't want is runtime reflection for TypeScript. Or at least, not a core part of the language. Because I like that TypeScript is just for compilation and at runtime you just have JavaScript, without any sort of abstraction layer that turns JS into some sort of intermediate representation with overhead or more indirection for debugging. I cherish the fact that even without source mappings, my output JS is perfectly legible and debuggable.
There are other exceptions, most of which are considered mistakes as well, the most obvious which come to mind being `module` and `namespace` as runtime constructs. But I’m fairly sure these have been primarily used by TypeScript itself for at least a few years, and even they recently migrated away.
Another one that comes to mind is, I believe, actually pretty popular: what they refer to as “parameter properties”, ie class members whose types are defined in a constructor’s parameters. These seem to have escaped controversy because they eliminate a lot of redundant boilerplate, and generally behave in obvious ways (at least as obvious as their redundant boilerplate JS equivalents).
Sure if you consider the whole language, typings
If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you.
I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern itself with runtime validation UNLESS JS gets some agreed upon way to do it.
I feel like Promises, decorators and the new pipe operator all went into the wrong directions with their implementations.
(I'd also add modules to your list fwiw, they were designed without taking performance into account.)
I’ve worked with people who find it too complicated or they feel like it should be baked into the language, but I’d argue there are so many contentious design choices in these libraries that it might actually be best to be an implementation choice, selected based on a project and its specific needs.
Zod has been very good to me though. It’s quite easy to get up and running with, and its API has never gotten in my way when scaling things out.
My one complaint is that certain patterns I love, such as runtime validation with zod and deriving types from schemas, doesn’t necessarily always play well with something like pattern matching in ts-pattern. The type definitions behind these libraries are labyrinths, and cases where something seems like it should work won’t always behave as expected. On some level, I do wish these were seamless language level features, though I fully recognize these are selfish desires.
But imagine having runtime safety combined with exhaustive pattern matching. I’d be very happy to have that.
Typescript does not change runtime behaviour, there is no special typescript {#if}
It's true. I don't remember if that was the only/main reason they said that, but that was definitely one of the things.
I find that a weird sentiment, though, because TypeScript has a couple of other features that are not just "JavaScript + type annotations".
Namespaces is one. It also has a syntactic sugar for defining class properties in the constructor arguments. And it had that experimental decorator feature for a long time, but I never used it, so I don't know much about it. It also has the "`this` parameter" syntax for methods/functions, which does disappear at compile time, but still looks and feels like more than just a JavaScript function with type annotations.
So too are "experimental decorators" another thing that some of the developers seem to list as massive regrets. That example is even so much worse than namespaces because it wasn't justified by existing patterns used in Production JS at the time and that they even believed that requiring a compile-time flag with the word "experimental" in it would stop developers from using that compile-time flag in anything destined for Production usage. (Seriously, we all should shame the many projects/companies that did that.)
AFAIK the best current solution is emitlDecoratorMetadata. [1]
[1] https://www.typescriptlang.org/tsconfig#emitDecoratorMetadat...
I think the author misunderstands the design goals of TypeScript. The goal isn't to have pristine, beautiful JS code with no complexity, the goal is to have the runtime semantics of TypeScript be identical to the runtime semantics of JavaScript. Barring the regretted exception of enums, TypeScript can be converted to JavaScript by simply stripping type annotations. That's the design goal, and that goal is not in conflict with itself.
The ecosystem that has built up around TypeScript depends on complete type erasure, and much of it would evaporate if this wish were granted. TS support in ESBuild, Deno, and Bun would become nearly impossible, because each would need to re-implement all of tsc in their respective languages, while right now they just need to maintain their own simplified parsers.
On the other hand, the convoluted libraries that OP bemoans are perfectly compatible with all of these tools, because they're implemented in user space.
Or some kind of syntax to emit the name of a type as a string. Currently, if you run `typeof foo` it will return the type as a string. If you could have a static version of that, like `tstypeof foo`, or with a class:
class Foo {
bar: string;
};
console.log(tstypeof Foo::bar) // or something less C++-looking; compiles to "string".
Just some basic RTTI would make a lot of ugly codesmelly boilerplate Typescript code evaporate instantly.
That being said, TypeScript is differently capable from C#. C# is nominally typed, with decent reified generics. I like programming in C#, and miss its features when programming in TypeScript. TypeScript, on the other hand, is structurally typed, forgoes soundness, and comes with a powerful type system to express complex type relationships (again, possible because it forgoes soundness). I like programming in TypeScript also, and also miss its features when programming in C#. I doubt a language that combined C# and TypeScript would be very nice, these languages go in different directions to good effect, but they are not compatible directions.
That’s not the language or type system per se, it’s the compiler implementation or rather the philosophy to stay close to js and have a very thin (powerful) layer at compile time only. Typescript in wasm, Deno maybe (didn’t try yet) etc could change this. Then we can have types as in other languages. Not sure why this would not be a win for everyone vs the current status.
Also, as you know, the run the web went out the door with nodejs; many backends are now typescript and indeed competing (… for at least writing web apps) with c#.
C#, and the CLR underneath it, were performance based, and the types feed into that. The reason they both are as they are is because of the environments they are meant to be used in. So ya, are you running web apps on the CLR, or are you running them in the browser. I don’t really get nodejs, or, i guess it only seems like you would go that route if you wanted to reuse your web browser devs or web browser code to run also in the server.
Simple one, distinguishing `2` number with `2` currency in your domain.
The problem is that the deserialization is untyped. It's just a Javascript object. Usually, the first thing you'll do is to cast it to a typed Typescript definition, but there's no way to guarantee that it actually fits that definition. No type information exists at runtime. It's used solely to check the code itself during compilation.
So any time you get data from outside of your program (over the network, from a database, out of a config file, etc.) you just have to hope that it actually fits the type. You can write code to check it... but you have to write that code yourself.
There are libraries you can use. For example, you can use a Data Description Language with a simpler type system, which usually suffices for the kind of data you want to serialize. Then you can use that to generate both a Typescript definition and a runtime type checker. But that's inelegant, and not standard, so every project is different despite it being something everybody needs.
JavaScript has a very simple built-in json reader/writer that does no type checking and returns some nested dictionaries or arrays. If you want more, you need a library (for example zod). Or you just trust the data to have the right shape.
I imagine C# and other Java-esque languages have something similar. But Typescript deliberately avoids that, and it would be difficult to get it to do so.
Additionally, because it is impossible to emit these types to the runtime, even in the form of a string naming the type, you cannot validate input to an API using generics. If you have, say, a class which will run a query for a record based on the keys in that record:
class Query<T>{
filter: Array<keyof T>
};
Because there is no real relationship between the class and the runtime validators, this makes validation more error prone, because it relies on either human beings to consistently remember to add new fields to the relevant decorators, or a custom linting tool to be written which basically pre-processes the typescript source using the typescript API. This is, again, writing code to account for the lack of features in the framework.
WHY do we put up with this crap? We have had Java and C# for a long time, and they solved these problems a long time ago. Why are we writing Typescript on the backend?
The simple answer; it is easier to find javascript developers than it is to find java developers. Bootcamps don't teach Java or C# because there's more react jobs out there. Bootcamp grads are not generally coding enthusiasts and so re-tooling is difficult for them and they don't generally do it for fun. So, we decided to write our backend in Javascript (or Typescript) as a labor decision, not a technology decision.
With c# I've seen openapi interface generators that don't validate properly, only basic deserialization. I've seen dto's that are deserialized wrong due to lacking null checking attributes. I've seen the way put requests are misused due to how difficult it is to separate null and undefined in patch requests. I've seen dto's with all nullables due to the lack of union types. Maybe I've yet to see a good c# codebase, but I certainly prefer typescript over the above.
For what it's worth, I want my production bundle to be as small as possible. Most people use bundlers among TypeScript, which further complicates things.
I would love a standard library to e.g. generate type predicate functions from TS types.
Taming the beast from this end might even end up useful for things like compilers, no?
TS provides a nice mechanism to be strict in the frontend and validate types using runtime code, that is, type predicates.
But from a higher level, this has never been enough, and you want to map JSON to TS types using some kind of schema definition.
I would love to just be able to pass in a TypeScript type and generate its type predicate at compile time.
Unfortunately, this is impossible due to the halting problem.
So, a standard solution for the case of a plain serializable JS/JSON object and the according TS interface would be very much welcome.
Edit: and all of this is of course about data from external sources (requests, DOM, compiler...). For all of the code and data known at compile time, there is rarely a need to validate types, as they are statically analyzable.
So there is a huge scope that TypeScript has to cater to. It includes JS projects where external type definitions often become obsolete and people who code in TS but do not enable strict mode for their own code (that is, disallow "any"). And all of these type defintions have to be interoperable.
For API requests, this is basically calling for a default generic REST client, and I agree that would be useful. The REST client could use type predicate functions extensively.
If this is done, TS will become something entirely different as it currently doesn't have a runtime: it's a huge-and-smart linter.
But that's all about it. No matter how huge, it's a linter.
Reflection would imply something beyond that. Even though I absolutely love reflection, I believe it should not be integrated into TS.
Input is bytes. Bytes will never carry their type information (and if they did, you couldn't trust them). So the type information needs to be used in the Deserialiser, not its input.
To get typed deserialisation of Foo, the compiler needs to generate a FooDeserialiser automatically for you. The compiler can't depend directly on Foo (Foo is written after the compiler), but if Foo could somehow emit its type information during compilation, then the compiler could depend on that.
It'd be lovely the way you described.
You just write
const personType: Type = typeof(Person);
const personType = {
name: "Person",
fields: [
{ name: "lastName", type: "string" },
{ name: "firstName", type: "string" },
],
}
If you would implement validation by hand, you'd come up with absolutely conceptually identical code. Look at any validation libraries out there.
The only difference is: you specify types with nice TypeScript language, not with some made-up abomination DSL.
If it's the way you've shown it'd be great!
With this proposal those tools must become extremely more complicated and probably they will just be as slow as tsc.
TypeScript's type system is indeed way more verbose than Haskell's.
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 JS-compatible, so the type system seems really crude? I can't put my finger on it. It sort of hits this weird inbetween where js is quick to write/prototype and rust is extremely "correct" but the ts type system slows things down/annoys me without providing enough benefits. Also, working with it in nested projects via npm tends to be a huge pain in the ass. Maybe I need to switch to Deno or something so it's native?
Now that rust/wasm is ramping up, I'm considering using rust for the API layer and something like Leptos for the frontend. I've been getting into svelte a lot, and Leptos seems similar enough to not be a huge leap.
It also has a WASM compilation target that is under early development. https://docs.flutter.dev/platform-integration/web/wasm
I wish Flutter was just a regular GUI library for another language (C maybe, so you can use it from everywhere, that'd be nice). Dart really killed it for me. Also, I know it's beating a dead horse, but Google doesn't have a good track record with long term support of their projects. If it was a grassroots open source project, I'd probably feel a lot more secure putting aside my Dart-inflicted OCD and really picking it up.
Given my current love affair with Rust, my main squeeze right now is Tauri. Once they hit mobile platforms I think it'll be unstoppable, and in the meantime whatever you can do in Tauri you could probably translate to Ionic.
I myself have come across moments where some rtti/reflection would have been useful. In those cases I was often able to use branded types. Having something like that built into the language might be nice. But I'd also support TypeScript and JavaScript developers making the choice not to support it ever. IME, working around rtti type code often forces the programmer to come up with a much better approach.
The run-time reflection approach is good in one way: it doesn't add tooling to the project. All the modules that use serialization have to make a bunch of tedious API calls to build the type object which represents the C structure. This is created once and stashed in a global variable. Then it is used as a parameter when serializing and deserializing.
There is a performance impact because the marshaling code is interpreting the type object; it recursively walks the type object, and in parallel it walks the C object to extract or stuff material.
A generative approach would just write a serialization and deserialization stub. There would be no need for any type object to be walked at run-time. No need to construct such objects at startup and no need to carry the library for that.
But there would be some tool which itself has to be compiled (for the build machine, not the embedded targets), and then some Makefile steps to run that tool on some interface files. The thought of inflicting that one the project made me go yuck.
A third possibility is to have the run-time type info objects, and add JIT. Why do something easy, like a code generation tool called out of Makefile, when you can do something hard and nonportable?
For validation, ORMs, APIs, etc., once you move beyond the simplest cases, you need more information than is present in Typescript type information. And that's before we get to the app-specific concerns.
So you're going to end up with schemas, boiler-plate, code-generators, and/or glue code anyway. Not to mention the libraries to help manage this stuff.
It's not that it's completely unhelpful, but I think it's a partial solution, and not the tricky part either.
One of the things I don't love about Rust is how type inference affects program behavior in ways that can be really subtle. In Rust's case this is a necessary evil because it doesn't have a dynamic foundation, but TypeScript has done great without that compromise
TypeScript is syntactic expansion layer over JavaScript.
"C preprocessor, please give me arrays that know how big they are at run-time. Oh, and access to the calling function's local variables!"
"Common Lisp defmacro, give me continuations usable anywhere!"
A macro layer can bring you the pie in the sky, but only (1) at some nonozero cost and (2) with additional representations that are not understood by regular code that is not in that framework.
Suppose a TypeScript type object is attached to every run-time object created in TypeScript. Firstly, those objects become more bloated and expensive to construct. [Edit: not really: all objects of the same type can have a pointer to the same meta-data which is created once]. They will need run-time support in their execution environment in order to have those type representations. Objects not created by TypeScript-generated code will not have anything like that attached to them, so places in the system where the two domains interoperate won't be able to rely on reflection; it will need a fallback for objects that don't do reflection.
I think serialization can be done without reflection. Because at the time when the static language is being processed, you could annotate certain types as requiring serialization. Then for those types, TypeScript would generate the marshaling routines.
Generating marshaling stubs from an interface language has been done in the C world for decades. It doesn't require any run-time types. The generated marshaling stubs just know how to walk objects of the type that they handle, and that's it.
It looks like in TypeScript, serialization is just punted to JSON, which is inadequate because when we are deserializing, we want to check that the JSON blob has a type and shape compatible with the TypeScript-level type. (Or even for that that type to be inferred in some way.) There are some libraries that try to do something in this direction like ts-serializer.
I think it's something you really want in TypeScript itself.
Basically round up the half-dozen or so use cases for reflection, and provide for all of them somehow without actual reflection. It's an X/Y problem. People really want to do Y (e.g. serialization), and believe that they must first solve X (have metadata in objects for reflection).
Which means we can have dataclass, pydantic, typer and fastapi all generating their stuff from regular type hints. No need for special syntax or functions. And that's super nice.
1. A way to get a value that represents the type of any statically known type (i.e. known at compile time). 2. A way to compare two typereps for equality. 3. A way to convert between types if the typereps are equal.
This is basically the equivalent of the `Typeable` class in Haskell and PureScript (https://hackage.haskell.org/package/base/docs/Data-Typeable....). Both Haskell and PureScript erase types at runtime, so it is possible to do without adding a runtime to TypeScript as well.
Edit: Actually this is the first result, I hadn't tried those exact terms. It's a bit hairy though, which is why the unofficial typescript-language-server npm package wraps it. https://github.com/microsoft/TypeScript/wiki/Standalone-Serv...
... 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?"
My litmus test regarding whether I can even consider using a library in production is: does it have more stars than fartscroll.js?
https://github.com/theonion/fartscroll.js/tree/master
Most of the entries there are below that number, which begs the question: is this really that much of a problem that it mandates the drastic changes required?
I actually don't know if it's even doable, considering TS's structural type system, where the answer to the question "what type is X?" is not straightforward.
It still wouldn’t be runtime typing, the compiler would just insert a constant wherever you use such a macro so I don’t think it would conflict with typescript’s goals. But it would make it a lot easier to build extra checks when deserializing data - or just give richer debug information.
But it would probably be hard for eg esbuild to support such a feature if tsc adds it. So I couldn’t use it anyway :)
Seems like a huge waste.
If only ECMAScript had a native macro system, TypeScript could be just a library - and I would have zero problems with its existence.
You're probably familiar with the following anecdote:
>Eich originally joined intending to put Scheme "in the browser",[4] but his Netscape superiors insisted that the language's syntax resemble that of Java.
JavaScript became the language that we all love to hate due to political, not technical reasons. Yet people look at me funny when I call out the TS/React monoculture as the blatant corporate power grab that it is.
If ECMAScript had macros, page load times would skyrocket. ECMAScript and/or browsers would have to define a way to distinguish JS-with-macros files and embedded scripts from plain old JS that doesn't require expansion.
Any JS code bases with complicated macros that take time and memory to expand would have to be expanded by the developer and shipped expanded. So, back to the same model as TypeScript.
>So, back to the same model as TypeScript.
I beg to differ. There's a world of difference between:
1. a standardized feature with an official spec, which is subject to debate among the community, and of which it's viable to have multiple competing implementations; vs
2. a proprietary product that presents itself to be a superset of the core language (but isn't), is peddled by a single multinational, has a single implementation designed by an unaccountable elite in the employ of said multinational, which just so happens to be the original Dumbing Down The Computer Company
>If ECMAScript had macros, page load times would skyrocket.
>ECMAScript and/or browsers would have to define a way to distinguish JS-with-macros files and embedded scripts from plain old JS that doesn't require expansion.
If you introduce them today by way of a polyfill, maybe. I'm not necessarily advocating for introducing native macros to ECMA-262 at the present juncture. But I can't help speculating what would've happened if they had caught on.
If they were introduced at the point in history when people were first realizing transpilers were a thing; or designed into the language from the start; or a pre-existing metaprogramming-aware language was used in browsers, instead of Eich designing in 10 days an entire new language under the constraint that it also has to be an ad for Java - who knows where we would be as a civilization? What do you think?
It could be, but maybe the use cases for that can be solved in another way that don't require the type system at run-time.
The good news is that static type is, well, static. All the objects of the same type can share a pointer to the same type metadata. The overhead is thus not necessarily huge: one extra property to initialize when an object is created.
The generated TS code has to carry the run-time support routines for the type stuff though.
IF typescript was 100% its own thing and not built on top of JS, it would make complete sense to do it, but with a js engine below it...
He sometimes (used to?) streams himself working on twitch and it's a really comfy place to hang out.[2]
Right now a lot of work seems to be going into getting a 1.0 release out of the door (the current one is still marked alpha).
Our JavaScript bundles are not large enough or slow enough. Could you please make it so we can ship even more data to the client and add more branching so we can give our customers an even worse experience.
You want reflection, use a language that has it and ship webassembly to the client, it will likely be significantly more performant than adding even more bloat to what is already needing to run in the JS interpreter.
No thanks! If you want this, compile java to JS or something equally hamfisted…
My use case isn’t particularly outlandish, I can even imagine it being non-niche if I ever get around to publishing it. But it’s also pretty far afield from any of the existing solutions: platform-agnostic documentation as a core/foundational principle.
My original work implemented JSON Schema documentation on top of io-ts, and added some runtime and type level functionality to support that. But my vision for a hypothetical successor is that
- the documentation standard itself (whether JSON Schema, OpenAPI, or any other underlying format) should be the underlying primitive
- the underlying format should be composable to produce APIs which are just as user friendly (ie users shouldn’t have to muck around with the doc format unless they have a really specific use case, and even then they should still be able to compose the parts they’re not concerned with)
- no additional build time codegen tooling: define a schema once, its type is inferrable from the definition without a compiler extension or IDE config, its documentation is a plain function call executable in any standard runtime to resolve what’s composed
This is all very achievable in TypeScript as-is. But it’s way out of scope from what I imagine any first class thing would or should be. And sure, if such first class thing existed, that wouldn’t make my thing any less achievable. But here’s what I think it would do:
1. Disincentivize usage by users who prefer the first class thing with type syntax as the primary authoring mechanism.
2. Incentivize me to cave on tooling to accommodate that.
3. Piss people off because “we wanted less tooling not more”.
4. Recurse into this same debate.
I’d personally prefer the status quo. Even if that means rehashing the same debate every few months, at least it’s at a recursion depth that’s manageable and doesn’t have countless other sets of unintended consequences.
It also demonstrates that what is being asked for is actually practical.
[1]https://raganwald.com/2014/04/10/mixins-forwarding-delegatio...
One needs to define their types as a const, like this one:
``` [{ type: Number, name: "field1" }, { type: String, name: "field2" }] as const ```
and then use Typescript magic to convert it into the fully fledged Typescript type.
Yes, it's annoying, but it's more flexible.
To anyone who works on typescript/JavaScript outside the context of a web browser, you DO NOT matter as far as I am concerned. If I was in control of JavaScript/typescript, I’d give zero attention to your demands. You are not my top priority. Go away.
I feel like we are losing focus here. Should JavaScript be an all purpose language? Yes. Should we focus on making a web browser context, also yes.
The reason I led with this is that I think it is up to the JavaScript folks and the web browser vendors to include support for this before typescript can change what it emits. Ideally, I’d say wait a couple of years after browser vendors include support to implement this in typescript.