5 ms·

Typescript is a truly great project, I'm not sure many people understand the amount of work that has gone into this compiler. They have the crazy constraint of

Typescript is a truly great project, I'm not sure many people understand the amount of work that has gone into this compiler. They have the crazy constraint of being 100% compatible with Javascript, which is a bit broken by design and yet they managed to make it so much better to work with TS than with JS. After trying Flow numerous times, I came to the conclusion it simply can't compete with the power of the team Microsoft put together. Even their alpha versions are stable enough to be used in production. Some advices: - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. - Use a noAny tslint rule. disable it on a case by case basis, only in util code. Most of the time, any is not necessary, often you can use {} or Object instead. - You can get away with just using undefined everywhere, null adds no value. - Use union types. Make impossible data combinations impossible to write! Example: export type RemoteData<D, E> = NotAsked | Loading | Refreshing<D> | Success<D> | Failure<E>

mercer 9y ago
> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. This is exactly what I did and it's the main reason I keep dropping TypeScript because I 'need to get shit done'! It's good advice though, and I would definitely advise new TypeScript users (especially those unfamiliar with type systems) to at least try it. But if it results in giving up and going back to just js, it might be worth going with the 'barely better' approach and only enable those flags if you're more comfortable with TypeScript.
- ash 9y ago
  strictNullChecks errors are easy to fix: 1. Add `| null` or `?` for things that could be null/undefined. 2. Start handling "is this thing null?" cases. In some occasions it could be annoying. E.g. when you are absolutely sure it's not null. E.g. in tests. TypeScript provides `!` operator for that: interface Baz { foo?: string; } let bar = (t: Baz) => // yes, I'm sure t.foo!.length; https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#non-null-assertion-operator https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
  - mercer 9y ago
    Good point! I was talking about noImplicitAny; strictNullChecks is worth the 'hassle' from the start.
    - ash 9y ago
      Why couldn't you use explicit `any` type when you 'need to get shit done'?
      - mercer 9y ago
        Mostly because it caused a huge list of error messages that I found difficult to get rid of. Some of it libraries, IIRC, and some of it my own code. Perhaps for some this would encourage them to one-by-one squash these messages, but in my case it made me go for what was familiar and not written in angry and red letters. I found it easier to introduce TypeScript from an opt-in perspective.
    - WorldMaker 9y ago
      Explicit any is usually also easy enough of a hassle to deal with: when you get a compiler complaint add an `: any` or `as any` somewhere and whatever necessary parentheses to scope that right. Optional: treat `: any` and `as any` as TODO or HACK markers to return to in the fullness of time (refactoring/fixing). Dealing with other people's modules has also gotten much easier in recent versions of Typescript. To define a module name as any-typed the boilerplate has shrunk to a bare minimum: declare module 'name-of-the-module' Even better, module names in recent Typescript versions accept wildcards: declare module 'some-big-node-library/**/*' declare module '**/*.css' declare module '**/*!text'
whatever_dude 9y ago
The new --strict option might come in handy too: https://blogs.msdn.microsoft.com/typescript/2017/04/10/announcing-typescript-2-3-rc/ https://blogs.msdn.microsoft.com/typescript/2017/04/10/annou...
azylman 9y ago
> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. It may be a good idea to add those flags for new projects, but if you're converting existing projects, that's just not feasible. Further, you can actually see huge benefits just from switching to the TypeScript compiler without any changes to your code. At my last company, we started switching to TypeScript just by running our large JavaScript codebases through the TypeScript compiler and installing type definitions [1] for the popular libraries we were using. While we were doing so, we started finding a lot of bugs in existing code that TypeScript was detecting for us automatically by inferring types from how we interacted with known libraries. [1] http://definitelytyped.org/ http://definitelytyped.org/
- jrhurst 9y ago
  What sort of bugs did you find? Were you able create replicate the regression from a user endpoint?
- deleted 9y ago
  [deleted]

mercer 9y ago

> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. This is exactly what I did and it's the main reason I keep dropping TypeScript because I 'need to get shit done'! It's good advice though, and I would definitely advise new TypeScript users (especially those unfamiliar with type systems) to at least try it. But if it results in giving up and going back to just js, it might be worth going with the 'barely better' approach and only enable those flags if you're more comfortable with TypeScript.

ash 9y ago
strictNullChecks errors are easy to fix: 1. Add `| null` or `?` for things that could be null/undefined. 2. Start handling "is this thing null?" cases. In some occasions it could be annoying. E.g. when you are absolutely sure it's not null. E.g. in tests. TypeScript provides `!` operator for that: interface Baz { foo?: string; } let bar = (t: Baz) => // yes, I'm sure t.foo!.length; https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#non-null-assertion-operator https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
- mercer 9y ago
  Good point! I was talking about noImplicitAny; strictNullChecks is worth the 'hassle' from the start.
  - ash 9y ago
    Why couldn't you use explicit `any` type when you 'need to get shit done'?
    - mercer 9y ago
      Mostly because it caused a huge list of error messages that I found difficult to get rid of. Some of it libraries, IIRC, and some of it my own code. Perhaps for some this would encourage them to one-by-one squash these messages, but in my case it made me go for what was familiar and not written in angry and red letters. I found it easier to introduce TypeScript from an opt-in perspective.
  - WorldMaker 9y ago
    Explicit any is usually also easy enough of a hassle to deal with: when you get a compiler complaint add an `: any` or `as any` somewhere and whatever necessary parentheses to scope that right. Optional: treat `: any` and `as any` as TODO or HACK markers to return to in the fullness of time (refactoring/fixing). Dealing with other people's modules has also gotten much easier in recent versions of Typescript. To define a module name as any-typed the boilerplate has shrunk to a bare minimum: declare module 'name-of-the-module' Even better, module names in recent Typescript versions accept wildcards: declare module 'some-big-node-library/**/*' declare module '**/*.css' declare module '**/*!text'

whatever_dude 9y ago

The new --strict option might come in handy too: https://blogs.msdn.microsoft.com/typescript/2017/04/10/announcing-typescript-2-3-rc/ https://blogs.msdn.microsoft.com/typescript/2017/04/10/annou...

azylman 9y ago

> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. It may be a good idea to add those flags for new projects, but if you're converting existing projects, that's just not feasible. Further, you can actually see huge benefits just from switching to the TypeScript compiler without any changes to your code. At my last company, we started switching to TypeScript just by running our large JavaScript codebases through the TypeScript compiler and installing type definitions [1] for the popular libraries we were using. While we were doing so, we started finding a lot of bugs in existing code that TypeScript was detecting for us automatically by inferring types from how we interacted with known libraries. [1] http://definitelytyped.org/ http://definitelytyped.org/

jrhurst 9y ago
What sort of bugs did you find? Were you able create replicate the regression from a user endpoint?
deleted 9y ago
[deleted]