Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.0 Beta

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

11–20 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#11

Post by kagia »

oblio wrote: post #8
knocte wrote: post #3

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.

Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.

I feel that typescript being only 2.0, should be in a position to break things once in a while.

If you pay too much attention to keeping legacy code 'alive' you end up complicating matters with either compiler-flags all over the place or redundant API's i.e win32 api (old+new+newer versions of the same function).

Re: Announcing TypeScript 2.0 Beta

#12

Post by jsheard »

jensvdh wrote: post #5

This is fantastic. Kind of gutted they delayed Async/Await until Typescript 2.1 releases. That's the one killer feature I'm missing. Typescript has been nothing short but amazing though!

In the meantime you can use async with TypeScripts ES6 emitter, which transforms async into generators, then run the output through Babel to transform the generators into plain old ES3/ES5. It's messy but it works.

Re: Announcing TypeScript 2.0 Beta

#13

Post by DougBTX »

nathancahill wrote: post #6
statictype wrote: post #2

The control-flow analysis of types is very clever. I've been slowly switching away from Coffeescript to Typescript and have been mostly happy with it. Only thing I still struggle with is grappling the namespace/modules mess in Javascript that's been inherited by Typescript.

Is it inherited from JS though? I was under the impression that Typescript was doing their own thing (like /// <reference)

TypeScript picked up a few features that were ultimately removed from JS at the draft spec stage, AFAIK the xml style references were never in a JS spec, but the convention has been around a while. TS also supports import etc.

Re: Announcing TypeScript 2.0 Beta

#14

Post by knocte »

Analemma_ wrote: post #9
knocte wrote: post #3

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.

It's a tough call, and I can see arguments for both sides. On the other side, one of the big selling points of TypeScript is that you can take your existing huge JavaScript codebase, and with little effort turn it into TypeScript with all the types being "any", then gradually add strong types as time permits. This wouldn't work if --strictNullChecks was the default and would add one more step to the migration process…

> and with little effort turn it into TypeScript

Good point, but then how about an opt-out warning (instead of error)?

Re: Announcing TypeScript 2.0 Beta

#15

Post by jameslk »

> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0]

Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers?

0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...

Re: Announcing TypeScript 2.0 Beta

#16

Post by kcorbitt »

Analemma_ wrote: post #9
knocte wrote: post #3

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.

It's a tough call, and I can see arguments for both sides. On the other side, one of the big selling points of TypeScript is that you can take your existing huge JavaScript codebase, and with little effort turn it into TypeScript with all the types being "any", then gradually add strong types as time permits. This wouldn't work if --strictNullChecks was the default and would add one more step to the migration process…

I don't use TypeScript, but with Flow (which has always disallowed nulls in built-in and user-defined types by default), "null" is a subtype of "any", so that would still work. Is this not the case in TypeScript with --strictNullChecks?

Re: Announcing TypeScript 2.0 Beta

#18

Post by moosingin3space »

jsheard wrote: post #12
jensvdh wrote: post #5

This is fantastic. Kind of gutted they delayed Async/Await until Typescript 2.1 releases. That's the one killer feature I'm missing. Typescript has been nothing short but amazing though!

In the meantime you can use async with TypeScripts ES6 emitter, which transforms async into generators, then run the output through Babel to transform the generators into plain old ES3/ES5. It's messy but it works.

How hard is it to automate this and what impact on build times does it have?

Re: Announcing TypeScript 2.0 Beta

#19

Post by nathancahill »

DougBTX wrote: post #13
nathancahill wrote: post #6

Earlier quoted context omitted.

Is it inherited from JS though? I was under the impression that Typescript was doing their own thing (like /// <reference)

TypeScript picked up a few features that were ultimately removed from JS at the draft spec stage, AFAIK the xml style references were never in a JS spec, but the convention has been around a while. TS also supports import etc.

The thing that bugs me the most is the inconsistent implementation of default imports with ES6. Makes it hard to work with a lot of libraries.

Re: Announcing TypeScript 2.0 Beta

#20

Post by rattray »

spriggan3 wrote: post #10

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decor…

Agreed – this may now be my top reason not to use TypeScript (followed by inadequate inference / support for gradual typing, differences from Babel, and a few random features), which I would otherwise very much like to use.
Post reply on HN