Live data from Hacker News

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

111–120 of 226 posts

Re: Announcing TypeScript 2.1

#111

Feels like Typescript is building (or has built up?) more momentum than Flow.

Very early on, Typescript cleverly built up an ecosystem around community-supported type definitions for popular js libraries. This makes type-checking and integration for those libraries dead simple.

2 years later, Flow is _still_ lagging behind in this area. [1] I'm not certain, but I think this may be due to Typescript allowing for a external header-like file while Flow requires inline types.

For this reason I believe, as many other commenters have noted, Typescript has nearly always been ahead of Flow in popularity.

[1] https://github.com/facebook/flow/issues/7

Re: Announcing TypeScript 2.1

#112

Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts

They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript. In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.

I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages.

Regardless, I don't see much of a difference between TS -> JS and haskell->JS and scala -> JS. It's all from one language to another. the fact that TS is still considered a form of javascript is kind of irrelevant other than for semantics

Re: Announcing TypeScript 2.1

#113
post #8

It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.

Well, to me at least the mapped types are the main advantage of this release. Very frequently you start building a record incrementally (so, you can't assign it to an interface where all fields are mandatory), but then at a given stage you will validate that record and copy it to another variable which has the type with all the fields mandatory. Previously you had to define two copies, one with mandatory fields, another with all optional... kind of a bummer, and easy to update one and to forget the other!

Also, this greatly improves the type security of variables which work as keys to objects, without repetition of those keys on the interface and on the string literal.

So yeah, I'm thrilled with these changes

Re: Announcing TypeScript 2.1

#114
post #57

Earlier quoted context omitted.

Its true and unfortunate. Typescript is the new Coffeescript. It splits the ecosystem. Flow is a progressive enhancement and improves the ecosystem. Typescript has had more push in the mindshare marketing from Microsoft.

TypeScript doesn't split the community any more than Flow does. TypeScript remains very close to ES2016/2017, syntax-wise, with the only major difference being type annotations, but you have those with flow as well. Anybody who can read JavaScript can read TypeScript.

Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc.

With Flow you don't even have to opt-in to a new syntax. You can just use comments:

    function foo(val /* : boolean */) /* : string */ {}
Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all](https://medium.com/@thejameskyle/flow-mapping-an-object-373d...).

Re: Announcing TypeScript 2.1

#115

Earlier quoted context omitted.

I think there are two main kinds of developers who use TypeScript. Some developers come from traditional statically-typed languages, like C#/Java/C++/etc, and expect the language to conform to their idea of "good design". For these developers, "mapped types" are "not good design". Other developers come from JavaScript, Python, Ruby, or other duck-typed languages and think, "I know that this object is just a dictionar…

I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am. At this point in time, it's a bit of a false dichotomy. It just amounts to a programming tool based on a form of meta-data. Of course people are going to have different ideas about the cost-benefit of that tooling. Of…

I don't think this is a false dichotomy. There's definitely a spectrum between static and dynamic type systems, and plenty of people who identify with either camp. Calling it "tooling" changes the name of the problem, there are still people who will complain when they think the tooling is going in the wrong direction, and those complaints have merits because so many of us will be forced to write code in a style we don't like.

Re: Announcing TypeScript 2.1

#116

Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp t…

> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); }

That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.

Re: Announcing TypeScript 2.1

#117
post #88

Earlier quoted context omitted.

Can anyone weigh in on TypeScript vs Elm?

Elm is really cool language that's pushing a lot of boundaries. Use it for learning or for small projects. TypeScript is a highly practical and pragmatic language. Use it for anything serious.

what boundaries do you think Elm is pushing as a language?

It is a cool language and platform, but to me it looks like with time it has actually become more conservative.

TS on the other hand appears to contain some interesting new things on each release (possibly too many). Case in point, Lookup and Mapped types in 2.1 seem like a brilliant idea.

Re: Announcing TypeScript 2.1

#118
post #26

Earlier quoted context omitted.

The new type system features are: keyof, lookup types, and mapped types. Does flow have even one of these?

$Keys for keyof, $MapObj for mapped types. They are sorely missing lookup types though.

Googling for mapobj doesn't give me any results. Can you point to some documentation on these?

Re: Announcing TypeScript 2.1

#119
How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing.

Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.

Re: Announcing TypeScript 2.1

#120

If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…

If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo".

  ```javascript
  var foo = {
    a: true, // Find all references on "a" here...
    b: "hello"
  };

  foo.a = false;
  bar(foo);

  function bar(obj) {
    obj.a = false; // Won't find this "a".
  }

  ```
Call site inference can follow this sometimes. However with types it can be certain, e.g.

  ```typescript
  interface Foo {
    a: boolean;
    b: string;
  };

  var foo: Foo = {
    a: true,   // Find all references on "a" here...
    b: "hello"
  };

  foo.a = false;
  bar(foo);

  function bar(obj: Foo) {
    obj.a = false; // Will be found, renamed if refactored, etc..
  }

  ```
Note that the JavaScript in VS Code is powered by the same engine as the TypeScript, so it's using the same inference, it just can't infer untyped parameters.

There is some support for JsDoc in the engine, so code like the below will work:

  ```javascript
  /** @typedef {{a: boolean, b: string}} Foo */

  /** @type {Foo} */
  var foo = {
    b: "hello"
  };

  foo.a = false; // Find all refs here
  bar(foo);

  /**
   * @param {Foo} obj - Some object
   */
  function bar(obj) {
    obj.a = false; // will find this one
  }

  ```
Full disclaimer: I work on these tools.
Post reply on HN