4 ms·

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static checking doesn't benefit end users. When I go to my bank's website, if their front-end code has a type error, it's not like I can fix it right then and there. The type system is mostly a developer-time feature, so it makes sense to leave it out of the core runtime environment. In other words, think of JavaScript/ECMAScript more like the architecture that browsers support. That needs to be slow-moving since it's deployed across billions of devices. TypeScript then just targets that. Adding TypeScript directly to JavaScript would improve the world to about the same degree that adding C++ features directly to x64 machine code would.

The_rationalist 5y ago
You are totally missing the point of reified generics and reflection.
moron4hire 5y ago
This is not true. There are a number of ways that TypeScript's type-checking can be subverted at runtime, particularly when dealing with APIs that return JSON. You have to trust that the API has returned exactly what you are expecting, or write your own very detailed validation scripts. It's similar to the sorts of testing one would do in vanilla JavaScript without TypeScript, but now executing all the time at runtime. As a developer, in the case of an API change that violated my assumptions, I would personally prefer my applications to fail-hard at the point of the API call, rather than to have my scripts run merrily on and only error in some other code far away from the root-cause when one of those assumptions fails. However, I have a lot of hope that runtime type checking based on auto-code generation around TypeScript's interfaces could be developed in a future version of TypeScript.
- kipple 5y ago
  This would be a big (but exciting) departure from the current TS goal of "Impose no runtime overhead on emitted programs." [1] Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard). [1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zod https://github.com/colinhacks/zod
  - moron4hire 5y ago
    Zod looks super cool. I'll have to check it out in depth.
- munificent 5y ago
  TypeScript is an optionally typed language. It's core to the design of the language that the static type system is purely statically typed and doesn't come into play at runtime. You could argue that that's not the best kind of language for users. I wouldn't disagree. I work on Dart which used to be optionally typed but now has a fully sound type system with runtime checks. But that's orthogonal to whether browsers should support TypeScript directly. If they supported a statically typed language that had the runtime checks to be sound, that might be a great language, but it wouldn't be TypeScript.
  - moron4hire 5y ago
    That's a strangely puritanical viewpoint. I wouldn't say it's core to the design of the language. I'd say it's a key design decision for the development of the compiler, but those are two different things. Also, I don't understand what you mean by "it wouldn't be TypeScript". Languages change. They change all the time. Did adding nullish coallescing before it became availalbe in JavaSciprt? It's also not true that TypeScript is purely static and doesn't have any runtime component. There are a bunch of helper sort of functions that TypeScript can optionally include, so there is some precedent for having runtime-oriented code generated by TypeScript, rather than just eliding type information after successful static checking. So perhaps there could be a syntax for imposing runtime-checking as an optional element. Something like: interface Point { x: number; y: number; } async function getPointFromAPI(): Promise<Point> { const request = await fetch("/api/points/current"); const point = await request.json<Checked<Point>>(); return check point; } Type `Checked<T>` would signal to the compiler that type information for T needs to be made available at runtime, and the `check` keyword would perform the check and "unwrap" the type to a bare reference to T. I don't know what it would look like, but it would be a huge value add.
spankalee 5y ago
This is also why Deno running TypeScript directly is a bad idea.
- Soremwar 5y ago
  They don't though. They transpile it behind the scenes
  - spankalee 5y ago
    Same thing with the same problems. The difference being that Deno isn't going to have the same no-breaking-changes policy that the web does.
- munificent 5y ago
  The difference is a that a developer has a lot more control over what version of Deno their server-side app runs on than they do what version of a browser their client-side app runs on.
  - spankalee 5y ago
    This isn't really true in the wider ecosystem. Yes, the app developer does, but the library developer does not. As Deno adopts newer versions of TypeScript and config options libraries can fail to compile. This is compounded by the lack of a package manager so that references to specific versions and CDNs are hardcoded into dependents. All with essentially no benefit over running plain JS with associated typings.

The_rationalist 5y ago

You are totally missing the point of reified generics and reflection.

moron4hire 5y ago

This is not true. There are a number of ways that TypeScript's type-checking can be subverted at runtime, particularly when dealing with APIs that return JSON. You have to trust that the API has returned exactly what you are expecting, or write your own very detailed validation scripts. It's similar to the sorts of testing one would do in vanilla JavaScript without TypeScript, but now executing all the time at runtime. As a developer, in the case of an API change that violated my assumptions, I would personally prefer my applications to fail-hard at the point of the API call, rather than to have my scripts run merrily on and only error in some other code far away from the root-cause when one of those assumptions fails. However, I have a lot of hope that runtime type checking based on auto-code generation around TypeScript's interfaces could be developed in a future version of TypeScript.

kipple 5y ago
This would be a big (but exciting) departure from the current TS goal of "Impose no runtime overhead on emitted programs." [1] Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard). [1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zod https://github.com/colinhacks/zod
- moron4hire 5y ago
  Zod looks super cool. I'll have to check it out in depth.
munificent 5y ago
TypeScript is an optionally typed language. It's core to the design of the language that the static type system is purely statically typed and doesn't come into play at runtime. You could argue that that's not the best kind of language for users. I wouldn't disagree. I work on Dart which used to be optionally typed but now has a fully sound type system with runtime checks. But that's orthogonal to whether browsers should support TypeScript directly. If they supported a statically typed language that had the runtime checks to be sound, that might be a great language, but it wouldn't be TypeScript.
- moron4hire 5y ago
  That's a strangely puritanical viewpoint. I wouldn't say it's core to the design of the language. I'd say it's a key design decision for the development of the compiler, but those are two different things. Also, I don't understand what you mean by "it wouldn't be TypeScript". Languages change. They change all the time. Did adding nullish coallescing before it became availalbe in JavaSciprt? It's also not true that TypeScript is purely static and doesn't have any runtime component. There are a bunch of helper sort of functions that TypeScript can optionally include, so there is some precedent for having runtime-oriented code generated by TypeScript, rather than just eliding type information after successful static checking. So perhaps there could be a syntax for imposing runtime-checking as an optional element. Something like: interface Point { x: number; y: number; } async function getPointFromAPI(): Promise<Point> { const request = await fetch("/api/points/current"); const point = await request.json<Checked<Point>>(); return check point; } Type `Checked<T>` would signal to the compiler that type information for T needs to be made available at runtime, and the `check` keyword would perform the check and "unwrap" the type to a bare reference to T. I don't know what it would look like, but it would be a huge value add.

spankalee 5y ago

This is also why Deno running TypeScript directly is a bad idea.

Soremwar 5y ago
They don't though. They transpile it behind the scenes
- spankalee 5y ago
  Same thing with the same problems. The difference being that Deno isn't going to have the same no-breaking-changes policy that the web does.
munificent 5y ago
The difference is a that a developer has a lot more control over what version of Deno their server-side app runs on than they do what version of a browser their client-side app runs on.
- spankalee 5y ago
  This isn't really true in the wider ecosystem. Yes, the app developer does, but the library developer does not. As Deno adopts newer versions of TypeScript and config options libraries can fail to compile. This is compounded by the lack of a package manager so that references to specific versions and CDNs are hardcoded into dependents. All with essentially no benefit over running plain JS with associated typings.