11 ms·

> It's easy to just strip the TS metadata and you're left with working JS. Compared to what? JSDoc made it even easier, you didn't even need to strip anything,

> It's easy to just strip the TS metadata and you're left with working JS. Compared to what? JSDoc made it even easier, you didn't even need to strip anything, as the "types" were just comments. This comes with its own problems, who want to program with comments? But it didn't require any changes to use for us who want nothing to do with TS.

moonchrome 5y ago
What are the changes for people who don't want to use TS when they consume TS from JS ? The packages are shipped as JS with additional definitions. The stripping part is just a fallback option if you decide to move away from TS, you never actually use that in practice.
verve_rat 5y ago
If you don't want to use Typescript... then don't?
- capableweb 5y ago
  Yeah, duh. The argument is that there is a group of people who wants types and write libraries. Before they used JSDoc, which is effortless to use from JS, as it's just actually vanilla JS. Some of those started using TypeScript now for everything, including libraries. If I want to use those libraries, I need to fork the project and rewrite them to vanilla JS, something that was not needed before. Or find a different library/write it myself.
  - smt88 5y ago
    It sounds like you either don't use npm and are trying to use libraries' source files or you don't actually have this issue. This doesn't and can't happen with npm.
  - elevader 5y ago
    You actually don't, that's the nice part. NPM Typescript modules are shipped as transpiled js modules with d.ts files. Those d.ts files contain the type informations for consuming TS projects but they are completely optional and you can simply ignore them if you write a plain js project. You can see this in the babel project, for example. It is written in typescript but used by a lot of js projects that don't care (and don't have to care) about this.
  - mynegation 5y ago
    > If I want to use those libraries, I need to fork the project and rewrite them to vanilla JS Why? If you want to just use, npm packages give you “compiled” vanilla JS and type definition files that you can ignore. Alternatively you can compile them yourself, if you vendor them in.
Aldo_MX 5y ago
Comments have the potential to get forgotten and become incorrect. Type annotations not.
- cxr 5y ago
  Corollary: we should invest in systems that allow us to mechanically verify correctness of comments as readily as type checkers do with type specifiers.
ponyous 5y ago
> Good luck doing that with a new language. Compared to a new language...
datagram 5y ago
> who want to program with comments? TypeScript supports providing types via JSDoc comments[1]. This gets you use all the IDE language features you'd get using TS, including highlighting type errors. I actually use this all the time, since I have plenty of scripts that are complex enough that I want type checking but not complex enough to warrant a compilation step. There's also Google's Closure Compiler[2], which uses JSDoc for its JS type annotations. [1]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... [2]: https://developers.google.com/closure/compiler https://developers.google.com/closure/compiler

moonchrome 5y ago

What are the changes for people who don't want to use TS when they consume TS from JS ? The packages are shipped as JS with additional definitions. The stripping part is just a fallback option if you decide to move away from TS, you never actually use that in practice.

verve_rat 5y ago

If you don't want to use Typescript... then don't?

capableweb 5y ago
Yeah, duh. The argument is that there is a group of people who wants types and write libraries. Before they used JSDoc, which is effortless to use from JS, as it's just actually vanilla JS. Some of those started using TypeScript now for everything, including libraries. If I want to use those libraries, I need to fork the project and rewrite them to vanilla JS, something that was not needed before. Or find a different library/write it myself.
- smt88 5y ago
  It sounds like you either don't use npm and are trying to use libraries' source files or you don't actually have this issue. This doesn't and can't happen with npm.
- elevader 5y ago
  You actually don't, that's the nice part. NPM Typescript modules are shipped as transpiled js modules with d.ts files. Those d.ts files contain the type informations for consuming TS projects but they are completely optional and you can simply ignore them if you write a plain js project. You can see this in the babel project, for example. It is written in typescript but used by a lot of js projects that don't care (and don't have to care) about this.
- mynegation 5y ago
  > If I want to use those libraries, I need to fork the project and rewrite them to vanilla JS Why? If you want to just use, npm packages give you “compiled” vanilla JS and type definition files that you can ignore. Alternatively you can compile them yourself, if you vendor them in.

Aldo_MX 5y ago

Comments have the potential to get forgotten and become incorrect. Type annotations not.

cxr 5y ago
Corollary: we should invest in systems that allow us to mechanically verify correctness of comments as readily as type checkers do with type specifiers.

ponyous 5y ago

> Good luck doing that with a new language. Compared to a new language...

datagram 5y ago

> who want to program with comments? TypeScript supports providing types via JSDoc comments[1]. This gets you use all the IDE language features you'd get using TS, including highlighting type errors. I actually use this all the time, since I have plenty of scripts that are complex enough that I want type checking but not complex enough to warrant a compilation step. There's also Google's Closure Compiler[2], which uses JSDoc for its JS type annotations. [1]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... [2]: https://developers.google.com/closure/compiler https://developers.google.com/closure/compiler