Had a bit of a discussion on Twitter with Kevin Darty about TypeScript. It started off with this tweet:

I'm still a bit puzzled by all the hate for TypeScript. There seem to be a lot of NaySayers, but I've still yet to see a single example of a codebase that couldn't benefit from TypeScript. Since it's a superset of JS, you don't have to do anything to start using it except rename your .js files to .ts, and then you can add TypeScript only where you think it will add value.

It's like having a magic switch that helps you find errors and refactor. How can it possibly be a bad thing?

I don't buy the "it'll stop people learning proper JavaScript" argument. I don't know a huge amount of Assembly or IL. Sure, there might be situations were knowing more of them would be useful, but is it really worth the time investment when I could instead be improving my C#/other skills that I use every single day?

Does it matter if I can't type javascript without looking it up to hook up subclass prototypes in JavaScript if TypeScript can do it for me? No. Does it help if I understand the generated code? Sure. Is it a requirement? No. All that matters is I understand how it behaves and any limitations of it. The same way I don't need to understand 100% of the IL generated when I write C#.

I'd actually argue that TypeScript will actually improve most peoples ability to write this kind of JavaScript. Think of the workflow... Chances are, you'll store both .ts and .js files in source control (that's how I'd probably do it, so code reviews can see the actual code going to the browser, and we don't have to worry about devs seeing different code to what's being deployed by the CI server). That means when you're viewing your diffs prior to committing, you'll review both your changes and the generated changes from TypeScript. I'd say this will teach you how these things work in JS. You'll become more aware of how sub-classes work, the behaviour of "this" in event handlers, etc.

I'm still generally curious; I'd love to see someone present a codebase that can't benefit from TypeScript and prove me wrong. I genuinely can't think of how anyone could write JavaScript to run in the browser that wouldn't benefit from type-checking (whether it by their own objects, or access to the DOM) in any way. If you're a NaySayer, then take this challenge! :-)

There was also some discussion about Dart following on from +Kevin Darty's tweet, like:

I can't speak for all MS devs, but I thought it worth sharing my opinion... I certainly LOL'd at the Hell World JavaScript created from Dart, but that was kinda funny (moreso with recent talk of Tree Shaking being a huge advantage of Dart). In general, however, I think Dart is a good idea, but possibly this effort could be better spent doing things slightly differently (more on that later).

I think Dart is a very ambitious project. I really hope it catches on and we see support in all browsers. However, I just can't see it happening :O( Dart and TypeScript solve some of the same issues but coming from the exact opposite sides.

TypeScript is designed to be compatible with JavaScript so you can use all of the existing JS libraries out there, and slowly/progressively add TypeScript to your code.

Dart goes further, and also provides a runtime, which brings huge performance benefits (where it can be executed natively). It compiles to JavaScript for compatibility (a necessity to ever gain traction). It tries to do so much more than TypeScript, however the trade-off is that it doesn't integrate with existing JS libraries.

In an ideal world, the decision to use something like TypeScript vs Dart should be based on things like:

  1. Whether a Dart runtime is available to the majority of your users
  2. Whether you need to interact with a lot of existing JS libraries
  3. Whether you need to interact with a lot of your own JS (legacy projects)
  4. Whether you can invest the time required to learn Dart (there's a lot less to learn with TypeScript)

However, I can't help but think that the decision is actually going to be based on one thing only:

  1. Are you using Visual Studio or an Open Source IDE?

I just can't see TypeScript support ever being as good in non-VS IDEs. Nor can I see Dart support in VS ever being as good as it will elsewhere.

I actually think we could do much better than Dart or TypeScript. Scott Hanselman described JavaScript as the "Assembly Language for the Web". I think this is the first problem to address. We need something that runs in all browsers that addresses the issues with JavaScript, but it should be more like an intermediate language that other languages/tools can compile to (like we currently do with JavaScript, but less shit). That way, the choice of language can be decoupled from the browser support. If you want to write C#, VB.NET, Dart, Java, etc., it shouldn't matter. As long as they can all be compiled to a standard "IL", they should be deployable to a browser.

I don't know whether any of the existing technologies are good candidates for this (could we compile C#/Java/etc. into Dart? NaCl?), but I think it would be the best solution for all. People could use the IDE and languages they feel most comfortable/productive with.

In the meantime, compiling to JavaScript is the only thing we can do for compatibility. But in the background, I wish the standards bodies and browser vendors could get their heads together and agree on a new way of executing code in the browser in a way that they can all offer the experiences they wish to their devs. It doesn't matter whether it's based on something existing or new; the important thing is that it's not tied to the web development language and that the browser vendors and the companies with huge influences in development get behind it. If we can develop desktop apps and server-side code in the language of our choice; why can't we do the same for the browser? This would allow huge amounts of code reuse across our applications that we don't currently get.

Chrome already has NaCl, and will presumably have native Dart support soon. I wouldn't be surprised if IE ended up with native TypeScript support. This is going backwards, not forwards.