Wednesday, January 2, 2013

Generating Google Closure JavaScript from TypeScript

Over a year ago, I created a prototype for generating Google Closure JavaScript from CoffeeScript. Today, I am releasing a new, equivalent prototype that uses TypeScript as the source language.

<shamelessplug>I will be speaking at mloc.js next month in Budapest, Hungary, which is a conference on scaling JavaScript development. There, I will discuss various tools to help keep large codebases in check, so if you are interested in hearing more about this work, come join me in eastern Europe in February!</shamelessplug>

I have been interested in the challenge of Web programming in the large for quite some time. I believe that Google Closure is currently still the best option for large-scale JavaScript/Web development, but that it will ultimately be replaced by something that is less verbose. Although Dart shows considerable promise, I am still dismayed by the size of the JavaScript that it generates. By comparision, if TypeScript can be directly translated to JavaScript that can be compiled using the advanced mode of the Closure Compiler, then we can have all the benefits of optimized JavaScript from Closure without the verbosity. What's more, because TypeScript is a superset of JavaScript, I believe that its syntax extensions have a chance of making it into the ECMAScript standard at some point, whereas the chances of Dart being supported natively in all major browsers is pretty low.

In terms of hacking on TypeScript itself, getting started with the codebase was a pain because I develop on Linux, and presumably TypeScript's developers do not. Apparently Microsoft does not care that cloning a CodePlex repository using Git on Linux does not work. Therefore, in order to get the TypeScript source code, I had to switch to a Mac, clone the repo there, and then import it into GitHub so I could clone it from my Linux box.

Once I got the code on my machine, the next step was figuring out how to build it. TypeScript includes a Makefile, but it contains batch commands rather than Bash commands, so of course those did not work on Linux, either. Modifying the Makefile was a bit of work, and unfortunately will likely be a pain to reconcile with future upstream changes. It would be extremely helpful if Microsoft switched to a cross-platform build tool (or maintained two versions of the Makefile themselves).

Once I was able to build, I wanted to start hacking and exploring the TypeScript codebase. I suspected that reading the .ts files as plaintext without any syntax highlighting would be painful, so I Googled to see if there were any good alternatives to Visual Studio with TypeScript support that would run on Linux. Fortunately, JetBrains recently released a beta of PhpStorm and WebStorm 6.0 that includes support for TypeScript, so I decided to give it a try. Given that both TypeScript and support for it in WebStorm are very new, I am quite impressed with how well it works today. Syntax highlighting and ctrl+clicking to definitions work as expected, though PhpStorm reports many false positives in terms of TypeScript errors. I am optimistic that this will get better over time.

Now that I have all of the setup out of the way, the TypeScript codebase is pretty nice to work with. The source code does not contain much in the way of comments, but the code is well-structured and the class and variable names are well-chosen, so it is not too hard to find your way. I would certainly like to upstream some of my changes and contribute other fixes to TypeScript, though if that Git bug on CodePlex doesn't get fixed, it is unlikely that I will become an active contributor.

Want to learn more about Closure? Pick up a copy of my book, Closure: The Definitive Guide (O'Reilly), and learn how to build sophisticated web applications like Gmail and Google Maps!

7 comments:

  1. Michael,

    With regard to the Linux/CodePlex Git issue. We have seen the before in a few instances. Try updating the version of Git.

    In the past this as been an issue with an older version of Git.

    Let me know if this does not work for you.

    Thanks,
    Mark - CodePlex

    ReplyDelete
  2. I have not been this excited since like forever. This would be so huge and so cool I cannot wait. Unfortunately I would assume it will not be that stable in the beginning, however the benefits are evident. I have tried typescript in a project and because I have read the mailing lists I see that most people face large difficulties with types and sub-typing and stuff, but it comes so naturally when you have already been using closure compiler in advanced mode I could say I don't think I could ever again write untyped code. I really really prefer the type annotations as they are in typescript, so much easier to write... so please please please make this work:)

    Thanks

    ReplyDelete
  3. You might want to checkout the "develop" branch of the TypeScript source which comes with a jakefile. That makes compiling TypeScript way easier on non Windows systems.

    Best,

    Julian

    ReplyDelete
  4. I think it's a great project. Combination of TypeScript and Google Closure can be very powerfull and very nice to work with. For me, it can be best option now in the JavaScript world.

    ReplyDelete
  5. Good job, I look forward to giving this a go.

    It would be nice to have a reverse version of this tool available, so that existing Closure codebases (including the Closure Library) could be converted to TypeScript.

    ReplyDelete
  6. Hi Michael,

    Is this an experimental project and how do you handle and merge new versions of the typescript?

    Thanks

    ReplyDelete
  7. I'm using closure at the moment, and Typescript+closure looks like a big productivity gain.

    A couple of notes about Dart. The javascript cross compiler, dart2js, has recently landed some changes to type inference that look like they are really paying off. For the two linked benchmarks, cross compiled code is running at 0.86x, and 0.74x, of the handcoded javascript versions. See http://www.dartlang.org/performance/. The type inference is likely also having a large impact on the generated javascript code size. I haven't seen any numbers yet. Perhaps file a bug report to get the Dart team to add a code size chart of the benchmarks on their performance page.

    It is now also possible to do deferred code loading, which can help with start up time. See: http://api.dartlang.org/docs/releases/latest/dart_async/DeferredLibrary.html

    As soon as I can drop IE8 support in my apps, I will switch to Dart.

    However, I imagine for some apps, I will want to hand code the performance sensitive parts in javascript using closure. (Maybe javascript really is becoming the assembly langauge of the web?)

    ReplyDelete