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.

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 (with Flow), it's an amazing tool for static code analysis and avoid errors at the runtime. I would suggest everyone give it a try (with TypeScript, Flow or whatever).

  ```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".
  }

  ```

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

  ```

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
  }

  ```

Disclaimer: I'm working on a competing tool

If a particular function can be tied to particular variable from scoping block, then the function is not entirely useful. On the other hand, if a function is general and has the same argument name as variable from scoping block, which is going to be passed in, mentally it is difficult to analyse the function without thinking about the variable which may shadow bugs in function. E.g. square root function may omit negative argument check, because variable from scoping block is always positive.

Instead of knowing scoping rules I advocate for distinct variable names, so scoping rules (name shadowing) do not even come into play.

  function Person(name) {
    var person = this;
    person.name = name;
  }
  
  var person = new Person("Jon Doe");
  
  alert("Welcome " + person.name);

  person.name = "Harry Houdini";

  // ES6 example:
  var messages = people.map( person => person.name += " is a rock star" )

As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript?

(I use the official flow-for-vscode extenstion, idk if it's relevant)

Edit: Ok I just tried and it works, even with the extension disabled.

  type 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; // Found it.
  }

- If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function).

- Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).

I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.

However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.

Their algorithm always fails on certain cases. If your code base is larger, it's more likely to contain those cases.

Example case that will always fail:

    const x = { foo: () => {} }
    x["f" + "oo"]();

Yes, this is a contrived case, but we had similar code in production at my last job.

With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!

I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.

I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.

If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.

That right there is the whole essence of typed programming :)

Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.)

Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)

But sometimes I don't care exactly what sort of number is used. This is where many type systems go overboard, by forcing me pick a 64 bit unsigned integer or whatever.

One big thing is TypeScript classes are entirely different than standard JS classes. I guess you don't have to use them but it adds Abstract classes, interfaces and access control (eg private, protected vars).

I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.

Elm is pretty neat if you want to build a reactive GUI framework with everything immutable by default and have lots of functional programming idioms at your disposal. However that's all it does: if you want to do e.g. server-side rendering or use it in an angular project you're out of luck; if you want to interop with other JS code then it's a pain.

Typescript doesn't enforce any paradigm or bring any particular framework with it. It's just Javascript with type annotations and some extra features. So you can use it with React and Redux to create something like Elm's framework, but it won't be quite as safe or concise as you'd get with Elm. However it fits in much nicer with other JS libraries and can run on the server or alongside any JS GUI framework of your choice.

Elm is also still officially beta, and new releases often involve fairly large breaking changes.

Personally I started off a big fan of Elm but fell off the bandwagon as I ran into its limitations.

Elm is sometimes on the frontpage of HN but let's be honest, it's not really used.

TypeScript is a highly practical and pragmatic language. Use it for anything serious.

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.

[Pros]

- Good language design (immutable, based on haskell+OCaml, nice type unions/pattern matching, everything is an expression, etc) Most people who write Elm are seduced by its elegance.

- Very, very typesafe. If it compiles, 99.5% of chances that you won't get runtime errors (baring a few bugs) handy when you're tired.

- It was made for beginners, it's easy to pick up, the tooling is simple, the compiler errors are easy to read.

- The "Elm architecture" provides a way to build simple SPAs, out of the box, without having to use 10 libraries like some people do in the JS world.

[Cons]

- The community is tiny

- Elm is... by far the most opinionated environment I've ever seen. More so than RoR/Ember. Elm the language and Elm the framework have no clean escape hatches. It provides guidance for newbies, but when you encounters problems, it stings.

- The Elm framework is entangled with the Elm language. One person pretty much maintains both; developments go at a very slow pace and potential contributors don't feel overly welcomed.

- Elm's type system is extremely simplistic. You won't be able to express many things with it, and your code will have a LOT of boilerplate.

- if you're a front end developer with a sharp attention to details, it's a pain to build complex things with it, especially SPAs who have a lot of state. You need hacks all the time as the language + the framework are fairly under powered and it gets new features once every blue moon. There are many things that are impossible to do in pure Elm, so you have to write javascript anyway. The official way is to use ports, but many teams seem to rely on the frown upon Native modules, which are written in awkward JS.

- Talking to Javascript (foreign interface) is a bit of pain (less so now than in the past though!) and so is reading/writing JSON, compared to typescript.

-------------- Typescript --------------

[Pros]

- Extremely productive, you're never stuck with a problem

- There is an entire team of professional developers behind this project. beta and RCs are actually more robust than Flow releases, for instance. You can even depend on nightly builds... It's solid.

- Very typesafe (way more than Java for instance), if you know what you're doing.

- The type system is now very, very expressive (version 2.0 and 2.1 helped a lot)

- It's extremely easy to use JS libs in your typescript project

- Performances are good as the generated JS is pretty much just the TS without the types annotations. There is no runtime, shim, etc.

- You still have access to everything JS, so for instance you can use CSS modules with webpack just like if you were using JS. The community is enormous.

[Cons]

- It's still crappy old javascript underneath. Everything is mutable (worse, Array apis mix mutable and immutable styles), if/else are not expressions, the "this" keyword, prototypes, classes are complete madness.

- Not typesafe enough if you are careless. Lots of traps. Unlike Elm, you can actually shoot yourself in the foot by not knowing about certain compiler flags, using <any> too often (I use a no-any tslint rule) or generally not paying attention enough (you need to give hints to the compiler in the right places) It's always going to be less typesafe than Elm though. For instance, functions are bivariant, ewww.

So for me, Elm is interesting conceptually and it has the potential to become good in a few years (perhaps compiling to web assembly) but typescript is the pragmatical choice in the short/medium term, unless you're building something fairly simple, in which case you can use absolutely whatever you want anyway!

So how do TypeScript and Elm compare to OCaml?

I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half.

I can hardly think of a reason to use JS now that TS exists.

Of course - there are some reasons, in some specific situations, but by and large, TS is the future.

TS does a great job without OO thanks to structural typing.

When I write JS, I end up with closures within closures within closures.

When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.

TypeScript tries not to impose any sort of restrictions on coding style.

I totally disagree with this. They are basically one of the best forms, if not 'the best' form of abstraction we have, particularly when it comes closer to the level of 'real world' abstraction.

Classes are the basis of 'typing' - which is to say, typing beyond primitive types.

They provide us with the ability to 'define things' that are not simply strings, numbers or booleans.

It's why JS has moved onto classes, and almost all popular languages use them.

The only time I find they can be limiting, is when there is the necessity to deal with looser typing, i.e. quick litoral objects ... but even then, 9 times out of 10 when I want to 'get around classes' - I'm just being lazy.

I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.

That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error.

With async/await, we had to rewrite our emit pipeline, which meant that we needed to keep parity in both output as well as time to emit. The investment has shown, and TypeScript is still extremely fast.

We're always willing to think about different approaches, but those are some of the rationales here.

I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bottle neck, async/await to the rescue!

Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging.

But your sewer is now even bigger! Look at how you can throw that hose around!

I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds.

It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it.

async/await in javascript is actually useful.

async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads.

That's not unique to the task-based asynchronous pattern, but it's far fewer lines of code to write than BeginExecuteReader/EndExecuteReader etc. so my appetite for doing it is much higher. And I believe asynchronous streaming (à la DbDataReader.ReadAsync) has no non-TAP equivalent.

Two steps forward, one step back. (You're right about debugging.)

And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead?

Where the entire web pipeline is already set up to naturally multi-thread by itself.

Most any .NET site doing volume should be using TPL, because the framework is incredibly efficient at managing threads and preventing the pipeline from getting clogged. I've worked on dozens of APIs and sites that need to deal with hundreds and thousands of concurrent requests. Handling those in a synchronous fashion or hand-rolling state management is horrible and I'd never want to go back to it.

The only downside I agree with is the debugging, but that gets better with every C#/.NET/VS release, and you really shouldn't have a ton of complexity buried in your await block. If it hurts, there's a good chance you're violating SOLID.

You're in the specific scenario!

If you're getting 1000s of concurrent requests, running at, say, 20ms each, that'd be 4.3 billion requests a day.

What percentage of C# devs have that kind of load?

If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download). Look at the wall clock - it's up to twice as fast. Look ma, no threads or synchronization primitives!

> And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself.

Blocking operations ... block. Now your thread is doing nothing while your database churns/disk writes/network packet streams. As I understand it, using async/await with the SynchronizationContext in ASP.NET will yield the thread to another request. You get more requests per thread, which mitigates the problems with thread-per-request as described here [1]. Instead it's a combination of thread-based and event-driven models.

[1] http://berb.github.io/diploma-thesis/original/042_serverarch...

So why bring it up?

And as for your condescending "Blocking operations ... block", talk about missing my entire point.

IIS is the victorian sewer, your code is the hose. IIS has many threads available to it, that's my entire point. You don't need async/await to free up those threads, it's got a ton of them ready to go.

Most programmers are not going to hit the thread limit, and when they do they can upgrade hardware while they figure out the tiny few high-impact async/awaits that would actually mitigate the problem.

It's pointless pre-optimization. We all talk about how evil it is, so why is it suddenly not evil with async/await?

Performance is not just fewer CPU cycles.

> IIS has many threads available to it, that's my entire point

My web services run on a VM with four cores. That's what I get given, and there's another twenty websites on it. The less overhead my code has the better. Just because it's not 100K TPS doesn't mean there aren't benefits.

Since there is no deadlock issue in JavaScript async/await should result in code that is easier to write as well as maintain.

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

Oh, for me it's just because I'm to dumb to grasp them ;)

Joke aside, I knew the other features from JavaScript already. I used them for half a year now and know what they give me. The rest is something I probably will apreciate when the time comes and I need it.

In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea.

I try to keep a simple stack (Typescript + NPM at the moment), and I prefer to wait for Typescript to have the feature I want, than to install a new dependency (Babel, for example) to my project.

These are two very different styles of programming, and TypeScript does a fairly good job of serving both groups--it would have to, in order to be as successful as it is. There are a ton of useful JavaScript libraries out there which couldn't easily be rewritten to conform to some Java-style type system, and there are a ton of skilled Java/C#/C++ engineers out there who don't want their name on a bunch of cowboy code.

I don't think this cultural division is going to go away any time soon, so it's in our best interest to believe that people in the "other camp" (whichever camp that is) are skilled and conscientious developers. 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 course, people are going to have differing opinions on how much of that tooling is worthwhile. Most of the problems with online discussions about this kind of tooling, come from people forgetting that it's just a discussion about tooling.

The key word is spectrum.

and plenty of people who identify with either camp.

What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopefully, someone has set that knob to a position that works pretty well, and things work out.

those complaints have merits because so many of us will be forced to write code in a style we don't like.

Just who gets to write code in exactly the style that they like? From what I've seen, people generally make compromises, or they found the "perfect" job, or they are the one running the project, or they are going rogue and doing their own thing and introducing inconsistencies into a project's codebase.

The difference between a dichotomy and a spectrum is itself a false dichotomy. Ask any biologist what a species is, and they might stammer out some kind of weaselly definition full of hedges, and that same biologist might turn around and publish a dichotomous key which tells you how to identify a particular species according to an easy set of rules. The same goes for politics, human sexuality, and yes, type systems.

So I'm not going to hedge myself when I say that people "identify with either camp". They do. Neither is it a contradiction when I say that there's a spectrum. And when I say that there are two main kinds of people—I hope that my reader understands that I'm not a robot, and that I don't actually think that type systems are some kind of strict dichotomy.

> Just who gets to write code in exactly the style that they like?

I could point out that, again, like/dislike is a spectrum and not only a dichotomy. See above discussion.

Please re-read. I never said your programming language "brings public discourse farther away from the truth." Otherwise, please provide a quote. What I said is that some discussion about language "brings public discourse farther away from the truth."

I just re-read, and perhaps you are talking about human language. Also, no, I'm not offended. I'm just making an observation about how talking about things in a certain way can shape thought in non-beneficial ways.

Ask any biologist what a species is, and they might stammer out some kind of weaselly definition full of hedges, and that same biologist might turn around and publish a dichotomous key which tells you how to identify a particular species according to an easy set of rules. The same goes for politics, human sexuality, and yes, type systems.

When I encounter political discussions online, I sometimes have a person pattern-match something I've said, then declare all of my political beliefs for me. In those situations, false dichotomy -- or rather unawareness of the spectrum -- has distorted someone's thinking away from the truth.

I suspect this happens to Golang a lot. Basically, the Go language designers seem to be heavily into the Pareto Principle. So they are very willing to have a quite barebones level of tooling, and leave a lot of features out. This is especially true for their type system. They seem (to me) to have succeeded in getting most of the benefits of a type system while minimizing the disadvantages, while having much of the "feel" of a dynamic language, while also avoiding most of the downsides. It's a kind of pragmatic minimalism I've only encountered before in dynamic languages like Clojure, Lua, and Smalltalk.

  interface Values {
    foo: string,
    // etc...
  }

  let keys: keyOf Values

  function initialize(defaults: {[key: keys]: string}) {...}

In general, in application-facing code I think you're absolutely correct: using strings as lookups is a hack that should be discouraged. (Though sometimes it's convenient when dealing with other JS libraries).

However the feature brings some strong metaprogramming abilities that wouldn't be possible otherwise. For instance I'd have to imagine that mapped types were implemented by using those features, and the ability to define types as variants of other types (beyond ordinary generics) is something very powerful.

I'm primarily an F# user and have been begging for something like this there. The ability to define variations on record types (without and id/timestamp for inserts, with those fields otherwise; hashed/raw password fields for your various user records; etc) in a typesafe manner without a ton of repetition is a game changer.

Why? (Genuine curiosity here, not trying to be hostile or anything like that)

I am basically 'anti religious' when it comes to software.

So many people argue back and forth about this or that, and 80% of arguments are academic and effete (this is what I mean be 'religious').

But I'm a big supporter of TS because I believe 'it makes sense' on almost every level.

I'm not a 'big supporter' of many things at all, if any.

I understand the limitations, and that it enforces some things for which we may want more flexibility ... but overall, I have to say I can't think of any reason ever to use JS again.

My hope is that V8 etc. build engines to run TS directly as opposed to having to transpile.

Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information?

I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps.

With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.

You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser!

As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them.

This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)

1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything)

    $ npm install --save-dev babel-plugin-transform-flow-strip-types

    { plugins: ["transform-flow-strip-types"] }

    $ npm install --save-dev eslint-plugin-flowtype-errors

    { plugins: ["flowtype-errors"] }

We're trying to integrate more with tools like this so you don't have to go changing your entire workflow. It shouldn't be so hard to add types to your existing JavaScript code.

EDIT:

Ah I think I get it, it's for editors that don't interface with Flow but only with eslint. Well, since WebStorm has Flow support - even though it's new and there are a few tickets open - I guess I should stick with the plugin that I already chose.

So I had enough and started with Flow on one file, then two - then I spent a week converting everything to Flow. I actually found a few subtle bugs in my code, but also two or three minor ones in Flow (issues submitted). I also found clear limits for this type system, for example, when you clearly know 100% sure that a value cannot be undefined but Flow insists you add a type check before using the property because it does not follow your dynamic logic, only its types.

If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types).

If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.

It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.

Yes and no.

Typescript does a little bit of filling in the gaps of some missing features if the target platform does not support a feature you used. So your compiled code will still be ES6 (or ES5), but it may have some boilerplate added to polyfill for something if ES6 or ES5 (or others..) do not officially support it.

The downside of using `esnext` everywhere is that someone might be employing a feature that is not widely supported in the target browser/JS engine. So it's pretty bad to start with that as a default without an understanding of the consequences.

  "no code changes" implies you could potentially be creating 
  something that doesn't run where you want it to. 

I'll be more careful about writing "one" instead of "you" next time.

Amazing work TypeScript team! This release has been a lot of work!

Great news! That will finally fix the syntax errors in VSCode. :)

https://github.com/Microsoft/vscode/issues/1974

https://github.com/Microsoft/vscode/issues/3804

  newThing = {...thing, propertyName: value}

  newThing = Object.assign({}, thing);
  newThing.propertyName = value;

    let newThing = { ...thing, propertyName: value } // type of newThing would be deduced: TypeOfThing & { propertyName: TypeOfValue }

    let newThing: TypeOfThing = { ...thing, propertyName: value }

    let newThing = Object.assign({}, thing, { propertyName: value })

It's nice paired with React (vs PropTypes) because the checking happens a lot earlier and is much richer.

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.

Another option is to load Typescript in your browser and let it transpile directly in the browser. Sourcemaps in this case are a bit more iffy in their browser support, but it can be an option for a quick debug cycle if you wanted to try something like that. Not particularly the fastest idea for a production app, though.

Typescript can be debugged on a source code level, using source-maps. Webstorm and VS Code have built-in or plugin solutions. I heard some people complaining about issues, but i had a pretty smooth experience so far.

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

  this may be due to Typescript allowing for a external
  header-like file while Flow requires inline types.

Though it looks like it didn't become active until after at least 03/2016 [2].

I mention this only because TypeScript has been active in this area since 10/2012 [3], which is in-line with the original intent of my comment - that Flow is over 2 years (closer to 3.5 years) behind in building this out.

[1] https://github.com/flowtype/flow-typed

[2] https://github.com/flowtype/flow-typed/graphs/contributors

[3] https://github.com/DefinitelyTyped/DefinitelyTyped/graphs/co...

Google Trends https://www.google.com/trends/explore?date=all&q=%2Fm%2F0n50...

NPM Downloads https://npm-stat.com/charts.html?package=typescript&package=...

- TS has been released before Flow

- TS has the support of the Angular community

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

    function foo(val /* : boolean */) /* : string */ {}

So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations.

Hardly a big difference.

> Using really powerful inference you can also write much fewer types

I'm just going to assume you didn't know typescript does this too.

Typescript is nice. You should give it a try once. You may end up surprised:)

Doesn't TypeScript actually predate all of those tools? So that logic doesn't seem reasonable.

What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case?

Also, do you have to tell TypeScript your target runtime for it to it to use it's ES3 async/await logic vs. it's ES2015 (which uses generators), or does it automatically figure it out?

(I'm working on it so let me know if you have questions)

Docs: https://www.typescriptlang.org/docs/handbook/compiler-option...

For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.)

With the following input:

  var foo = { x: 1, y: 2 };
  var bar = { a: 3, b: 4, ...foo };
  var baz = new Promise(function(resolve, reject) {
    resolve("quux");
  });

  var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };
  var foo = { x: 1, y: 2 };
  var bar = _extends({ a: 10, b: 11 }, foo);
  var baz = new Promise(function(resolve, reject) {
    resolve("quux");
  });

To solve this problem, many people use the `transform-runtime` plugin [1] as well. To put it shortly, it replaces inline helper functions (like _extends in the example above) with imports from an adapter module called 'babel-runtime', which itself exposes the relevant polyfills (regenerator[2] and core-js[3]).

With `transform-runtime`, I get the following:

  import _Promise from "babel-runtime/core-js/promise";
  import _extends from "babel-runtime/helpers/extends";
  var foo = { x: 1, y: 2 };
  var bar = _extends({ a: 10, b: 11 }, foo);

  var baz = new _Promise(function (resolve, reject) {
    resolve("foo");
  });

> I didn't know how to tell Babel which browsers I was targeting...

You might *really like babel-preset-env[4], a new project they just launched. Basically, you give it a set of browser targets (much like autoprefixer) and it works out exactly which plugins you need to support the latest (currently es2015, I think) version of javascript.

Hope that helps! Sorry for going on a Babel-related spiel in a Typescript thread, couldn't help myself. ;)

1: http://babeljs.io/docs/plugins/transform-runtime/#technical-... 2: https://facebook.github.io/regenerator/ 3: https://github.com/zloirock/core-js 4: https://github.com/babel/babel-preset-env

https://babeljs.io/docs/plugins/transform-object-rest-spread...

Might be cool in combination with preset-env

I was missing this mostly for incoming requests. A good solution for me has been to generate json-schema from typescript interface definitions, using the typescript-json-schema npm package. Then incoming data can be checked vs the generated json schemas. Works fine and I get json schemas for api endpoints from it as well, so no complaints.

if (my_var instance_of MyCustomType)

in TS, but you could in normal statically typed languages, correct?

The issues tend to start cropping up as you get further into TS-specific types like generic types. In a statically typed language you can inquire about the specifics of an implementation of a generic directly, and often even dispatch directly on that type. JS has no concept of your generic wrapper type and you need some other flag or logic to determine the runtime type of your generic code.

But in TS itself structural typing is used everywhere for actual type checking (except for classes with private members), and from my understanding there's no way to have TS help you check at runtime whether a type is structurally compatible with a value.

I wrote a library [1] that does this in a readable pattern-matching way, hope you find it useful!

[1] https://github.com/jiaweihli/rematch

Typescript can't match them 100%, but it's getting there. e.g. It doesn't have type variance, but it does have f-bounded polymorphism (which is unheard of in most mainstream languages). The language is powerful enough to build your own constructs. I maintain a Typescript library[1] that emulates Scala options/trys/futures.

For day-to-day work, Typescript is a joy to work with. I describe it to others as the child of Scala and Ruby - pretty powerful type system but with a large community.

[1] https://github.com/jiaweihli/monapt

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

Are they different? If language X can be expressed in its entirety as language Y then we can speak about X and Y interchangeably -- that's literally the point: full interop between client and server.

Anyway, there's a world of difference between TS and GHCJS, Scala.js, Clojurescript, Js_of_ocaml, etc. One speaks javascript, the others speak both.

As for reliability, in so far as TS is typed it will provide the compile time guarantees that its type system provides; not surprisingly the same goes for Scala.js, GHCJS, etc.

So, the decision point probably hinges more on aforementioned overhead, size of community, and tooling than language/type system features/power. If it were otherwise we'd have seen a huge uptick by now wrt adoption rates for the compile-to-js languages. Maybe that will change in future but for now the big players drive the javascript bus...

  // this should not be assignable, functions should be
  // contravariant WRT arguments, so if o2 is subtype of o1
  // then F1 is subtype of F2, which means you can't assign
  // a value of type F2 to F1: there are functions in the
  // set of functions F2 that don't belong in the subset F1
  type O1 = { a: string; b: string }
  type O2 = { a: string; b: string; c: string } 
  type F1 = (o: O1) => string
  type F2 = (o: O2) => string

  // should not compile!
  let f: F1 = (o: O2) => { return o.c.toString() }

  f({a: '1', b: '2'}) // throws at run time (o.c undefined)

Haskell and Scala have algebraic datatypes (or case classes) which make it easier to model data (especially in Haskell where the syntax is really nice). TypeScript also supports disjoint unions (union of several types with a tag field that has a concrete string value as the type) and control flow analysis, so with some effort it can provide "idiomatic" JS-style ADTs. Haskell and Scala can do exhaustiveness checks, making sure you've covered all the cases. TS can also sort of do that (when strictNullChecks are on):

  type T1 = { tag: 't1', value: string }
  type T2 = { tag: 't2', value: number }
  type T3 = { tag: 't3' }

  type T = T1 | T2 | T3

  function f(t: T):string {
    switch (t.tag) {
      case 't1': return t.value;
      case 't2': return t.value.toString()
      // Compiles only if you uncomment this line.
      // Otherwise inferred return type string|undefined is
      // incompatible with specified return type string
      //case 't3': return 'N/A'
    }
  } 

Both Haskell and Scala have higher kinded generics, something that TypeScript still lacks. This means importing category theory concepts in TypeScript is pretty much impossible. The problem isn't just with category theory though; the need to parameterise generic types with other generic types as type arguments can come up everyday JS code too. For example, a library that accepts a promise constructor as an argument is parameterized by a generic type [1]

Before v2.1 TypeScript already had some powerful features for working with record types, such as record unions and intersections. With mapped types introduced in 2.1 however, you could say it surpasses Haskell and Scala in this regard - if not with features, then at least with pleasantness / ease of use. I believe its possible to achieve the same things in Haskell with vinyl [2][3], but those are definitely not Haskell's native records. Not sure if Scala's shapeless [4] can provide something similar (the answer is probably yes).

Haskell has type classes, and Scala can provide the "equivalent" via implicits+traits. Both of these allow a very nice and generic style of programming with implementation flexibility (you can write new typeclass instances for old code). TypeScript has structural interfaces, which offer some flexibility compared to nominal interfaces: you can write an interface that is a subset of old code, then use both old and new code under that interface without modifying the old code. Still, its not as flexible as typeclasses (the implementation must already be a subset of the original old code). They also can't offer the return-type-based implementation selection that typeclasses can.

Of course, Haskell and Scala both have various type / macro / template superpowers that TypeScript doesn't have and isn't likely to ever have. For everyday programming though, the above list should cover the vast majority of interesting features.

[1]: https://github.com/Microsoft/TypeScript/issues/1213 [2]: https://hackage.haskell.org/package/vinyl-0.5.2/docs/Data-Vi... [3]: https://hackage.haskell.org/package/vinyl-0.5.2/docs/Data-Vi... [4]: https://github.com/milessabin/shapeless/wiki/Feature-overvie...

TypeScript continues to be for me the clear winner of the alt.js languages.

  function bar(x): string {

    function bar(x) /* : string */ {

Build and minification is still a pain though...

You can also create a separate build task to run a smoke test by directly calling the ts compiler to compile your code (skipping pre- and post- build steps). This was a lot faster than I expected.

I also would need to straighten out some things with how I'm handling TSX I think.

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 the difference between AMD and other paradigms. I still have problems with circular dependencies, or rather, things happening before modules are loaded.

Here's one pain point:

Creating a static attribute on a class and initializing it right there, as in:

class A { static b:B = new B(); }

Means that 'new B()' will get executed right when that module is loaded, possibly before the module containing B is loaded.

It's ugly, mechanical - but it's not a 'fine point'. I think these are the kinds of issues which are more likely to hold people back, as opposed to the lack of some rather fancy new paradigms such as 'Mapped Types'.

Anyhow, keep up the good work. Lovin't it.

«I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...»

async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial<T> (partial objects) and Readonly<T> (shallowly frozen objects).

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

I've got a project that just silently fails to build in VS - no errors, no warnings, build successful - but no output.

It seems like the Typescript tools inside VS2015 (even with the latest update) just aren't ready.

Turns out they implement two case statements, and handle every possible control structure.

https://github.com/Microsoft/TypeScript/issues/1664

OTOH, a function accepting an object which implements a specific interface as a parameter will make your code much more easier to extend, instead of modifying the prototype of a concrete class.

https://github.com/tc39/proposal-bind-operator (stage 0)

Then I could just write Typescript and run it on node/browser

I wonder if there is any ES proposal for enums.

Basically, Python 3 added syntax for annotations, but most of the syntax is make sure it parses like code expressions would, then ignore whatever those code expressions are.

    function f(x: any): T {
      return x
    }

If you don't want that behaviour, don't given x 'any' type. In that case there I'd probably use '{}' instead, and then use type guards (https://www.typescriptlang.org/docs/handbook/advanced-types.... to convince TypeScript that it's a T (whatever that means).

The last feature I'd want is an easy way to map nested json into classes rather than interfaces. Anyone know how?

    abstract class AbstractClassObject {
        constructor(json?: any){
            if (json){
                this.updateFromJSON(json)
            }
        }
        public updateFromJSON = (json: any): this => {
            Object.assign(this, json);
            return this;
        }
    }

    class Post {
       id: string;
       user: User;  // <- should be typeof User
    }

Any plans for .NET Core / CLR backend ?

I think, this will be the silver bullet. TS types should be able to generate statically compiled bytecode => native binary ?

[0] - http://type.litesolutions.net/

[1] - https://frhagn.github.io/Typewriter/

    let merged = { ...foo, ...bar, ...baz };

  let a = [1, 2, 3];
  Math.max(...a); // 3

  function sum(...numbers) {
    return numbers.reduce((a, b) => a + b, 0);
  }
  sum(1, 2, 3, 4, 5); // 15

Rest is the variadic case:

    function myFunction(a, b, ...rest) {
    }

    let [a, b, ...rest] = ['a', 'b', 'c', 'd']

    let { a, b, ...rest } = { a: 'a', b: 'b', c: 'c', d: 'd' }

Babel will do the second part.

You do have to pay for some of them, but there's some free ones as well.

The new changes makes `--noImplicitAny` require less type annotations; where the compiler can figure out the type of a variable through following the control flow.

TS is a superset of ES6+. So, not much. Dart is closer to C#, I'd say.

C# is a well-designed language, though. You can't say that about the first iterations of JS and none of its baggage was ever dropped for the sake of maintaining backwards compatibility.

TS gently pushes you in a more modern direction, which means that those JS issues matter much less in practice. It works pretty well. It does what it's supposed to do; it makes working on larger projects much more manageable.

If you write a lot of JS, I highly recommend to check it out.

TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one in C#, and it was designed to fit well with JS patterns and idioms (structural vs nominal type system)

If you look at TS code that looks like C#, it's because JS looks like that (classes syntax, classical inheritance, lambda syntax - it's all ES7 (or ES2016/ES2017, or whatever it's called now)