6 ms·

Instead of focusing on what TS does not, focus on what it does. TypeScript is not sound; JavaScript isn’t either. The first one will catch some type errors, th

Instead of focusing on what TS does not, focus on what it does. TypeScript is not sound; JavaScript isn’t either. The first one will catch some type errors, the second will catch none. Syntax highlighting, linting, testing, and now type checking: every step can make you more confident about the code you ship, before it even hits the browser. You can forgo using any help and probably you’ll code faster, but, again, you lose confidence.

lucisferre 7y ago
Tests are the only thing that give me confidence about any code I write, Javascript or otherwise.
- jsight 7y ago
  And compilers are effectively a rudimentary form of test. They are not sufficient, nor necessary but they do validate some basic assumptions about the code.
  - mixedCase 7y ago
    They also remove redundant testing (you only need to prove something fulfills certain properties once as long as you have a type for it); and the more advanced the type system the fewer tests needed.
    - valand 7y ago
      friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
      - paulcowan1970 7y ago
        I mention io-ts https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts in the post
        valand 7y ago
        Thanks for the article It sparked useful discussion around the world
  - valand 7y ago
    I would upvote you twice if I can for that compiler is a test thing
  - thrower123 7y ago
    If for no other reason, I would like Typescript for flagging when you typo some property - e.g. foo.FooID vs foo.FooId. I've lost a stupid amount of time in regular JS because of things like this that make me want to pick up the computer and throw it out the window.
    - valand 7y ago
      Decent editor does that now. I'm using atom on daily basis and it's helping me with that. VScode and intellij does the same
      - dragonwriter 7y ago
        Doesn't the functionality for that in most editors leverage typescript typings, so that it's not really independent of typescript?
        valand 7y ago
        Ah I misread the parent comment. I thought it was more like "I wish typescript has this anti-typo functionality" You're right that it's not independent from TS.
    - amatecha 7y ago
      you can add JSDoc annotations and use a modern IDE like vscode or webstorm, etc.
- Matthias247 7y ago
  Tests only help if they are written, and if they cover the code in question. Both of things are unfortunately not always given. If things are not covered by tests type systems are still better than nothing.
- mirekrusin 7y ago
  It's not just about confidence. It's also about the speed you can use/refactor the code. Suggestions, type information on hover and instant feedback if you forgot, used wrong order or type, misspelled or simply don't remember exactly signatures or auto generated documentation means a lot when writing code. You can move much faster when working on typed code. Nobody ever claimed that types are replacement for tests. It just means that your tests don't require obvious clutter anymore, you can focus on more complex/important test cases to cover.
spoiler 7y ago
FlowType has better soundness than TypeScript. I like to think of TypeScript as a "feelgood" typesystem (especially how it handles predicate functions, type variance in function arguments, and type casts). The only downside is that Flow's typesystem is volatile. You _might_ find it painful to upgrade between versions. With that being said, I still prefer Flow. Not sure how relevant this is, but at my company we mostly write Flow in the teams. For libraries I tent to provide both (code being written in flow, with with .d.ts provided). I also maintain both 3rdparty ts and flow type defs. TS tooling blows Flow out of the water, though. But, I've heard flow team at facebook is focusing a bit more on DX and on making the typesystem a bit more ergonomic and expressive. :)
- ng12 7y ago
  > TS tooling blows Flow out of the water, though This is the dealbreaker. Building Flow in OCaml was a mistake, full stop. I'm not convinced the level of soundness we're talking about is important except for the people who like to wax philosophical about PL theory. TypeScript has never been "unsound" in a way I actually care about and I would argue if you get caught up in a soundness issue you're already doing something completely crazy.
  - mirekrusin 7y ago
    It's true that ocaml has different contribution entry profile. The only "issue" here is that flow being a js tool, naturally would attract more js contributions, but that's it. You can't say ocaml itself is not fit for purpose because this kind of tool is pefect use case for ocaml. It would be interesting to see flow rewrite in flow itself thought.
    - ng12 7y ago
      It being written in OCaml is why the tooling is poor. TypeScript integrates perfectly with most build tooling (e.g. Webpack) because it's just JavaScript like every other tool. To run Flow everything has to be shelled out to an external bin which adds a lot of flakiness and manual configuration if you want to integrate it with your build config. I understand OCaml is great for writing meta languages (ha) but it's bad for the end user.
hajile 7y ago
Javascript is dynamically typed -- that does not mean it has no types. You are free to add dynamic type checks anywhere you want. I view these as critical for APIs even if you decide to use typescript. I also view them as critical for third-party interfaces where you may not be able to test integrations completely.

lucisferre 7y ago

Tests are the only thing that give me confidence about any code I write, Javascript or otherwise.

jsight 7y ago
And compilers are effectively a rudimentary form of test. They are not sufficient, nor necessary but they do validate some basic assumptions about the code.
- mixedCase 7y ago
  They also remove redundant testing (you only need to prove something fulfills certain properties once as long as you have a type for it); and the more advanced the type system the fewer tests needed.
  - valand 7y ago
    friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
    - paulcowan1970 7y ago
      I mention io-ts https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts in the post
      - valand 7y ago
        Thanks for the article It sparked useful discussion around the world
- valand 7y ago
  I would upvote you twice if I can for that compiler is a test thing
- thrower123 7y ago
  If for no other reason, I would like Typescript for flagging when you typo some property - e.g. foo.FooID vs foo.FooId. I've lost a stupid amount of time in regular JS because of things like this that make me want to pick up the computer and throw it out the window.
  - valand 7y ago
    Decent editor does that now. I'm using atom on daily basis and it's helping me with that. VScode and intellij does the same
    - dragonwriter 7y ago
      Doesn't the functionality for that in most editors leverage typescript typings, so that it's not really independent of typescript?
      - valand 7y ago
        Ah I misread the parent comment. I thought it was more like "I wish typescript has this anti-typo functionality" You're right that it's not independent from TS.
  - amatecha 7y ago
    you can add JSDoc annotations and use a modern IDE like vscode or webstorm, etc.
Matthias247 7y ago
Tests only help if they are written, and if they cover the code in question. Both of things are unfortunately not always given. If things are not covered by tests type systems are still better than nothing.
mirekrusin 7y ago
It's not just about confidence. It's also about the speed you can use/refactor the code. Suggestions, type information on hover and instant feedback if you forgot, used wrong order or type, misspelled or simply don't remember exactly signatures or auto generated documentation means a lot when writing code. You can move much faster when working on typed code. Nobody ever claimed that types are replacement for tests. It just means that your tests don't require obvious clutter anymore, you can focus on more complex/important test cases to cover.

spoiler 7y ago

FlowType has better soundness than TypeScript. I like to think of TypeScript as a "feelgood" typesystem (especially how it handles predicate functions, type variance in function arguments, and type casts). The only downside is that Flow's typesystem is volatile. You _might_ find it painful to upgrade between versions. With that being said, I still prefer Flow. Not sure how relevant this is, but at my company we mostly write Flow in the teams. For libraries I tent to provide both (code being written in flow, with with .d.ts provided). I also maintain both 3rdparty ts and flow type defs. TS tooling blows Flow out of the water, though. But, I've heard flow team at facebook is focusing a bit more on DX and on making the typesystem a bit more ergonomic and expressive. :)

ng12 7y ago
> TS tooling blows Flow out of the water, though This is the dealbreaker. Building Flow in OCaml was a mistake, full stop. I'm not convinced the level of soundness we're talking about is important except for the people who like to wax philosophical about PL theory. TypeScript has never been "unsound" in a way I actually care about and I would argue if you get caught up in a soundness issue you're already doing something completely crazy.
- mirekrusin 7y ago
  It's true that ocaml has different contribution entry profile. The only "issue" here is that flow being a js tool, naturally would attract more js contributions, but that's it. You can't say ocaml itself is not fit for purpose because this kind of tool is pefect use case for ocaml. It would be interesting to see flow rewrite in flow itself thought.
  - ng12 7y ago
    It being written in OCaml is why the tooling is poor. TypeScript integrates perfectly with most build tooling (e.g. Webpack) because it's just JavaScript like every other tool. To run Flow everything has to be shelled out to an external bin which adds a lot of flakiness and manual configuration if you want to integrate it with your build config. I understand OCaml is great for writing meta languages (ha) but it's bad for the end user.

hajile 7y ago

Javascript is dynamically typed -- that does not mean it has no types. You are free to add dynamic type checks anywhere you want. I view these as critical for APIs even if you decide to use typescript. I also view them as critical for third-party interfaces where you may not be able to test integrations completely.