I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
Announcing TypeScript 2.2
21–30 of 123 posts
Re: Announcing TypeScript 2.2
#22Woo :) whenever I have to work with an old javascript code base now I always add typings to it first. It makes it orders or magnitude easier to work with and refactor after that.
Re: Announcing TypeScript 2.2
#23Crumbles from the design-table. Oh look, a new object type. I'm not even sure this is an improvement to straight JS any more, it just fails in more exotic ways from pretending to be something it isn't. Once the choice is made to compile to JS, there are plenty of real languages to choose from.
I don't think you're familiar with what TypeScript is trying to achieve. It's not supposed to be another language entirely, but a standards-compatible type-safe version.
Re: Announcing TypeScript 2.2
#24I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
Why would flow + es6 be better?
Re: Announcing TypeScript 2.2
#25My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Can you show a few examples of where this is useful?
You can read the proposal and discussion around the feature on the github suggestion page for this feature.
The initial suggestion was made because there are certain functions in JavaScript that expect a non-primitive type in order to function. Such as Object.create, Object.getPrototypeOf, etc. Previous to this there was no way to model the functions with type safety, such that a developer would be prevented from accidentally sending a primitive value into those functions. This is because Typescript doesn't have the ability to say "Any type except X, Y and Z". So a new type was needed for this.
Re: Announcing TypeScript 2.2
#26Earlier quoted context omitted.
No, object is not a nullable type. For your code to work, you'd need to run it with strictNullChecks disabled. That's probably what you're doing, since it's the default.
since it's the default. It's not the default for the command line compiler. Also, all types (except Any/null/undefined) are non-nullable under that option, so that's not what makes object special (it's the no primitive types that is important). >tsc test.ts >tsc test.ts --strictNullChecks > test.ts(3,1): error TS2322: Type 'null' is not assignable to type 'object'.
> you'd need to run it with strictNullChecks disabled. That's probably what you're doing, since it's the default
I think you misinterpreted my reply. I meant the default is off. That's what your code shows.
Re: Announcing TypeScript 2.2
#27I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
Why would flow + es6 be better?
Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
Re: Announcing TypeScript 2.2
#28Earlier quoted context omitted.
since it's the default. It's not the default for the command line compiler. Also, all types (except Any/null/undefined) are non-nullable under that option, so that's not what makes object special (it's the no primitive types that is important). >tsc test.ts >tsc test.ts --strictNullChecks > test.ts(3,1): error TS2322: Type 'null' is not assignable to type 'object'.
> you'd need to run it with strictNullChecks disabled. That's probably what you're doing, since it's the default I think you misinterpreted my reply. I meant the default is off. That's what your code shows.
I did, sorry about that.
Re: Announcing TypeScript 2.2
#29Earlier quoted context omitted.
Why would flow + es6 be better?
Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
Also, you can progressively opt in to add typing information, while still getting most of the benefits without.
Re: Announcing TypeScript 2.2
#30I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
Why would flow + es6 be better?
One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.