7 ms·

Why does TypeScript have be the answer to anything?

94 points by andrijac 14y ago

ivanjovanovic 14y ago
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.
- dreamdu5t 14y ago
  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.
  - ajanuary 14y ago
    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 14y ago
      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 14y ago
        No. JSDoc is just hints. TypeScript offers a fuzzy type unification system.
  - oinksoft 14y ago
    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 14y ago
      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 14y ago
        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.
  - winteriscomming 14y ago
    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 14y ago
    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 14y ago
    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 14y ago
  1. Well said.
- rmrfrmrf 14y ago
  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 14y ago
    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 14y ago
    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-analysis/ 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.
MatthewPhillips 14y ago
I agree with this. If it's nothing more than a forward-compatible superset of JavaScript, with optional static typing, it has a place in the world of JS target languages.
- grayrest 14y ago
  I'm not sold on forward compat. I'm only an interested observer of TC39 but to my knowledge only arrow lambdas and modules (the cross file ones) are near consensus. The rest of the features added have either been going around for a long time or haven't really gotten a lot of discussion.
devgutt 14y ago
This is a ingenious move. A much smaller subset than CoffeeScript and still a sensitive and important one that probably will be incorporate at ECMAScript 6. If not, you still have your vanilla JS. I'm not sure with TypeScript will succeed, but I'm sure that this is the way to fix JS's problems.
nahname 14y ago
I have to build my entire project every time I want to update my client side code? That is an enormous tax to charge the developer just to add static typing to your client side code. I can't see this doing anything but slowing a team down.
- Me1000 14y ago
  Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too. A build step is already a reality for many people writing JS today.
  - asher_ 14y ago
    This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production. Even so, a build step can be a single keypress, so its no big deal.
    - MatthewPhillips 14y ago
      I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.
      - oinksoft 14y ago
        This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly. Unless you are performing integration tests, there is no reason to compile each time. Doing that is just the legacy of limited build systems.
mistercow 14y ago
>Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example. What is meant by this? As far as I know, the only way that you can use Dart in any browser currently is by compiling it to JS, and when you do that it most certainly does use native JS numbers. In fact, the type check function it creates for numbers contains this line: if (!(typeof value === 'number')) {
- apendleton 14y ago
  The native Dart VM distinguishes between integers and floats for performance reasons, and (I think) lets you explicitly cast back and forth between them, and if, at some point, Chrome ships a Dart interpreter, developers will be able to take advantage of that. I assume this all gets turned into noops when it's translated to JS, so to some extent it's academic, but I think they were just trying to illustrate that Dart's innate notions of built-in types are different than JS's, and are kludged into JS types at compile time, whereas TS sits much closer to current JS environments.
- scott_s 14y ago
  He means that the semantics of Dart - including the data types provided by Dart - are different from JavaScript. This is in opposition to TypeScript, which is a superset of JavaScript, which means that it necessarily shares JavaScrips semantics. If your example bothers you, consider that JavaScript just happens to be a target language for the Dart compiler. That is, it takes a program with Dart's semantics, and figures out how to map those to JavaScript semantics. That there is a mapping is not all that interesting, as such a mapping will exist from any Turing complete language to any other.
  - lindenr 14y ago
    Really? Wow, that's cool. Can I have a reference?
    - scott_s 14y ago
      I'm really just describing how a compiler works. Are you looking for references on the compilation process? There's a classic series called "Let's Build a Compiler" (http://news.ycombinator.com/item?id=1727004 http://news.ycombinator.com/item?id=1727004) available online that walks through building a simple compiler. Then there's also actual textbooks, but I was not impressed with either of the two textbooks I've had on the topic. Many people recommend "Compilers: Principles, Techniques, and Tools" (http://dragonbook.stanford.edu/ http://dragonbook.stanford.edu/) also referred to as just the dragon book. If you're not averse to textbooks, you may also want to check out Michael Scott's "Programming Language Pragmatics" (http://www.cs.rochester.edu/~scott/pragmatics/ http://www.cs.rochester.edu/~scott/pragmatics/).
benatkin 14y ago
The author ignores the fact that TypeScript is being heavily promoted by Microsoft. TypeScript isn't an experiment, but something Microsoft is trying to sell, along with their IDE. He starts it with a quote from a colleague rather than citing examples of people attacking TypeScript, as if it's a forgone conclusion that people have gone overboard on attacking it. I hate to see an argument for a programming language start with the author's persecution complex.
- TazeTSchnitzel 14y ago
  >Microsoft is trying to sell Do you mean sell as in for money? Or sell as in get people to adopt? Under an Apache license, I doubt it's the former. Although they could sell the Visual Studio tooling.
  - seanmcdirmid 14y ago
    Use the tooling to sell the platform? It might be in Microsoft's interest to have some mindshare I this space; JavaScript is a significant part of the windows 8 story from what I can tell.
- ryanzec 14y ago
  > Microsoft is trying to sell, along with their IDE I highly doubt that they created TypeScript to try to sell more copies of Visual Studio. I mean TypeScript is under the Apache 2.0 License so I don't see what would stop other IDEs (like JetBrain's WebStorm/PHPStorm/RubyMine/etc...) from integrating TypeScript into them (and I really hope they do soon).
rbellio 14y ago
I've been testing it out and I like it so far. I personally don't enjoy writing JavaScript in text editors and the tools like PHPStorm, while being decent don't really give me the slick development environments that I've come to enjoy. Since I do a lot of Windows and .NET web app development for my day job, I really enjoy the fact that Microsoft is putting a concerted effort into not only adding more support for JavaScript, but also for looking at the state of JavaScript and looking to improve the experience for people like me. In Anders introduction to TypeScript, he mentions the gap between .NET development and JavaScript and hints that this is just the beginning of bridging that gap. Rather than being a language that hides the underlying structure (a la ASP and ASP.NET) it is much closer to native JavaScript development. I'm really excited to see where this might go and have my fingers crossed that it only improves the state of JavaScript development.
bascule 14y ago
"What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more." RubyMine (by IntelliJ) can do all of that. Don't get me wrong, the refactoring support for statically typed languages is a lot better (e.g changing method signatures) but none of the examples he listed require one.
krohrbaugh 14y ago
First of all, I'm glad Microsoft is getting involved in this space. They have a deep talent pool when it comes to language design and tooling and it'll be interesting to see where TypeScript goes. Unfortunately, the arguments trying to draw some kind of monumental distinction between TypeScript, Dart and CoffeeScript are silly. They are all a response to the state of client-side development and are all applying essentially the same strategy (i.e., some syntax changes and a pre-compiler). It's great that TypeScript is a superset, which is what makes it pretty interesting to me, but it's still more similar to the other two than not. Plus, what's so bad about being Microsoft's "answer" to something else? Windows was the response to Mac OS, Xbox was a response to PlayStation, .NET was the response to Java, ASP.NET AJAX was the response to Prototype (later abandoned for jQuery), ASP.NET MVC was the response to Rails, Entity Framework was the response to Hibernate/Active Record, NuGet was the response to Rubygems/npm. Each of these moved MSFT forward and several of them moved the industry forward. The ASP.NET team (of which Mr. Hanselman is a member) is doing a lot of great stuff inside MSFT, but a lot of is derivative. That's okay. It's largely the strategy MSFT has always followed, so why waste energy defending what has worked well in the past? I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.
- TazeTSchnitzel 14y ago
  > essentially the same strategy (i.e., some syntax changes and a pre-compiler) TypeScript and CoffeeScript, yes. Dart's a brand new C-like web language that is quite different, and has its own VM. Although, of course, you can still compile to JS. But unlike TypeScript and CoffeeScript, it isn't really an alternative syntax for JS, or annotations removed at compile-time.
  - krohrbaugh 14y ago
    Yes, I know and you are correct. At a high-level, though, and in the case where browsers are the target platform, those aspects are largely implementation details.
    - TazeTSchnitzel 14y ago
jmmcd 14y ago
This isn't exactly the right place, but I don't know where else to ask this. When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why? I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if you don't deliberately write code to fool it. Right?
- winteriscomming 14y ago
  Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.
  - jmmcd 14y ago
    I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.
    - winteriscomming 14y ago
      It is just much more difficult to have tooling since the tools cannot know for sure what the program is doing (and neither can another human looking at it).
      - seanmcdirmid 14y ago
        To be more specific you have to use some crazy static analysis technology (global interprocedural analysis) that is intractable unless you sacrifice accuracy. Human have similar problems as compilers/tooling, though they are a bit better at understanding nuanced conventions to make better judgements about what dynamic code is doing.
        jmmcd 14y ago
drhowarddrfine 14y ago
Oh. I get it. It's the new JScript.
jconley 14y ago
The Typescript syntax looks shockingly like Adobe's ActionScript. Next up, Adobe releases an ActionScript to Javascript cross compiler?
- aaronblohowiak 14y ago
  Do you know the history of ES4? http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Edition http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...
- Zecc 14y ago
  This guy agrees with you (and so do I btw): http://blog.blakebarrett.net/2012/10/typescript-vs-actionscript.html http://blog.blakebarrett.net/2012/10/typescript-vs-actionscr... And yes, they're all variants of ECMAScript. It's a mess!
eranation 14y ago
I think google missed big time on Dart, and something like TypeScript is what they should have done. I really find it hard to come up with bad things to say about Microsoft's move, it's a mental cognitive dissonance, but I have to admit, they are doing something very right. 1) it's just JavaScript - winning some CoffeeScript fans 2) regular JavaScript is valid, (just like SCSS vs SASS) 3) it has day 1 interop with vanila JS (Dart just started, and until it has it, it's just a play-with language) 4) TypeScript support for most popular editors (Dart has mostly Eclipse I think, TypeScript has support for everything but eclipse, but an eclipse plugin is just a matter of time probably) 5) TypeScript has a bit more chance becoming a standard, (future ECMASCript 6?) Well played Microsoft, didn't see it coming... VS 2012 is actually nice, still I would probably wait for an Eclipse plugin (I'm sure someone out there is already working on it) but this is for me a big reason not to start learning Dart
- cmccabe 14y ago
  I think you answered your own question. Google wanted a fundamentally different language, not just JS with some extra features thrown in. As to what will win out in the end-- I have no idea.
  - eranation 14y ago
    Google seem to like inventing things, they have people who create languages for a living (some of the creators of Java, that some of them are probably behind Dart) and they did some pretty amazing things, Go is a great language, I'm sure Dart will have a fan base, and who knows, it might catch up (in 2004 no one thought Ruby will be that popular, right?) Google went for their vision, Microsoft went for the practical.
- ahrjay 14y ago
  Don't forget source map support, that is a huge plus to have from day one.
cmccabe 14y ago
Seems like a troll article to me. Of course people are comparing TypeScript to Dart. They do the same freaking thing-- provide you with a different way to write code to run in the browser. Then he presents the metaphysical distinction between "building on JS" (good) versus "interop with JS" (bad). What's the difference? Neither language is JS. If something breaks, you're still going to be debugging code that isn't the code you wrote-- it's generated code. I feel no better informed after reading this article than before. Will someone please do a straightforward comparison between Dart, TypeScript, and CoffeeScript? It might be kind of hard because as far as I can see, TypeScript does not build on Linux. P.S. Is "it doesn't even use the JS numeric type" supposed to be a put-down of Dart? I always thought the JS numeric type was a big mistake. Who would want to be forced to use floats for everything? Inaccurate and slow-- two great tastes that taste great together.
- Garoof 14y ago
  > What's the difference? One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code. I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.) * It still obviously depends a lot on the language. Like, how well TS-code works together with plain JS-code (how much do you get out of adding some type annotations here and there while leaving most of the JS-code untouched, etc.).
  - cmccabe 14y ago
    OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.
    - path411 14y ago
      Mostly the approach that personally makes TS interesting to myself is that typescript is building on top of javascript. You don't need to convert javascript to typescript because it already is typescript. Typescript simply extends the language. Dart or coffeescript on the other hand essentially creates an entirely new language that is simply compiled down to javascript.

94 points by andrijac 14y ago

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.

dreamdu5t 14y ago
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.
- ajanuary 14y ago
  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 14y ago
    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 14y ago
      No. JSDoc is just hints. TypeScript offers a fuzzy type unification system.
- oinksoft 14y ago
  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 14y ago
    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 14y ago
      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.
- winteriscomming 14y ago
  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 14y ago
  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 14y ago
  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 14y ago
1. Well said.
rmrfrmrf 14y ago
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 14y ago
  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 14y ago
  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-analysis/ 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.

MatthewPhillips 14y ago

I agree with this. If it's nothing more than a forward-compatible superset of JavaScript, with optional static typing, it has a place in the world of JS target languages.

grayrest 14y ago
I'm not sold on forward compat. I'm only an interested observer of TC39 but to my knowledge only arrow lambdas and modules (the cross file ones) are near consensus. The rest of the features added have either been going around for a long time or haven't really gotten a lot of discussion.

devgutt 14y ago

This is a ingenious move. A much smaller subset than CoffeeScript and still a sensitive and important one that probably will be incorporate at ECMAScript 6. If not, you still have your vanilla JS. I'm not sure with TypeScript will succeed, but I'm sure that this is the way to fix JS's problems.

nahname 14y ago

I have to build my entire project every time I want to update my client side code? That is an enormous tax to charge the developer just to add static typing to your client side code. I can't see this doing anything but slowing a team down.

Me1000 14y ago
Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too. A build step is already a reality for many people writing JS today.
- asher_ 14y ago
  This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production. Even so, a build step can be a single keypress, so its no big deal.
  - MatthewPhillips 14y ago
    I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.
    - oinksoft 14y ago
      This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly. Unless you are performing integration tests, there is no reason to compile each time. Doing that is just the legacy of limited build systems.

mistercow 14y ago

>Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example. What is meant by this? As far as I know, the only way that you can use Dart in any browser currently is by compiling it to JS, and when you do that it most certainly does use native JS numbers. In fact, the type check function it creates for numbers contains this line: if (!(typeof value === 'number')) {

apendleton 14y ago
The native Dart VM distinguishes between integers and floats for performance reasons, and (I think) lets you explicitly cast back and forth between them, and if, at some point, Chrome ships a Dart interpreter, developers will be able to take advantage of that. I assume this all gets turned into noops when it's translated to JS, so to some extent it's academic, but I think they were just trying to illustrate that Dart's innate notions of built-in types are different than JS's, and are kludged into JS types at compile time, whereas TS sits much closer to current JS environments.
scott_s 14y ago
He means that the semantics of Dart - including the data types provided by Dart - are different from JavaScript. This is in opposition to TypeScript, which is a superset of JavaScript, which means that it necessarily shares JavaScrips semantics. If your example bothers you, consider that JavaScript just happens to be a target language for the Dart compiler. That is, it takes a program with Dart's semantics, and figures out how to map those to JavaScript semantics. That there is a mapping is not all that interesting, as such a mapping will exist from any Turing complete language to any other.
- lindenr 14y ago
  Really? Wow, that's cool. Can I have a reference?
  - scott_s 14y ago
    I'm really just describing how a compiler works. Are you looking for references on the compilation process? There's a classic series called "Let's Build a Compiler" (http://news.ycombinator.com/item?id=1727004 http://news.ycombinator.com/item?id=1727004) available online that walks through building a simple compiler. Then there's also actual textbooks, but I was not impressed with either of the two textbooks I've had on the topic. Many people recommend "Compilers: Principles, Techniques, and Tools" (http://dragonbook.stanford.edu/ http://dragonbook.stanford.edu/) also referred to as just the dragon book. If you're not averse to textbooks, you may also want to check out Michael Scott's "Programming Language Pragmatics" (http://www.cs.rochester.edu/~scott/pragmatics/ http://www.cs.rochester.edu/~scott/pragmatics/).

benatkin 14y ago

The author ignores the fact that TypeScript is being heavily promoted by Microsoft. TypeScript isn't an experiment, but something Microsoft is trying to sell, along with their IDE. He starts it with a quote from a colleague rather than citing examples of people attacking TypeScript, as if it's a forgone conclusion that people have gone overboard on attacking it. I hate to see an argument for a programming language start with the author's persecution complex.

TazeTSchnitzel 14y ago
>Microsoft is trying to sell Do you mean sell as in for money? Or sell as in get people to adopt? Under an Apache license, I doubt it's the former. Although they could sell the Visual Studio tooling.
- seanmcdirmid 14y ago
  Use the tooling to sell the platform? It might be in Microsoft's interest to have some mindshare I this space; JavaScript is a significant part of the windows 8 story from what I can tell.
ryanzec 14y ago
> Microsoft is trying to sell, along with their IDE I highly doubt that they created TypeScript to try to sell more copies of Visual Studio. I mean TypeScript is under the Apache 2.0 License so I don't see what would stop other IDEs (like JetBrain's WebStorm/PHPStorm/RubyMine/etc...) from integrating TypeScript into them (and I really hope they do soon).

rbellio 14y ago

I've been testing it out and I like it so far. I personally don't enjoy writing JavaScript in text editors and the tools like PHPStorm, while being decent don't really give me the slick development environments that I've come to enjoy. Since I do a lot of Windows and .NET web app development for my day job, I really enjoy the fact that Microsoft is putting a concerted effort into not only adding more support for JavaScript, but also for looking at the state of JavaScript and looking to improve the experience for people like me. In Anders introduction to TypeScript, he mentions the gap between .NET development and JavaScript and hints that this is just the beginning of bridging that gap. Rather than being a language that hides the underlying structure (a la ASP and ASP.NET) it is much closer to native JavaScript development. I'm really excited to see where this might go and have my fingers crossed that it only improves the state of JavaScript development.

bascule 14y ago

"What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more." RubyMine (by IntelliJ) can do all of that. Don't get me wrong, the refactoring support for statically typed languages is a lot better (e.g changing method signatures) but none of the examples he listed require one.

krohrbaugh 14y ago

First of all, I'm glad Microsoft is getting involved in this space. They have a deep talent pool when it comes to language design and tooling and it'll be interesting to see where TypeScript goes. Unfortunately, the arguments trying to draw some kind of monumental distinction between TypeScript, Dart and CoffeeScript are silly. They are all a response to the state of client-side development and are all applying essentially the same strategy (i.e., some syntax changes and a pre-compiler). It's great that TypeScript is a superset, which is what makes it pretty interesting to me, but it's still more similar to the other two than not. Plus, what's so bad about being Microsoft's "answer" to something else? Windows was the response to Mac OS, Xbox was a response to PlayStation, .NET was the response to Java, ASP.NET AJAX was the response to Prototype (later abandoned for jQuery), ASP.NET MVC was the response to Rails, Entity Framework was the response to Hibernate/Active Record, NuGet was the response to Rubygems/npm. Each of these moved MSFT forward and several of them moved the industry forward. The ASP.NET team (of which Mr. Hanselman is a member) is doing a lot of great stuff inside MSFT, but a lot of is derivative. That's okay. It's largely the strategy MSFT has always followed, so why waste energy defending what has worked well in the past? I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.

TazeTSchnitzel 14y ago
> essentially the same strategy (i.e., some syntax changes and a pre-compiler) TypeScript and CoffeeScript, yes. Dart's a brand new C-like web language that is quite different, and has its own VM. Although, of course, you can still compile to JS. But unlike TypeScript and CoffeeScript, it isn't really an alternative syntax for JS, or annotations removed at compile-time.
- krohrbaugh 14y ago
  Yes, I know and you are correct. At a high-level, though, and in the case where browsers are the target platform, those aspects are largely implementation details.
  - TazeTSchnitzel 14y ago

jmmcd 14y ago

This isn't exactly the right place, but I don't know where else to ask this. When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why? I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if you don't deliberately write code to fool it. Right?

winteriscomming 14y ago
Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.
- jmmcd 14y ago
  I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.
  - winteriscomming 14y ago
    It is just much more difficult to have tooling since the tools cannot know for sure what the program is doing (and neither can another human looking at it).
    - seanmcdirmid 14y ago
      To be more specific you have to use some crazy static analysis technology (global interprocedural analysis) that is intractable unless you sacrifice accuracy. Human have similar problems as compilers/tooling, though they are a bit better at understanding nuanced conventions to make better judgements about what dynamic code is doing.
      - jmmcd 14y ago

drhowarddrfine 14y ago

Oh. I get it. It's the new JScript.

jconley 14y ago

The Typescript syntax looks shockingly like Adobe's ActionScript. Next up, Adobe releases an ActionScript to Javascript cross compiler?

aaronblohowiak 14y ago
Do you know the history of ES4? http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Edition http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...
Zecc 14y ago
This guy agrees with you (and so do I btw): http://blog.blakebarrett.net/2012/10/typescript-vs-actionscript.html http://blog.blakebarrett.net/2012/10/typescript-vs-actionscr... And yes, they're all variants of ECMAScript. It's a mess!

eranation 14y ago

I think google missed big time on Dart, and something like TypeScript is what they should have done. I really find it hard to come up with bad things to say about Microsoft's move, it's a mental cognitive dissonance, but I have to admit, they are doing something very right. 1) it's just JavaScript - winning some CoffeeScript fans 2) regular JavaScript is valid, (just like SCSS vs SASS) 3) it has day 1 interop with vanila JS (Dart just started, and until it has it, it's just a play-with language) 4) TypeScript support for most popular editors (Dart has mostly Eclipse I think, TypeScript has support for everything but eclipse, but an eclipse plugin is just a matter of time probably) 5) TypeScript has a bit more chance becoming a standard, (future ECMASCript 6?) Well played Microsoft, didn't see it coming... VS 2012 is actually nice, still I would probably wait for an Eclipse plugin (I'm sure someone out there is already working on it) but this is for me a big reason not to start learning Dart

cmccabe 14y ago
I think you answered your own question. Google wanted a fundamentally different language, not just JS with some extra features thrown in. As to what will win out in the end-- I have no idea.
- eranation 14y ago
  Google seem to like inventing things, they have people who create languages for a living (some of the creators of Java, that some of them are probably behind Dart) and they did some pretty amazing things, Go is a great language, I'm sure Dart will have a fan base, and who knows, it might catch up (in 2004 no one thought Ruby will be that popular, right?) Google went for their vision, Microsoft went for the practical.
ahrjay 14y ago
Don't forget source map support, that is a huge plus to have from day one.

cmccabe 14y ago

Seems like a troll article to me. Of course people are comparing TypeScript to Dart. They do the same freaking thing-- provide you with a different way to write code to run in the browser. Then he presents the metaphysical distinction between "building on JS" (good) versus "interop with JS" (bad). What's the difference? Neither language is JS. If something breaks, you're still going to be debugging code that isn't the code you wrote-- it's generated code. I feel no better informed after reading this article than before. Will someone please do a straightforward comparison between Dart, TypeScript, and CoffeeScript? It might be kind of hard because as far as I can see, TypeScript does not build on Linux. P.S. Is "it doesn't even use the JS numeric type" supposed to be a put-down of Dart? I always thought the JS numeric type was a big mistake. Who would want to be forced to use floats for everything? Inaccurate and slow-- two great tastes that taste great together.

Garoof 14y ago
> What's the difference? One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code. I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.) * It still obviously depends a lot on the language. Like, how well TS-code works together with plain JS-code (how much do you get out of adding some type annotations here and there while leaving most of the JS-code untouched, etc.).
- cmccabe 14y ago
  OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.
  - path411 14y ago
    Mostly the approach that personally makes TS interesting to myself is that typescript is building on top of javascript. You don't need to convert javascript to typescript because it already is typescript. Typescript simply extends the language. Dart or coffeescript on the other hand essentially creates an entirely new language that is simply compiled down to javascript.