Why does TypeScript have be the answer to anything? | Hacker News Reader

Why does TypeScript have be the answer to anything?

hanselman.com

94 pointsandrijac80 comments

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.

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

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.

With the rather large exception of filesize.

> I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.

Yeah, this was kind of an odd non sequitur that didn't go anywhere. I half-expected the article to actually give an illustration from computing history.

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

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.

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.

Don't forget source map support, that is a huge plus to have from day one.

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.

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.

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)

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?

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

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!

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( );

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.

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.

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.

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.

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.

1. Well said.

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.

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.

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.

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.

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.

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

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.

> 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).

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.

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

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?

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.

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.

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).

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.

Yes, of course, we sacrifice accuracy. I said so at the very start. But imagine a "go to definition" tool that works correctly for 99% of cases and barfs or goes to the wrong place on the others. If the alternative is no tool at all, that still sounds pretty useful!

I admit there are cases (refactoring is an example) where if you don't trust the tool 100% you won't use it. But many tools are not like that.

Well, you'd be without feedback alot, state of the art in type recovery is nowhere near 99%. Your libraries can exploit the flexibiliy of a dynamic language (meta programming, crazy unions) and make the job much harder. Typescript seems very interesting in the way they handle type retrofits on libraries, but I haven't really absorbed it yet.

Think about this pseudocode; imagine it's The Hot New Dynamic Language Of The Week.

  print "Which do you like better: cars or trees?
  let a = AskUserForInput()
  var b
  if a=="cars" then
   b = new Car()
  elseif a=="trees" then
   b = new Tree()
  endif
  b.DriveOnExpressway()

Clearly, that's not going to work out too well if the user picks "trees" but it's tough to spot before run time.

While that's a contrived and simplistic example (that you probably could somewhat easily detect with tooling/analysis) think about a language like Javascript where there are no classes and you may be adding or modifying a bunch of an object's methods at runtime. At coding time, the tooling doesn't even know if foo has a .bar() function, much less which .bar() function, much less if the particular .bar() function that foo may have is being called with acceptable parameters.

edit: even my pseudocode is buggy ;-)

Ok, if I understand you right, your point is that a tool like a linter will fail to warn about this error. I'm not sure what current (say) Python linters do in situations like that.

But a tool like "go to definition" would work fine, wouldn't it? Maybe you would need a heuristic that guesses what are the possible types b could have, and detects that Tree doesn't have DriveOnExpressway, so it takes you straight to the definition in Car. Certainly, there are more complicated cases where guessing b's type is harder or impossible. I'm not denying that.

I was curious what PyCharm would handle that. Here's a screenshot: http://imgur.com/IvwG5

Basically it will complain if neither Car or Tree have a DriveOnExpressway method, but it's fine if one of them does -- the warning goes away if I uncomment the method. So there's ways to fall through the safety net, but lots of things it will catch.

(In Javascript, it's looser -- it only flags a potential problem if "DriveOnExpressway" isn't defined at all in the file.)

Because there is no type. It's dynamic. You can't figure out what the type is unless you run the code.

def do_something(thing_a, thing_b): ...

What's the type of thing_a or thing_b?

There is none. There isn't even a type globally. thing_a and thing_b acquire new types at every call instance. This basically screws you for all useful auto-complete information.

You can't even do proper go-to-definition because of things like getattr.

Yes, there most certainly is a type. It's dynamic, but not nonexistent. Now, of course you don't know the type for sure unless you run the code. I said so at the start. But I'm saying, can't you do a pretty good job in most cases? In this case, you could go to all places where do_something is called and see what objects are being passed in.

Yes, maybe there are situations where dozens of different types are passed in by different calls, or where we're building a library and we don't have any calls to do_something in our codebase, and cases where everything is obfuscated by one means or another. But depending on style I bet there are lots of cases where it works out ok.

Yeah, I think it might be a programming-language cultural thing. Most refactoring tools are written for Java and C#, so the people with experience writing refactoring tools have worked out how to solve the problems when they have certain assurances. But it really should be possible to write usable refactoring tools for ruby and python and javascript - you'll have to do a little more work to figure out name collisions between variables and methods and there's going to be ambiguous metaprogramming stuff like using strings to lookup instance variables, but having good tooling in the cases where you weren't using metaprogramming might encourage programmers to use a more concrete coding style, and that's probably a good thing. (Java has the same problems when you use a lot of reflection. So people don't use much reflection!)

YES! And I bet that a little bit of heuristics, a little bit of machine learning, and/or a little bit of user feedback (say, a button that tells the tool it went to the wrong function definition) would help such a tool cover a few more of the difficult cases.

This ought to be a classic case of "worse is better", which is why I'm surprised to see that people seem to shy away from it.

I came to ask a similar question -- how much better is IDE support for statically typed languages than, for example, JetBrains' IDE support for Python, Javascript, CoffeeScript, etc? They offer code-completion, live error highlighting, go-to-declaration, refactoring (with a confirmation step if it's ambiguous), all that good stuff.[1] The interface asks for clarification when it's not sure what something refers to. It seems to work pretty well. I don't really use typed languages, though, so I don't know how much I'm missing. Can anyone comment based on experience with both?

(I actually also came to say, damn, y'all, IDE support is awesome, and it's here for dynamic languages. Go-to-declaration alone is lifechanging, since it's usually faster to jump into a library call with ctrl-B than to check the docs. Live error highlighting alone is worth it. Just give JetBrains whatever they ask for.)

[1] http://www.jetbrains.com/pycharm/features/index.html

If you've ever used Resharper then it's difficult to work in any other environment. I doubt most of Resharper's features would be possible in a non statically typed language. It's a Jetbrains product as well:

http://www.jetbrains.com/resharper/

Try the TypeScript playground http://www.typescriptlang.org/Playground/ . You can do rename, intellisense, find reference, etc directly from your browser.

TypeScript language service is developed in TypeScript. This is how they can host these type of function on the browser. It's all just JavaScript

Check out this screenshot from the playground http://i.imgur.com/H2rqD.png

Typescript has static type annotations. All those things are already easy in that context.

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.

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.

>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')) {

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.

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.

Really? Wow, that's cool. Can I have a reference?

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) 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/) 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/).

There is an experimental build of Chromium called Dartium that contains a Dart VM. It isn't practical for daily use, but it's a taste of things to come.

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

Do you know the history of ES4? http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...

This guy agrees with you (and so do I btw): http://blog.blakebarrett.net/2012/10/typescript-vs-actionscr...

And yes, they're all variants of ECMAScript. It's a mess!

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.

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.

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.

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.

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.

Does goog.require() resolve at run time or compile time?

You're realistically only going to deploy a compiled script. The compiler supports goog.require/provide() without requiring any JS inputs, and core tools like closurebuilder.py (which has superseded calcdeps.py) build your dependency graph for you. The compiler uses the require/provide statements to ensure that all necessary symbols are indeed provided, and are only included once in the script.

For debugging purposes, `base.js' implements goog.require() in JavaScript. The implementation is naïve, it just turns foo.bar.Baz into foo/bar/Baz.js and tries to include it. This is good enough for running unit tests or fiddling around with experimental code, which are the two times you're going to use `base.js'.

http://code.google.com/p/closure-library/source/browse/trunk...

Yes, my question is whether goog.require() executes on the client's computer (in production) or whether Closure strips out those calls when you pass a special flag (as part of your deploy build). I personally don't want dependency resolution to happen at runtime in production.

Erm ... like I said, it happens at compile-time. The library provides a runtime version for testing purposes. Sorry if I wasn't clear enough.

If there doesn't already exist a tool that watches your working directory for file changes and automatically recompiles, it will soon.

There are plenty of people who actively have build steps for web development: SASS, Less, CoffeeScript, CSS.

Pretty sure this will be addressed (likely sooner than later) in much the same way Mindscapes Web Workbench plug-in compiles SCSS & less files when you save the file...

Edit: I'm currently using Chirpy to compress and unify all my JavaScript, anyway. So this isn't even really a concern.

I agree 100%. You won't see type-check warnings/errors from the Closure Compiler (which I noted yesterday supports far more detailed type-checking than TypeScript) until you re-compile, but this doesn't prevent you from running your code in a development context at all, as it's just plain JavaScript and `base.js' can handle goog.require() calls at runtime. The same things of course apply to unit testing via the Closure test runner or any other test framework.

And you can use plovr to recompile on every reload (takes 5-10s) if you need these warnings in your workflow at every step.

Not an issue in practice with coffescript, due to various server- and client- side tooling. My current setup will actually recompile and refresh the browser for me whenever I save. Typescript should be just the same, workflow-wise.

I have to build my entire project

With good tools (IDE and build automation) coupled with continuous integration/deployment, this doesn't have to feel like a tax.

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.

> 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.).

OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.

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.

I believe it is also possible to create definition files, like c++ header files, for existing libraries. So for instance, if you want the type checking for backbone, you could create a backbone.d.ts and just include the class/method/function definitions (and interfaces if you want to) and not even touch the original library. I would imagine this is the preferred way of doing things still I would imagine most libraries are not going to want to convert there libraries to include TypeScript only syntax.

Reply on news.ycombinator.com