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

31–40 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#31

Post by spriggan3 »

ihsw wrote: post #27
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 c…

> let x = (id: number, name?: string) => { return; };

hmm, it would make more sense if it was written like that

> let x = (id: number, name: string?) => { return; };

But I guess it's more or less ok. But I definitely feel inconfortable with the ! .

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

I don't use React.

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

The probability is higher for ES to implement async/await than the ! operator. The former is a safe bet, the latter isn't, by a long shot.

> 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.

It means that language will break. Not very good if you write large TS codebases today.

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

That's your opinion. I'm not interested in Flow.

Ultimately TS is successful because it more or less looks like Action Script 3/ES4/JScript.net and javascript itself. Make it too Alien and the people who refused to use Coffee script because of its semantics will not want to use TS. And FYI I use TS today. I may reconsider that.

Re: Announcing TypeScript 2.0 Beta

#33

Post by ceronman »

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…

Being realistic, it might take more than a decade to see a standard EcmaScript version with type annotations available in all major browsers. Until then, transpiling is the only choice. So I don't think diverging from the (possible) standard is too bad. We don't know how the state of web development will be at that time, and probably the standar won't ever catch up with TypeScript and transpiling will be required for quite a long time until something like WebAssembly really takes off.

Re: Announcing TypeScript 2.0 Beta

#35

Post by moosingin3space »

Derander wrote: post #22
moosingin3space wrote: post #18

Earlier quoted context omitted.

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.

I ask because I'm debating between trialing TypeScript or Elm for a personal project (I primarily work in Rust and Go on the backend/infrastructure), and iteration times are important when trying to get a frontend UI "just right".

Re: Announcing TypeScript 2.0 Beta

#36

Post by jsheard »

moosingin3space wrote: post #35
Derander wrote: post #22

Earlier quoted context omitted.

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.

I ask because I'm debating between trialing TypeScript or Elm for a personal project (I primarily work in Rust and Go on the backend/infrastructure), and iteration times are important when trying to get a frontend UI "just right".

You could just use TypeScripts ES6 output directly during development, using a browser that supports ES6 natively, then add Babel to the build chain for public builds that need to work on older browsers.

Re: Announcing TypeScript 2.0 Beta

#37

Post by kbenson »

spriggan3 wrote: post #31
ihsw wrote: post #27

Earlier quoted context omitted.

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 c…

> let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too an…

> > let x = (id: number, name?: string) => { return; };

> hmm, it would make more sense if it was written like that

> > let x = (id: number, name: string?) => { return; };

> But I guess it's more or less ok. But I definitely feel inconfortable with the ! .

I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well.

In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.

Re: Announcing TypeScript 2.0 Beta

#38

Post by johnfn »

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…

This post is full of misplaced FUD.

> It's not just type annotations anymore + ES6

How not?

! is just an inline type coercion.

> What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ?

This seems unlikely because ! is already an operator in JS.

But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language.

In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.

Re: Announcing TypeScript 2.0 Beta

#39

Post by moosingin3space »

jsheard wrote: post #36
moosingin3space wrote: post #35

Earlier quoted context omitted.

I ask because I'm debating between trialing TypeScript or Elm for a personal project (I primarily work in Rust and Go on the backend/infrastructure), and iteration times are important when trying to get a frontend UI "just right".

You could just use TypeScripts ES6 output directly during development, using a browser that supports ES6 natively, then add Babel to the build chain for public builds that need to work on older browsers.

Do I generally need to use prerelease browsers for ES6 support? Sorry, it's been a long time since I've been on the frontend.

Re: Announcing TypeScript 2.0 Beta

#40

Post by jsheard »

moosingin3space wrote: post #39
jsheard wrote: post #36

Earlier quoted context omitted.

You could just use TypeScripts ES6 output directly during development, using a browser that supports ES6 natively, then add Babel to the build chain for public builds that need to work on older browsers.

Do I generally need to use prerelease browsers for ES6 support? Sorry, it's been a long time since I've been on the frontend.

The stable versions of Chrome, Firefox and Edge all support ES6 generators. Safari stable doesn't support them yet but the tech preview does.

https://kangax.github.io/compat-table/es6/

Post reply on HN