[ivanjovanovic]

The way I see it:

1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain.

2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain. Regarding that, it is kind of answer to forces that are trying to ensure domination in that domain for the future.

[rmrfrmrf]

To me, TypeScript is the answer to 1) the perceived quirkiness of JavaScript to those who are unfamiliar with it and 2) an increasing number of developers coming out of college with heavy Java backgrounds. I see TypeScript taking off mainly because of the latter point--strict typing and well-defined OO practices will act as a decent safety net for new developers.

[giulianob]

Actually just about every popular library out there for JS creates some sort of fake OO layer on top of JS (e.g. Backbone, jQuery, Prototype, YUI, etc..). If you are just throwing a couple of scripts together then JS is fine but if you are trying to make an actual application, you need libraries to make it more OO.

I've worked on large code bases in several languages and JS has to got to be one of the worst when it comes to code quality due to the flexibility. It's always an awful experience trying to refactor a large portion of JS since it's difficult to even find where objects are being used. I'd take AS3 over JS anytime of the day since it allows me to specify types (though optional) and if I do the tooling is able to do a lot of the static analysis that is important in large projects. TypeScript still gives you plain old JS while allowing you to specify some extra information in order to facilitate development. It's actually new developers that aren't aware of these things and love JS from what I've seen. They haven't worked on large code bases and love the flexibility of JS. When you actually are trying to create proper abstractions in order to architect your code, you need visibility modifiers, you need interfaces, and you need types.

[WayneDB]

Javascript is quirky. It's a great language, but c'mon...please. That horse has been beaten to death and the long discussion on this topic alone is proof of it's quirkiness and it's numerous pitfalls.

The idea that (optional) strict typing and (optional) well-defined OO practices would only work to act as a "safety net" for new developers is, quite frankly, ludicrous. Static typing is the bedrock of static analysis and if you can't see the value in static analysis, take a read here - http://www.altdevblogaday.com/2011/12/24/static-code-analysi...

You're welcome to keep doing things the hard way. You will certainly be enabled to do so since Javascript is not going anywhere. But easy-to-use Javascript-compatible languages with powerful, precise and accessible features are the future, IMO. I don't think I'm alone in that sentiment given the recently budding interest in this arena.

[dreamdu5t]

Poor state of JavaScript development? By what measure?

I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable.

The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like "JS lacks classes!" - I'm not sure they understand JavaScript.

[oinksoft]

Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped up my development cycle when working on hairy code.

This is a type, not a class, taken from a Closure Compiler docs annotation example:

  /**
   * Enum for tri-state values.
   * @enum {number}
   */
  project.TriState = {
    TRUE: 1,
    FALSE: -1,
    MAYBE: 0
  };

Now I can require this type in my code with standard JSDoc, which is what the compiler uses anyway for type-checking. It makes my code self-documenting (the Closure Linter, should you use it, will complain if you omit descriptions and the like too, if you find yourself getting lazy):

  /**
   * Do something...
   * 
   * @param state {project.TriState} The state ...
   */
  function doSomething(state) {

If you are documenting your code, you already do this. And now you have static analysis out-of-the-box ... not bad!

[disordinary]

The JSDoc system gets in the way too much, how for instance do you type variables which is something like:

  /** @type {myType} */ var thing = new myType( );

It gets way to verbose when compared to typescript which is something like:

  var thing : myType = new myType( );

[oinksoft]

Actually that's not quite accurate. The Closure Compiler doesn't need you to tell it that `thing` is a myType, it knows that, asuming myType is defined in your compiled code, or you provide an extern specifying what myType means. And I might be wrong about that last bit even; the compiler may always know that `new Foo` returns a {Foo} regardless of context ... I would have to check the compiler source to be certain.

Also, I think that the first example is more likely to be written as follows (in the case where type data cannot be inferred):

  /**
   * Description of the variable.
   *
   * @type {my.UnionType}
   */
  var foo = { ... };

Whatever "..." may be. It's common to document the meaning of variables where explicit typing like this is important, just like in well-documented Java and PHP code.

[disordinary]

The benefit of typing javascript is for the developer and not the compiler, therefore telling closure compiler that a variable is a type is to decrease the chance of mistakes. Closure compiler also is buggy and isn't as smart as we would like to think it is, sometimes you have to prod it into the right direction. It was a simplified example, something better would be:

  /** @type {myType} */ var thing = function_that_returns_a_myType( );

The point is using comments for typing a language is messy and takes up far more space than required.

[ajanuary]

The type system in TypeScript isn't 'rigid'. It's both optional and structural. These combine to make it a heck of a lot more lightweight than something like C++ or Java.

The classes in TypeScript are a formalisation of a very common design pattern in Javascript, so obviously people do think it's useful. TypeScript takes the common practice and makes it more succinct. (Other than inheritance, which does seem a little un-JSy)

[zachrose]

Perhaps you understand TypeScript better than I do. My rough understanding is that TypeScript is JavaScript with what's essentially inline JSDoc. The compiler is just there to give hints and warnings. Is this right?

[Locke1689]

No. JSDoc is just hints. TypeScript offers a fuzzy type unification system.

[winteriscomming]

You are entitled to your opinion but many developers disagree and want some more structure in the programming model. The very fact that many people are trying so hard to come up with some solution to JS means that there are significant problems worth fixing. If you don't see these problems or have them then that's great for you.

[nxn]

To preface, let's say that "application-scale" means something like the following: your server outputs a single html file that only contains references to js files and css (i.e., the minimum to get the app to work right), from then on all data operations are ajax calls to a server side API, while the entire state of the app, all UI/markup components included, is maintained via JS.

I've worked on a couple of these applications, they almost always end up having some fake-class system that provides mechanisms for encapsulation, code sharing, and namespacing. There's often almost a hundred of these fake classes defined with thousands of instances living in memory. I grant you that you can use things like the module pattern to accomplish those requirements -- in fact, if you couldn't, then I wouldn't be here talking about it because I'd be writing Java applets instead. But the lack of having static typing to catch simple errors and enabling basic refactoring tools (like renaming something without having to use a regular expression which took 2 hours to "perfect", or simply switching argument orders, etc) was the absolute worst. I've spent countless hours debugging problems that occurred because something like a string was accidentally passed when an array was expected, and only having the actual runtime error occur 50 function calls later because something like "cat"[0] was working fine up to that point. Static typing would have caught that before I even ran the app.

Anyway, these types of apps perhaps aren't as common as websites, but they exist and therefore there is a need for statically typed languages for the browser.

[path411]

I don't think of lack of strong typing or OO features as a bug either. I think Typescript's approach of optional features added to javascript provides even more flexibility. You can choose specifically if you want strong typing or not, or you can choose to use classes if you think it's the best approach for the current project. I don't think typescript is trying to remove the options that javascript already has, otherwise they would have gone the way of coffeescript or dart. Typescript, to use the common metaphor, simply extends your toolbelt to let you pick what you want for what you need.

[petegrif]

1. Well said.