7 ms·

> As TypeScript is a core part of the Deno ecosystem, we are also very interested in pushing for even closer alignment of TypeScript and JavaScript in the futur

> As TypeScript is a core part of the Deno ecosystem, we are also very interested in pushing for even closer alignment of TypeScript and JavaScript in the future. I've wondered why the frontend community hasn't gotten together and said, "The next version of JavaScript - is TypeScript!" I've been using TypeScript for five years professionally now and cannot understate how much easier it has made large frontend (not just Web, but mobile and desktop) projects. Surely enough thought and work has been put into TypeScript to make it the next standard.

conaclos 5y ago
TypeScript is still experimenting with its type system and it has numerous edge cases. I could be more in favor to specify and support a minimal subset of TypeScript rather than the entire TypeScript. Basically we could start by enabling type annotations, enum declarations, and type-aliases.
dcgudeman 5y ago
Because then ability for typescript to be agile would be destroyed. JavaScript can’t be changed as easily as typescript.
AprilArcus 5y ago
TypeScript is great and everything, but Microsoft owns the standard and the single functioning checker, and haven't published a specification or even a grammar.
- TimTheTinker 5y ago
  The TypeScript checker/compiler is Apache 2.0 licensed, so I'm not sure there's room to complain, unless you disagree with the direction they're taking the project: https://github.com/microsoft/TypeScript/blob/main/LICENSE.txt https://github.com/microsoft/TypeScript/blob/main/LICENSE.tx...
  - anderskaseorg 5y ago
    Nobody disputes that TypeScript is open source, but there’s still a vast difference between a single open-source implementation and a specification that’s suitable for standardization. The implementation inevitably has bugs, and there needs to be a way to decide which bugs are actually “features” that other implementations will need to emulate. (Here’s the specification for ECMAScript, for example: https://tc39.es/ecma262/ https://tc39.es/ecma262/) To be clear, I am not bashing Microsoft here—just pointing out a reason that TypeScript can’t be declared “the next version of JavaScript”, which is the context of this thread.
jollybean 5y ago
TS design goals and non-goals [1] It's very much designed to be a layer of abstraction over JS. I am as much a fan of TS, however, it's not likely ever going to be the thing that it's really close to being. [1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
msoad 5y ago
Types in TypeScript are great but if JavaScript ever wants to add types it has to be something like a real programming language types in which you can use types in runtime as well. Like in a catch clause I can assert the type of the error and do things with it once that assertion is done. Many other useful things when types space and runtime space are not totally separate. ES4 was the first shot at adding types to JavaScript which failed due to how big the ambitions were. I'm not sure if there is any more appetite for adding types to JS tho. In very very serious big applications like a 3D editor you can fall back to WebAssembly and use your favorite typed language. For smaller apps TypeScript is good enough. This way JavaScript stays simple and lean.
- bvaldivielso 5y ago
  "real programming language types" There are a few languages where types only exist (for the most part, though with exceptions and hacks here and there) at compile-time, like Rust, C++ or even Haskell IIRC.
- jonny_eh 5y ago
  > it has to be something like a real programming language It's a nice feature request but there's no one feature that makes a programming language "real".
- javajosh 5y ago
  *>...use types [at] runtime..." Two things. First, TS conceives of itself as having no runtime component. If it did, I think people (including the TS devs) would be more confused. Second, I'd say rather we need a runtime type system. In fact I've tried my hand at writing one in the most minimalist way possible, and have been working on it recently [1]. The type system is explicit in that a type is a JSON like object, similar to JSON schema, but 100x less code. [1] https://github.com/javajosh/simpatico/blob/master/friendly.html https://github.com/javajosh/simpatico/blob/master/friendly.h... This is effectively the test harness for the module.
- anderskaseorg 5y ago
  JS objects already have runtime types, and you can use them in catch clauses. try { … } catch (e) { if (e instanceof FooError) { … } else if (e instanceof BarError) { … } else { throw e; } } There was once a Mozilla extension (https://web.archive.org/web/20200111091805/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch#Conditional_catch-blocks https://web.archive.org/web/20200111091805/https://developer...) that allowed you to abbreviate the above to try { … } catch (e if e instanceof FooError) { … } catch (e if e instanceof BarError) { … } It was never standardized, but since it’s just syntactic sugar, if there were demand, it could be standardized without bringing in an entirely new type system. There would be at least two problems with using TypeScript types for this. Firstly, TypeScript types are unsound in a number of intentional and unintentional ways, meaning that it’s possible for the compile-time and runtime types to disagree, even in fully typed code. Secondly, TypeScript can express many types that cannot be tested at runtime; for example, there is no way to tell whether a function accepts a string as an argument, or to guess the inner type of an empty array.
jamil7 5y ago
Would expanding wasm capabilities be a better long term option here instead of supporting TS directly? Opening the browser up to a whole lot of languages, including Typescript (AssemblyScript exists already).
munificent 5y ago
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

conaclos 5y ago

TypeScript is still experimenting with its type system and it has numerous edge cases. I could be more in favor to specify and support a minimal subset of TypeScript rather than the entire TypeScript. Basically we could start by enabling type annotations, enum declarations, and type-aliases.

dcgudeman 5y ago

Because then ability for typescript to be agile would be destroyed. JavaScript can’t be changed as easily as typescript.

AprilArcus 5y ago

TypeScript is great and everything, but Microsoft owns the standard and the single functioning checker, and haven't published a specification or even a grammar.

TimTheTinker 5y ago
The TypeScript checker/compiler is Apache 2.0 licensed, so I'm not sure there's room to complain, unless you disagree with the direction they're taking the project: https://github.com/microsoft/TypeScript/blob/main/LICENSE.txt https://github.com/microsoft/TypeScript/blob/main/LICENSE.tx...
- anderskaseorg 5y ago
  Nobody disputes that TypeScript is open source, but there’s still a vast difference between a single open-source implementation and a specification that’s suitable for standardization. The implementation inevitably has bugs, and there needs to be a way to decide which bugs are actually “features” that other implementations will need to emulate. (Here’s the specification for ECMAScript, for example: https://tc39.es/ecma262/ https://tc39.es/ecma262/) To be clear, I am not bashing Microsoft here—just pointing out a reason that TypeScript can’t be declared “the next version of JavaScript”, which is the context of this thread.

jollybean 5y ago

TS design goals and non-goals [1] It's very much designed to be a layer of abstraction over JS. I am as much a fan of TS, however, it's not likely ever going to be the thing that it's really close to being. [1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

msoad 5y ago

Types in TypeScript are great but if JavaScript ever wants to add types it has to be something like a real programming language types in which you can use types in runtime as well. Like in a catch clause I can assert the type of the error and do things with it once that assertion is done. Many other useful things when types space and runtime space are not totally separate. ES4 was the first shot at adding types to JavaScript which failed due to how big the ambitions were. I'm not sure if there is any more appetite for adding types to JS tho. In very very serious big applications like a 3D editor you can fall back to WebAssembly and use your favorite typed language. For smaller apps TypeScript is good enough. This way JavaScript stays simple and lean.

bvaldivielso 5y ago
"real programming language types" There are a few languages where types only exist (for the most part, though with exceptions and hacks here and there) at compile-time, like Rust, C++ or even Haskell IIRC.
jonny_eh 5y ago
> it has to be something like a real programming language It's a nice feature request but there's no one feature that makes a programming language "real".
javajosh 5y ago
*>...use types [at] runtime..." Two things. First, TS conceives of itself as having no runtime component. If it did, I think people (including the TS devs) would be more confused. Second, I'd say rather we need a runtime type system. In fact I've tried my hand at writing one in the most minimalist way possible, and have been working on it recently [1]. The type system is explicit in that a type is a JSON like object, similar to JSON schema, but 100x less code. [1] https://github.com/javajosh/simpatico/blob/master/friendly.html https://github.com/javajosh/simpatico/blob/master/friendly.h... This is effectively the test harness for the module.
anderskaseorg 5y ago
JS objects already have runtime types, and you can use them in catch clauses. try { … } catch (e) { if (e instanceof FooError) { … } else if (e instanceof BarError) { … } else { throw e; } } There was once a Mozilla extension (https://web.archive.org/web/20200111091805/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch#Conditional_catch-blocks https://web.archive.org/web/20200111091805/https://developer...) that allowed you to abbreviate the above to try { … } catch (e if e instanceof FooError) { … } catch (e if e instanceof BarError) { … } It was never standardized, but since it’s just syntactic sugar, if there were demand, it could be standardized without bringing in an entirely new type system. There would be at least two problems with using TypeScript types for this. Firstly, TypeScript types are unsound in a number of intentional and unintentional ways, meaning that it’s possible for the compile-time and runtime types to disagree, even in fully typed code. Secondly, TypeScript can express many types that cannot be tested at runtime; for example, there is no way to tell whether a function accepts a string as an argument, or to guess the inner type of an empty array.

jamil7 5y ago

Would expanding wasm capabilities be a better long term option here instead of supporting TS directly? Opening the browser up to a whole lot of languages, including Typescript (AssemblyScript exists already).

munificent 5y ago

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