6 ms·

> TypeScript's type system is over-complex since it tries to be a superset of JS. This is exactly why it got so popular, and TypeScript support in the JS ecosy

by dsnr 5y ago

> TypeScript's type system is over-complex since it tries to be a superset of JS. This is exactly why it got so popular, and TypeScript support in the JS ecosystem is so good. It's easy to just strip the TS metadata and you're left with working JS. This is why projects like esbuild managed to ship TS support so quickly (without type-checking). Good luck doing that with a new language. I for one am "all in" on TypeScript, with all its shortcomings it's just the best of both worlds, and so easy to get on board.

elevader 5y ago
And it works in both directions. You can "easily" (I mean, this is JS afterall so this heavily depends on the degree of toolchain hell chosen) move to the TS toolchain and rename your files to have the .ts extension and you have a valid TS project and benefit from the inferred types for your code. Type annotations can then be added later on as you go. And the syntax everybody already knows stays valid. This is a huge benefit compared to something like ReScript because it makes adoption really easy. With the obvious downside of not having nice features like pattern matching.
- kvathupo 5y ago
  I agree that TS eases the transition from JS, but I'd qualify your statement by saying it's not the toolchain that's a source of headache. Ideally, one should compile TS with `--strict`, otherwise there's little difference with JS. With this in mind, it's quick and easy to switch to TS tooling. Afterwards, one can incrementally adopt stricter typing, culminating in adding `--strict` to your `tsconfig`. In reality, since `--strict` is false by default, I'm concerned people erroneously assume that their JS code is type-safe after the first step, when it really isn't. In other words, it's no different than JS, except in name only!
- _old_dude_ 5y ago
  The problem with the add types later approach is that in the end you have half baked .ts files left and right. And it becomes increasingly difficult to know when something compiles if it's because it's correct or because there is an any somewhere.
  - elevader 5y ago
    Yeah, agreed. Ideally this wouldn't happen like that. Temporary solutions like a half-migration have a tendency to stick around for a lot longer than anybody anticipates. But I think it is still better than not having any types at all, if only for having type information in development.
capableweb 5y ago
> 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.
ragnese 5y ago
TypeScript's biggest flaw, IMO, is that it can't (or chooses not to- I don't understand anything about JS-adjacent build systems and how they work) understand the difference between "code I write" and "code someone else wrote". I'm not going to beat the dead horse of how unsound TypeScript's type system is. We all know that most of that is intentional because it would just be too inconvenient to work with existing JavaScript code (Aside: think about what this implies about existing JavaScript code. This makes alarm bells go off in my head). However, why should I have to deal with an unsound type system in my new, fresh, TypeScript-only code? I'm not saying it's simple or criticizing anybody's work, but it would VASTLY increase my opinion of TypeScript if I could enable some kind of 'truly-strict-new-code' flag that would error on unsound code in the current project and maybe just warn when I call unsound code from a dependency. Because, honestly, I'm truly disappointed that the one language that finally has a chance to unseat JavaScript has such a poor type system that it can't even do basic sub-type variance correctly no matter how many flags you set. Out of all of the statically typed languages I've used, TypeScript has helped me the least when it comes to type errors.
- pcthrowaway 5y ago
  Is it even possible for the program to know at compile-time if the types will be violated at run-time? Even if you declare data from other sources 'not mine' this still seems like it would be impossible to do.
  - danenania 5y ago
    You can accomplish it with a library like zod[1]. It's not the prettiest though; first class support would definitely be better. 1 - https://github.com/colinhacks/zod https://github.com/colinhacks/zod
  - jayshua 5y ago
    The type system can force you to handle both cases - the data being in the expected & typed form, and the data not being in the expected form. You would have a function like this: parseJsonString : String -> Result Error Person Where Result is a value that is either an Error or a Person. To get the Person value out, the type system forces you to also do something with the Error if it exists. Not handling both possibilities in some way is a type error.
thegreatpeter 5y ago
ReScript supports Typescript types. Both consuming and generating them. Rescript also uses esbuild under the hood. Lots of great optimizations. If you're "all in" on TypeScript, you'll love Rescript. It's sooo much faster. Been using it for 3 years now.
- AkshitGarg 5y ago
  ReScript doesn't uses esbuild. It has its own compiler: https://github.com/rescript-lang/rescript-compiler https://github.com/rescript-lang/rescript-compiler
- rsrsrs86 5y ago
  Ocaml is so nice and fast! The very fast feedback you get from the compiler is amazing.
frou_dh 5y ago
>It's easy to just strip the TS metadata and you're left with working JS. This actually touches on one of ReScript's supposed unique selling points amongst the functional compile-to-JS languages. Namely that the JS its compiler generates is so clean and readable that, if you end up deciding you don't want to bother with ReScript any more, you can just take the output from the final time you ran the compiler and treat that as a plain JS codebase to continue working on. Exactly how true that is, I don't know.
pjmlp 5y ago
Same here, by being a tool to type annotate JavaScript, it kind of avoids the usual guest language problem.

by dsnr 5y ago

elevader 5y ago

And it works in both directions. You can "easily" (I mean, this is JS afterall so this heavily depends on the degree of toolchain hell chosen) move to the TS toolchain and rename your files to have the .ts extension and you have a valid TS project and benefit from the inferred types for your code. Type annotations can then be added later on as you go. And the syntax everybody already knows stays valid. This is a huge benefit compared to something like ReScript because it makes adoption really easy. With the obvious downside of not having nice features like pattern matching.

kvathupo 5y ago
I agree that TS eases the transition from JS, but I'd qualify your statement by saying it's not the toolchain that's a source of headache. Ideally, one should compile TS with `--strict`, otherwise there's little difference with JS. With this in mind, it's quick and easy to switch to TS tooling. Afterwards, one can incrementally adopt stricter typing, culminating in adding `--strict` to your `tsconfig`. In reality, since `--strict` is false by default, I'm concerned people erroneously assume that their JS code is type-safe after the first step, when it really isn't. In other words, it's no different than JS, except in name only!
_old_dude_ 5y ago
The problem with the add types later approach is that in the end you have half baked .ts files left and right. And it becomes increasingly difficult to know when something compiles if it's because it's correct or because there is an any somewhere.
- elevader 5y ago
  Yeah, agreed. Ideally this wouldn't happen like that. Temporary solutions like a half-migration have a tendency to stick around for a lot longer than anybody anticipates. But I think it is still better than not having any types at all, if only for having type information in development.

capableweb 5y ago

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

ragnese 5y ago

TypeScript's biggest flaw, IMO, is that it can't (or chooses not to- I don't understand anything about JS-adjacent build systems and how they work) understand the difference between "code I write" and "code someone else wrote". I'm not going to beat the dead horse of how unsound TypeScript's type system is. We all know that most of that is intentional because it would just be too inconvenient to work with existing JavaScript code (Aside: think about what this implies about existing JavaScript code. This makes alarm bells go off in my head). However, why should I have to deal with an unsound type system in my new, fresh, TypeScript-only code? I'm not saying it's simple or criticizing anybody's work, but it would VASTLY increase my opinion of TypeScript if I could enable some kind of 'truly-strict-new-code' flag that would error on unsound code in the current project and maybe just warn when I call unsound code from a dependency. Because, honestly, I'm truly disappointed that the one language that finally has a chance to unseat JavaScript has such a poor type system that it can't even do basic sub-type variance correctly no matter how many flags you set. Out of all of the statically typed languages I've used, TypeScript has helped me the least when it comes to type errors.

pcthrowaway 5y ago
Is it even possible for the program to know at compile-time if the types will be violated at run-time? Even if you declare data from other sources 'not mine' this still seems like it would be impossible to do.
- danenania 5y ago
  You can accomplish it with a library like zod[1]. It's not the prettiest though; first class support would definitely be better. 1 - https://github.com/colinhacks/zod https://github.com/colinhacks/zod
- jayshua 5y ago
  The type system can force you to handle both cases - the data being in the expected & typed form, and the data not being in the expected form. You would have a function like this: parseJsonString : String -> Result Error Person Where Result is a value that is either an Error or a Person. To get the Person value out, the type system forces you to also do something with the Error if it exists. Not handling both possibilities in some way is a type error.

thegreatpeter 5y ago

ReScript supports Typescript types. Both consuming and generating them. Rescript also uses esbuild under the hood. Lots of great optimizations. If you're "all in" on TypeScript, you'll love Rescript. It's sooo much faster. Been using it for 3 years now.

AkshitGarg 5y ago
ReScript doesn't uses esbuild. It has its own compiler: https://github.com/rescript-lang/rescript-compiler https://github.com/rescript-lang/rescript-compiler
rsrsrs86 5y ago
Ocaml is so nice and fast! The very fast feedback you get from the compiler is amazing.

frou_dh 5y ago

>It's easy to just strip the TS metadata and you're left with working JS. This actually touches on one of ReScript's supposed unique selling points amongst the functional compile-to-JS languages. Namely that the JS its compiler generates is so clean and readable that, if you end up deciding you don't want to bother with ReScript any more, you can just take the output from the final time you ran the compiler and treat that as a plain JS codebase to continue working on. Exactly how true that is, I don't know.

pjmlp 5y ago

Same here, by being a tool to type annotate JavaScript, it kind of avoids the usual guest language problem.