Live data from Hacker News

TypeScript 2.4

blogs.msdn.microsoft.com

21–30 of 52 posts

Re: TypeScript 2.4

#21
post #12

Won't we stop transpiling everything once ES6 support (& modules) are ubiquitous? I kind of feel like this is when everybody converted codebases to CoffeeScript and are now stuck with having to undo that... Yes, I get strong typing has merits - but so does writing the native language.

ES6 is mostly just syntax sugar and standard library stuff compared to ES 5 just like CoffeeScript. TypeScript is about about static analysis (and required metadata called type annotations in code which allow the analysis).

Big difference is that ES 6 has indeed replicated most solutions of CoffeeScript. However so far I can tell ES won't be ever(?) statically typed and therefore it won't ever(?) solve same problem space as TS.

Re: TypeScript 2.4

#22
I'm really excited about String enums. I've been avoiding enums in TypeScript until now, since every time I've wanted to use them, I realized that a literal union was easier to use when the times come to log or persist the value. But with this you keep the string representation, and get a typed constant at the same time.

Dynamic imports is pretty huge too, that should come in handy for a lot of people.

Re: TypeScript 2.4

#23

Is Typescript goal to be the Java/C# of the browser/nodejs? static type checking, tooling and heavily OOP(as in Java/C#) based?

It only adds types to Ecmascript/Javascript, so it's not more or less OOP then ES6 is.

Re: TypeScript 2.4

#24
post #4

The string enums don't seem to work the same way as the number enums, there's no 2 way access. For example. enum Test { a } let a = Test.a; let b = Test[ 0 ]; // isn't available on the string ones I wonder why its like that.

If there were a reverse map like for numeric enums, there'd be no way to (at runtime) distinguish a Name from a Value. With a numeric enum you can use typeof Test[x] to figure out if x was a valid Name or valid Value, but this doesn't work for string enums because they're both typeof == 'string'.

Re: TypeScript 2.4

#25
> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables…

> TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callback parameter type checks.

I understand what they mean after quite a bit of wrestling with that and the example, but I feel like that could have been far better worded for laypeople.

Re: TypeScript 2.4

#26
this is great news. the code below failed to compile in 2.3 but works in 2.4. it was an annoying bummer when working with ADTs in typescript. It's also nice that you can use string enum for the discriminators now. "{ kind: Kind.Ok, value: 'bla' }" feels less stringly.

  interface Ok { kind: "ok"; value: T; }
  interface Err { kind: "err"; error: string; }
  type Result = Ok | Err

  const maybeNumbers: Result[] = [
    { kind: "ok", value: 10 },
    { kind: "err", error: 'some error' },
    { kind: "ok", value: 9 },
  ];

  function isOk(thing: Result): thing is Ok {
    return thing.kind === "ok";
  }

  const okNumbers: Ok[] = maybeNumbers.filter(isOk);

Re: TypeScript 2.4

#27
post #3

I only know a little bit of JavaScript, what's the best way to learn TypeScript? Read Eloquent JavaScript then some TS related stuff? Or is there a TypeScript for Dummies that don't know JS?

Use it as a javascript syntax checker, it's probably the easiest to work with right now. And, when you learn more javascript, you may eventually take a look at actual typescript.

Re: TypeScript 2.4

#28
post #4

The string enums don't seem to work the same way as the number enums, there's no 2 way access. For example. enum Test { a } let a = Test.a; let b = Test[ 0 ]; // isn't available on the string ones I wonder why its like that.

What would be the use-case?

Re: TypeScript 2.4

#29
post #25

> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables… > TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callba…

I would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.

Re: TypeScript 2.4

#30
post #12

Won't we stop transpiling everything once ES6 support (& modules) are ubiquitous? I kind of feel like this is when everybody converted codebases to CoffeeScript and are now stuck with having to undo that... Yes, I get strong typing has merits - but so does writing the native language.

I see a potential end-game being TypeScript becoming the new ECMAScript.
Post reply on HN