TypeScript first impressions

Anders published a video of his new project today, which aims at creating a superset of JavaScript, that compiles down to regular current JavaScript. Anders is a tremendously clever guy, and it always shows in his work. There is much to like in the enterprise (good code completion, refactoring and adoption of the module pattern instead of namespaces to name three), but a few things made me rise an eyebrow.

First, there is no mention of CoffeeScript or Dart, but he does talk briefly about Script# and GWT. This is probably because the target audience seems to be the same as the audience for the latter two, i.e. developers who are more comfortable with statically-typed languages such as C# and Java than dynamic languages such as JavaScript. I don’t think he’s aiming at JavaScript developers. Classes and interfaces, although well executed, are not especially appealing.

Second, as any code generation tool (and this is true of CoffeeScript as well), you’d better like the generated code. I didn’t, unfortunately. The code that I saw is not the code I would have written. What’s more, I didn’t always find the TypeScript code especially more expressive than what it gets compiled to.

I also have a few questions.

Is it possible to duck-type interfaces? For example, if I have an IPoint2D interface with x and y coordinates, can I pass any object that has x and y into a function that expects IPoint2D or do I need to necessarily create a class that implements that interface, and new up an instance that explicitly declares its contract? The appeal of dynamic languages is the ability to make objects as you go. This needs to be kept intact.

UPDATE: this works.

More technical: why are generated variables and functions prefixed with _ rather than the $ that the EcmaScript spec recommends for machine-generated variables?

In conclusion, while this is a good contribution to the set of ideas around JavaScript evolution, I don’t expect a lot of adoption outside of the devoted Microsoft developers, but maybe some influence on the language itself. But I’m often wrong. I would certainly not use it because I disagree with the central motivation for doing this: Anders explicitly says he built this because “writing application-scale JavaScript is hard”. I would restate that “writing application-scale JavaScript is hard for people who are used to statically-typed languages”. The community has built a set of good practices over the last few years that do scale quite well, and many people are successfully developing and maintaining impressive applications directly in JavaScript.

You can play with TypeScript here: http://www.typescriptlang.org

16 Comments

  • At about 10:20 in the video he mentions that duck-typing works.

  • Yes, duck-typing interfaces works exactly as you'd hope. I agree with the __ vs $ bit though.

  • """""
    I would restate that “writing application-scale JavaScript is hard for people who are used to statically-typed languages”.
    """""

    Sorry, but this is ridiculously stupid.... JavaScript is uniquely broken in ways Python and Ruby are not.

  • Good point, Bertrand. Most of the developers who use statically-typed languages consider JavasScript weird and immature, and TypeScript seems the way to go for them. However, like you, I don't expect much adoption outside of Microsoft world. We'll see.

  • You said: "The community has built a set of good practices over the last few years that do scale quite well"... Which are you referring to? Thanks!

  • @Lou: the module pattern implemented in require.js is one.

  • Sorry, as somebody that has done a lot of development in both C# and JavaScript, on the server and client I don't really agree that the community has solved the scalability issues at all.

    Requirejs is great, so is coffeescript.  But with JavaScript the ability to discover the functionality of a external libraries is terrible.  If a language requires me to troll through the source or rely on the documentation to be up to date then there's something very wrong.

    Type checking is just step-1 on the path to validation.  With TypeScript it's an optional tool that you can add to your code.  

  • I've very rarely had to go into a JavaScript library's code in order to discover its features, but I've had to do it many times for managed code libraries. The language has little to do with that. Now if you are willing to use libraries with out-of-sync documentation, again that's got little to do with the language, but is definitely a bad choice on your part.
    With something like requirejs, it's quite easy to discover what's available. I really struggle to see what you mean. With good tooling, I don't feel a strong difference with managed code any more. Actually, I often do prefer dealing with JavaScript, because I don't need to use decompilers if I ever need to dive into the code as there is no binary JavaScript format.

  • I don't really approve when you say: “writing application-scale JavaScript is hard for people who are used to statically-typed languages”, it's true but TypeScript could make a lot of things easier for these people too.

    A simple exemple: updating a depedency with breaking API changes, without typescript you'll have to manually search/replace + running tests to ensure you did the right changes.
    With typescript when you're done fixing the compilation errors, it's probably ok.

    I really wish TypeScript will be adopted outside the MS community, the TS team should release equivalent tooling on other IDEs than VisualStudio as soon as possible to get the best support from community.

  • I'm curious about this statement:

    "Second, as any code generation tool (and this is true of CoffeeScript as well), you’d better like the generated code."

    Why? When I write C#, I don't care about what the IL looks like as I will seldom be interacting with it directly. I can't see the logic in wanting idiomatic JavaScript as output. I'm assuming source maps are on the feature list, which would allow me to step through the source rather than the output.

  • @Guillaume: that's unfortunate but it's my blog ;) You're neglecting the fact that decent tooling for JavaScript does exist. With refactoring, yes. And not just on Windows (ouch!). That argument would have worked five years ago. Barely.

    @Kevin: JavaScript is not IL. If you treat it like IL, you are in for a world of pain. Beyond debugging, which is a much more difficult issue than you imagine (GWT has you install browser plug-ins for example), and adding another leaky abstraction layer, it puts you in a walled garden of dependencies. Forget about using existing JavaScript libraries (TypeSharp got that one kinda right although the proxies they have to write are icky). Google tried it with GWT (and Meijer with Volta). Well, pretty much everyone tried it 6-7 years ago. If you like that sort of thing...

    Here's a good article from Resig about this subject: ejohn.org/.../javascript-language-abstractions

    Just learn JavaScript already instead of piling up layers of impenetrable junk above it ;)

  • Type safety is important for the domain. Any developer can agree with this.

    However, do I want to write all of my business logic in this?... probably not but it's a good bridge between C# and the demand for JS. I hope to use this in the near future but it will be driven by a C# based project.

  • Bertrand, you let them get under your skin.

    First, javascript is itself an abstraction, there's NOTHING wrong with abstractions!

    Second, this reminds me of the old C vs C++ argument, where they claim that anything you can do in C++, you can do in C. Well, while that's true, it's just harder because the language doesn't support advanced features.

    So it boils down to code quality and productivity. Of course you can write enterprise apps in plain javascript, but not without what you just derided... adding additional layers(albeit more js layers).

    All of the enterprise java/C++/C# developers can't possibly be wrong about best practices for delivering enterprise apps, but more importantly...

    Enterprise apps developed using teams of developers!

    TypeScript is a step in that direction, IMO, and a good step, even for smaller projects.

    I do agree that folks in the JS community, most of whom are small 1-5 dev shops who probably have never had to develop enterprise class apps won't care, or see what this is for.

    That's why I agree that this is more for Microsoft devs and their enterprise partners, who will force coding practices on contractors.

  • @Sam: I never said there was something inherently wrong with abstractions (even leaky ones: http://weblogs.asp.net/bleroy/archive/2004/12/02/274105.aspx). There is more than one way to build robust applications. "Enterprise" practices aren't the only ones. Thank FSM.
    Now that here: "folks in the JS community, most of whom are small 1-5 dev shops who probably have never had to develop enterprise class apps" is a gross caricature. As if I said for example that "enterprise developers" love to pile layer upon layer of unnecessary complexity that are only there to justify the salary of some IBM consultant.

  • Bertrand, I do find TypeScript somewhat interesting.

    Isn't part of the point that the community has developed patterns and practices on top of vanilla javascript that achieve most of what TypeScript sets out to do.

    Web development leaders who have spent a sifnificant portion of the last decade becoming masters of these practices will no doubt have a visceral reaction to TypeScript becuase they would prefer to mentor other developers into such practices.

    But there exists a large set of developers who no doubt benefit from this. I certainly will and ironically I will no doubt learn more about javascript looking at the generated code.

  • The only bad thing about Typescript is having to rewrite all your javascript to support it right? Or is there some easy converter? I would love to use it but I don't want to rewrite everything and worry about breaking things and retesting...

Comments have been disabled for this content.