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

21–30 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#21

Post by Derander »

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…

TypeScript has dealt with this in the past by adapting to the introduction of `` from jsx, which clashed with typescript's casting operator. If this ends up being a problem I'm sure that the TypeScript team will just pick a different syntax.

In my experience, the overhead caused by TypeScript is far outweighed by benefits in tooling and confidence that my code works (mostly) after refactors.

Re: Announcing TypeScript 2.0 Beta

#22

Post by Derander »

moosingin3space wrote: post #18
jsheard wrote: post #12

Earlier quoted context omitted.

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?

It's not hard to automate with raw gulp or webpack, but it does add a significant amount of time to compilation. It roughly doubled our incremental compile times. My team decided it wasn't worth it, but it's possible that a cleverer person could decrease the overhead.

Re: Announcing TypeScript 2.0 Beta

#23

Post by smt88 »

moosingin3space wrote: post #18
jsheard wrote: post #12

Earlier quoted context omitted.

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?

It takes about 20 min. It's very easy to get TS to output ES6 (a single line in a config file). It's very easy to get Babel to output ES5 from ES6.

The only thing that might be time-consuming is setting your paths if you don't already have a plan for keeping things separate.

Re: Announcing TypeScript 2.0 Beta

#24

Post by smt88 »

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…

I don't plan to use that feature. If they remove or change it, my code will still work.

Re: Announcing TypeScript 2.0 Beta

#25

Post by bcherny »

rattray wrote: post #20
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.

This is a poor reason to not use TS.

If in the unlikely worst case scenario the TS team drops/renames the ! syntax at some point, given that these are compile time checks, you will just manually go through a list of compile time errors and fix the issues one by one.

More likely scenarios:

- They will make the change in a backwards-compatible way

- They will release a jscodeshift script to do the upgrade for you

- Etc.

Re: Announcing TypeScript 2.0 Beta

#26

Post by spankalee »

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…

AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://github.com/tc39/proposal-decorators/commit/c32ea1815...)

Even so, I've been pretty impressed with the TypeScript teams ability to manage this kind of change an uncertainty and keep up with and move closer to standard JavaScript where they have been differences.

Specifically regarding the `!` operator* , to convert to standard JavaScript just remove the `!` operator, like you would remove a cast or type annotation. It's still within the TypeScript spirit to me.

* I personally would have rather seen it either be a type of cast (maybe `strs.map(...);`), or add a null-safe property accessor: `strs?.map(...)` which doesn't assert that `strs` is non-null, but makes the expression null-safe, returning null if `strs` is null.

Re: Announcing TypeScript 2.0 Beta

#27

Post by ihsw »

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…

Do you have the same complaints about optional parameters too?

    let x = (id: number, name?: string) => { return; };
Is it abuse to use interfaces as well? They are not present in vanilla JS.

How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes?

Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse?

I won't even get into generics as that's a whole different can of worms.

Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time.

TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that.

[1] https://flowtype.org/

Re: Announcing TypeScript 2.0 Beta

#28

Post by bsimpson »

> In 2.0, we’ve started using control flow analysis to better understand what a type has to be at a given location.

Sounds like Flow. Curious to see how they converge/diverge over time.

I know there are people who hate the tooling spaghetti that modern JS development involves, but I appreciate that I can plug Flow into a babel/webpack stack and have it just do the error checking. I also have high hopes for things like tree shaking and its ilk that control flow analyzers (Flow, and now TypeScript) will bring to JS going forward.

I'm sure you could have Babel just do the experimental transforms and pipe the result into TypeScript, but having two separate sugar/transformation systems seems not-great.

Re: Announcing TypeScript 2.0 Beta

#30

Post by berns »

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…

Typescript is a superset of Javascript, but it it's not only Javascript plus types. Some features like async/await could end up being implemented differently in Ecmascript. It seems inevitable that there could be incompatibilities in the future. But the same happens with Babel or other transpilers when they introduce features that are not yet standardized.
Post reply on HN