The Rise of TypeScript?

rise_typescript_header

The JavaScript community consolidates tools and frameworks about as often as Nicholas Cage makes a good movie. I mean, it happens, but it happens so infrequently that you notice when it does.

Which is why I found the Angular team’s decision to switch from their own AtScript language to TypeScript for Angular 2 particularly interesting. The Angular team had been working with the TypeScript team for some time now, but their decision to use TypeScript directly throws a lot of weight behind the TypeScript project.

And Angular isn’t the only project leveraging TypeScript. Completely coincidentally, we at Telerik released our public beta of NativeScript on the exact same day as the Angular team’s announcement. The NativeScript project’s core JavaScript framework and CLI are both written in TypeScript, and NativeScript treats TypeScript application code as a first-class citizen.

TypeScript has benefited from a number of these announcements in the last few months. In fact, a “highly scientific” Google Trends comparison shows that these recent announcements have given TypeScript more internet points than competing compile-to-JavaScript frameworks:

tbbsuzI

Why TypeScript? Why now?

TypeScript is not the first attempt to build a language to compile to JavaScript; it’s actually late to the party. The ubiquity of JavaScript as a runtime has inspired people from a variety of programming backgrounds to recreate JavaScript as they see fit. The CoffeeScript team actually maintains a ludicrously long list of 250+ languages that compile to JavaScript. That’s right—OVER TWO HUNDRED AND FIFTY LANGUAGES. At this point I think I’m legally obligated to include this very appropriate xkcd comic.

To be fair some of these languages are fly-by-night creations or proof-of-concept implementations that have never really taken off in the wild (I’m looking at you CobolScript). But many of these languages are major engineering efforts with large ecosystems and large corporate backers. So with that in mind, what differentiates TypeScript from the pack? Here are a few things.

Differentiator #1: It’s opt-in

Compile-to-JavaScript frameworks can generally be categorized into two camps: those that build on top of JavaScript and those that abandon JavaScript completely. Most frameworks fall into the latter camp (abandoning JavaScript altogether), but TypeScript chose to build on top of JavaScript, and Microsoft has adamantly defended this approach. Here’s a telling quote from an older blog post that lays out their views:

“Some examples [of compile-to-JavaScript frameworks], like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view. We believe that with committee participant focus, the standards runtime can be expanded and the syntactic features necessary to support JavaScript at scale can be built upon the existing JavaScript standard.”

Because TypeScript is a superset of JavaScript, this means you can rename your existing .js files to be .ts files they’ll usually just work. This is a familiar pattern for web developers, as the CSS processors many of us already use (SASS and LESS for example) work the exact same way.

There are a few edge cases where valid JavaScript isn’t valid TypeScript, but those cases are generally easy to detect and fix

TypeScript includes an optional type system, which many JavaScript developers may scoff at as unnecessary, but many server-side developers view as OMG THANK GOODNESS – I NEED MY TYPES. The great thing about TypeScript’s optional type system is the optional part; it means you can use types where they make sense and omit them where they don’t, and each team can decide where that line is for themselves.

For example, the following TypeScript code defines two local variables as numbers and then uses them in a calculation:

var height : number = 2;
var width : number = 3;
console.log( "Area is: " + ( height * width ) );

In very simple scenarios like this I personally find the types unnecessary, as it’s very clear what you’re using these variables for. In fact, TypeScript will actually automatically infer the types here from the right-hand sides of these two expressions.

However, suppose you refactor this functionality into a function you intend to use across your application (and which is way more complex than this simple example). Such an approach is shown below:

function calculateArea( height: number, width: number ) : number {
    return height * width;
}

console.log( calculateArea( 2, 3 ) );

Here the three number declarations tell TypeScript that this function expects two parameters of type number, and that the function will return a number (The : number at the end defines the return type of the function itself). Here the type declarations feel more useful because this function is intended to be a reusable API. Other developers can use these type declarations to learn how to use this function, and having these types can help you maintain your code over time.

TypeScript enforces these type declarations at compile time. That is, if you use this function the wrong way, such as passing two strings rather than two numbers, your build will fail. Here’s what TypeScript’s command-line interface shows when I try to compile calculateArea( "2", 3 ):

Rm4Aw57

This can help with maintenance as every time you change this function’s API, the type-aware compiler can instantly flag all existing uses of the function, so that you don’t have to rely on a find and replace.

Although TypeScript’s opt-in nature is usually associated with its type system, that same design choice applies to everything that TypeScript offers. TypeScript has modules, classes, interfaces, and more, and if you find them valuable you can use them, but if you don’t, you can continue using vanilla JavaScript as you see fit.

TypeScript didn’t pioneer optional types, as Dart and several languages before it have had such a feature, but TypeScript has made a separate smart design decision that Dart didn’t: betting on JavaScript.

Differentiator #2: Commitment to ECMAScript compatibility

TypeScript has consistently committed to supporting the latest ECMAScript features, which is reassuring to JavaScript developers that are concerned about using a language that may diverge from the standard.

For example the latest TypeScript release introduced support for the let and const keywords, as well as support for ES6 template strings. The upcoming 1.5 release touts an impressive list of ES6 features including ES6 modules, destructuring, the spread operator, and more.

The current version of TypeScript still lags behind other use-ES6-today solutions such as Babel and Traceur (see chart below), but the upcoming version 1.5 of TypeScript aims to close that gap considerably.

TjFiOY2

Current ES6 compatibility from https://kangax.github.io/compat-table/es6.

It’ll be difficult for TypeScript to keep up with the Traceurs and Babels of the world, as those projects’ explicit aim is to support as many new JavaScript features as possible. What differentiates TypeScript is not the sheer number of new APIs it provides, but rather that it’s providing these new JavaScript features in addition to offering the lightweight type system discussed above.

One of main reasons for having this type system is that it makes all sorts of tooling possible that you can’t do with vanilla JavaScript. Let’s take a look at some of it in action.

Differentiator #3: Tooling

One of the biggest complaints of TypeScript has been that its tooling has historically only been available in Microsoft’s own Visual Studio, but this is starting to change. For instance WebStorm recently added TypeScript support, and there’s a relatively new Eclipse plugin as well.

As a Sublime Text user, I was super excited to see TypeScript’s Jonathan Turner demo a new Sublime Text plugin Microsoft has been working on at ng-conf. You can grab that plugin from GitHub to try it for yourself (thanks to @jasssonpet and @robpenner for pointing me in the right direction.). I’m happy to say that it’s a really well done plugin; all the screenshots I show in this article use it.

To see what sort of tooling TypeScript makes possible let’s return to our calculateArea function from before.

function calculateArea( height: number, width: number ) : number {
    return height * width;
}

Let’s say you try to pass this method a string, for instance calculateArea( "2", 3 );. Because TypeScript knows about the types this method expects, it knows there’s a problem, and it can inform you about it via the tooling. For example here’s what the error looks like in Sublime Text:

giCwLq3

Tooling can similarly flag problems when you try to use the function’s return type inappropriately. For instance here’s the error you’ll see if you try to use the calculateArea function’s result as a string:

BrznULB

TypeScript has a number of other features that are out of the scope of this article, but, when you use them the tooling only gets smarter. For example when you create classes TypeScript automatically knows which properties and methods are available:

3okKB1k

It can even handle more complex scenarios like class hierarchies:

4snpfpZ

Perhaps my favorite feature of TypeScript is its declaration files. I’ll let TypeScript’s docs explain the feature in detail, but I like to think of declaration files as a way to enable code completion for external libraries. The DefinitelyTyped GitHub repo contains declarations for hundreds of existing libraries that you can download and use. These declaration files are becoming quite popular, so much so that even some static type checkers like Facebook Flow are considering using them.

As of an example of how to use these, the code below includes the jQuery declaration file for jQuery API code completion.

olABd9S

This code completion is especially helpful for libraries that you’re not already familiar with. In NativeScript, for instance, we provide access to all iOS and Android APIs via JavaScript. It’s really slick, but the problem is I’m not an Android or iOS developer…so I have no idea what APIs exist. But NativeScript provides TypeScript declaration files (see android17.d.ts and ios.d.ts in this repo), and using them has made my life a lot easier. In the gif below I explore the iOS and Android APIs in Sublime Text:

dmKU74M

There are far more features than I have time to cover in this article, but these are the major features that I believe differentiates TypeScript from competing compile-to-JavaScript languages. It’s not that TypeScript is the only language with these features — for example, Dart has an optional type system, some other languages have built on top of JavaScript, and plenty of other languages have been written with tooling in mind. For TypeScript it’s the combination of these features that make TypeScript a language worth considering.

Will TypeScript grow?

The Angular announcement has given TypeScript some hype, but the most interesting TypeScript-related question to me is whether that hype will turn into actual large-scale usage. While several compile-to-JavaScript frameworks have gained a following, none have successfully gone mainstream. For instance the oft-cited TIOBE index of programming languages has zero compile-to-JavaScript languages listed in its top 50. CoffeeScript and Dart are both in the 50–100 section, and TypeScript is not on the list.

As further evidence of the lack of mainstream adoption, check out what happens if you add a preprocessor that has gone mainstream, SASS, to the Google Trend graph I showed before.

wnPCH9V

I find it fascinating that SASS is so much more popular. Five years ago I would’ve argued that people don’t use compile-to-JavaScript frameworks because they don’t want to add a build step to their app, but nowadays the widespread usage of tasks runners such as Grunt and Gulp has made build steps commonplace. The popularity of SASS also shows that front-end developers no longer seem to be concerned with having a build step in their development workflow. So if that’s the case, why are web developers using CSS preprocessors but not JavaScript preprocessors?

You could make the argument that CSS has more perceived shortcomings than JavaScript, thus explaining the increased CSS preprocessor usage, but my anecdotal experience says that’s not true. In my experience there are about as many JavaScript haters as CSS haters, or at the very least that there’s not a great magnitude of difference.

Here’s my theory: since JavaScript, unlike CSS, contains the logic for your app, people have much stronger opinions about how that logic is written. Developers want to write their web code using whatever conventions they’re already familiar with. CoffeeScript has borrowed several Ruby-isms, and has thus been most popular in the Ruby world. TypeScript was started by the same person who wrote C#, and has thus been most popular in the C# world. This fragmentation of opinions and syntaxes has kept any of these preprocessors from bridging multiple communities and truly taking off.

Why TypeScript might be different

I’ll be honest. I’m one of those web developers that has traditionally seen all of these compile-to-JavaScript frameworks as unnecessary. I like to keep my JavaScript pure, as God intended. I’m far more interested in a preprocessor that stays as true to JavaScript as possible (e.g. Babel), than one that introduces types and tooling.

But TypeScript is the first of these preprocessors that I haven’t immediately dismissed. The minimalistic approach that builds on top of JavaScript is surprisingly appealing, and the commitment to staying true to the ECMAScript standard is reassuring. But as a long-time JavaScript developer, I still find myself hesitant to take the plunge. Douglas Crockford actually summarized the way I feel in this older comment about TypeScript:

Microsoft’s TypeScript may be the best of the many JavaScript front ends. It seems to generate the most attractive code. And I think it should take pressure off of the ECMAScript Standard for new features like type declarations and classes. Anders has shown that these can be provided nicely by a preprocessor, so there is no need to change the underlying language.

I think that JavaScript’s loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.

But while I may not be ready to go all in with TypeScript myself, I also realize that those of us in the JavaScript community aren’t necessarily the target audience of these compile-to-JavaScript languages, and I can definitely see TypeScript appealing to a wide spectrum of developers.

Interestingly Crockford has also had nice things to say about CoffeeScript, as has the general JavaScript community, but CoffeeScript has yet to go mainstream. So what what might make TypeScript different? Perhaps Microsoft + Angular.

CoffeeScript has done well in the Ruby community, but has had trouble breaking out of that ecosystem. TypeScript now has the support of Microsoft and Angular, which are both behemoths that bring massive developer communities with them. If TypeScript can manage to take hold in both communities, maybe it can become the first of these compile-to-JavaScript frameworks to go mainstream.

Plus there’s the growing popularity of ES6 to consider. As ES6 gains traction, more and more people are going to be looking for tools that let them use JavaScript’s new features today. TypeScript provides a compelling use-ES6-today solution, and its type system empowers an impressive set of tooling that other use-ES6-today libraries can’t offer. Will that translate into large-scale real-world usage? Time will tell.

TypeScript Resources

I’ve come across a number of good articles and resources in the process of learning TypeScript and writing this article. These resources are listed below:

Header image courtesy of NBphotostream

Comments

  • hal9k2

    Great article, I want to start with Typescript comeing from C#, but I am not sure if I should start first with javascript, then go to Typescript, or just go stright to Typescript, someone got any hints? 🙂

    • Brocco

      @hal9k2:disqus In my opinion you should go directly to TS, it gives you everything you have in JS (ECMAScript 5) plus things from ES6 & ES7 plus types. But coming from C# there is much less of a learning curve than it is to vanilla JavaScript. That being said, play with the examples in the TypeScript playground on their site, and look at the output on the right to help you understand what the rendered JavaScript looks like and how it works.

    • Brocco

      @hal9k2:disqus In my opinion you should go directly to TS, it gives you everything you have in JS (ECMAScript 5) plus things from ES6 & ES7 plus types. But coming from C# there is much less of a learning curve than it is to vanilla JavaScript. That being said, play with the examples in the TypeScript playground on their site, and look at the output on the right to help you understand what the rendered JavaScript looks like and how it works.

    • Ryan Scheel

      TypeScript is a superset of JavaScript (like early C++ was a superset of C), so any JavaScript tutorial applies to TypeScript. The only reason you wouldn’t want to start with TypeScript first is because it does have to be compiled. But if you can set up your developer environment without much hassle, go for it.

    • Ryan Scheel

      TypeScript is a superset of JavaScript (like early C++ was a superset of C), so any JavaScript tutorial applies to TypeScript. The only reason you wouldn’t want to start with TypeScript first is because it does have to be compiled. But if you can set up your developer environment without much hassle, go for it.

    • Bo83

      do your sanity a huge favor and just start with TS

    • Bo83

      do your sanity a huge favor and just start with TS

  • hal9k2

    Great article, I want to start with Typescript comeing from C#, but I am not sure if I should start first with javascript, then go to Typescript, or just go stright to Typescript, someone got any hints? 🙂

  • Brocco

    Great article, I completely agree with the future of TypeScript due to its alignments with ES(5/6/7). I would also point you to the tool tsd which is a TS definition file manager like npm or bower but for *.d.ts files. (https://github.com/DefinitelyTyped/tsd)

    • Thanks! Somehow I’ve missed tsd and that definitely looks useful. Installed 🙂

      • Brocco

        It is quite helpful, it prevents you from having to clone the full definitely typed repo and copying in what you need. Not to mention the headaches involved with keeping them up to date. But as libs like RxJs & eventually angular2 including their own .d.ts files then hopefully the need for this tool will fall by the wayside for as many popular libs as possible.

    • Thanks! Somehow I’ve missed tsd and that definitely looks useful. Installed 🙂

    • franleplant

      The last commit for TSD is from Dec 2014 😐

    • franleplant

      The last commit for TSD is from Dec 2014 😐

  • Brocco

    Great article, I completely agree with the future of TypeScript due to its alignments with ES(5/6/7). I would also point you to the tool tsd which is a TS definition file manager like npm or bower but for *.d.ts files. (https://github.com/DefinitelyTyped/tsd)

  • Pingback: Dew Drop – March 30, 2015 (#1983) | Morning Dew()

  • Any chance the Sublime Text plugin might also work with Brackets?

  • Any chance the Sublime Text plugin might also work with Brackets?

  • I will care about TypeScript when it gets serious about ES6 support. It has way too little of that right now. I’m using ES6 features in a production app and I’m not willing to go back.

  • I will care about TypeScript when it gets serious about ES6 support. It has way too little of that right now. I’m using ES6 features in a production app and I’m not willing to go back.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1830()

  • Pingback: Dew Drop – March 31, 2015 (#1984) | Morning Dew()

  • thanks for sharing the post.i try the typescript.

  • thanks for sharing the post.i try the typescript.

  • Rob Eisenberg

    Don’t want to be rude here. This is an FYI because I find that a lot of people don’t know what really happened.

    Most of the Angular/TypeScript stuff was just marketing fluff. Angular had not been using TypeScript at all prior to the announcement and no part of Angular was written in TypeScript. In fact, the decision to switch to TypeScript only happened a few weeks (at most) before ng-conf. The TypeScript team was still working hard to convince them at that point. I know because they (the TS team) asked me and Yehuda for Decorators samples from Aurelia and Ember to help convince them to dump AtScript. At ng-conf, Misko makes clear that they hadn’t ported anything to TypeScript. If you follow the repos on GitHub, you can also see that work on AtScript continued after the conference and work with TypeScript didn’t start until a few weeks ago (at earliest). Angular 2 still isn’t built with TypeScript as of today.

    That said, yes TypeScript is a good choice, particularly as they approach full compatibility with ES6. They are pretty close with their 1.5 release. The Ember and Aurelia teams have been working very close with TS to help them tie up the loose ends and I’m really happy with how engaging they have been.

    • franleplant

      Interesting aclarations!

      In the angular key note when they show the venn diagrams of Typescript 1.4 and 1.5 I became pretty excited about TS.

    • franleplant

      Interesting aclarations!

      In the angular key note when they show the venn diagrams of Typescript 1.4 and 1.5 I became pretty excited about TS.

  • Rob Eisenberg

    Don’t want to be rude here. This is an FYI because I find that a lot of people don’t know what really happened.

    Most of the Angular/TypeScript stuff was just marketing fluff. Angular had not been using TypeScript at all prior to the announcement and no part of Angular was written in TypeScript. In fact, the decision to switch to TypeScript only happened a few weeks (at most) before ng-conf. The TypeScript team was still working hard to convince them at that point. I know because they (the TS team) asked me and Yehuda for Decorators samples from Aurelia and Ember to help convince them to dump AtScript. At ng-conf, Misko makes clear that they hadn’t ported anything to TypeScript. If you follow the repos on GitHub, you can also see that work on AtScript continued after the conference and work with TypeScript didn’t start until a few weeks ago (at earliest). Angular 2 still isn’t built with TypeScript as of today.

    That said, yes TypeScript is a good choice, particularly as they approach full compatibility with ES6. They are pretty close with their 1.5 release. The Ember and Aurelia teams have been working very close with TS to help them tie up the loose ends and I’m really happy with how engaging they have been.

  • phil85

    the new Bridge.net C# to js compiler project might be an option if you are coming from C#. Recently launched, but looks very promising. Full open source too.

  • philbot85

    the new Bridge.net C# to js compiler project might be an option if you are coming from C#. Recently launched, but looks very promising. Full open source too.

  • I really love what I’m seeing come out of TypeScript, but I”m disappointed by what I haven’t seen. They’re too slow to get all of the ES6 features in there, and I also want to see some experimental ES7 features like async functions. Those are a godsend in my current development, so until those are in, I can’t vouch too much for TS.

    • Rob Eisenberg

      They did get the ES7 Decorators proposal into 1.5, which is nice. It’s my understanding that they are also working on async/await. There are a few other things missing that are really important even for ES6 support, like system.register module format, which is the only semantically correct way to represent ES6 module behavior in ES5. But, the team seems pretty keen to tie up the loose ends. We’ll have to wait and see though.

      • Yea, I’m definitely excited about the future, I just hope it’s near future and not far future. I thought they’d have more of ES6 in there for a while now, though that was largely a misunderstanding of what they were doing initially. If they can get all the tooling and features in there in the next few months, I’ll probably hop on the TS bandwagon myself. It’s obviously got some good backing with Microsoft and Google both investing in it pretty strongly, so it may outlast some of the awesome things like Babel, Traceur, and JSPM as well.

      • Yea, I’m definitely excited about the future, I just hope it’s near future and not far future. I thought they’d have more of ES6 in there for a while now, though that was largely a misunderstanding of what they were doing initially. If they can get all the tooling and features in there in the next few months, I’ll probably hop on the TS bandwagon myself. It’s obviously got some good backing with Microsoft and Google both investing in it pretty strongly, so it may outlast some of the awesome things like Babel, Traceur, and JSPM as well.

  • I really love what I’m seeing come out of TypeScript, but I”m disappointed by what I haven’t seen. They’re too slow to get all of the ES6 features in there, and I also want to see some experimental ES7 features like async functions. Those are a godsend in my current development, so until those are in, I can’t vouch too much for TS.

    • Rob Eisenberg

      They did get the ES7 Decorators proposal into 1.5, which is nice. It’s my understanding that they are also working on async/await. There are a few other things missing that are really important even for ES6 support, like system.register module format, which is the only semantically correct way to represent ES6 module behavior in ES5. But, the team seems pretty keen to tie up the loose ends. We’ll have to wait and see though.

  • Owen Densmore

    This is dull. It would be Really Interesting if TS compiled to ASM.js.

  • Owen Densmore

    This is dull. It would be Really Interesting if TS compiled to ASM.js.

  • Owen Densmore

    This is dull. It would be Really Interesting if TS compiled to ASM.js.

  • Pingback: Programming Languages in 2014 | Kynosarges Weblog()

  • Pingback: Link Archive #1 | 0x49D1 Blog()

  • Pingback: TypeScript, Frameworks vs Architecture, Unity, and the death of IE? | Under the Mountain Software()

  • markbrown4

    You joked about using the highly scientific google trends graphs to show popularity but I see it used over and over. It only shows what people are searching for, not languages people are actively using. CoffeeScript is a tiny language on top of JavaScript, there’s not much need to keep searching google for help because you can learn it in a day or two. Something like Angular on the other hand is such a complex beast that you’ll constantly be searching for answers. The lines of code in Github per language is much more telling here than Google Trends.

  • markbrown4

    You joked about using the highly scientific google trends graphs to show popularity but I see it used over and over. It only shows what people are searching for, not languages people are actively using. CoffeeScript is a tiny language on top of JavaScript, there’s not much need to keep searching google for help because you can learn it in a day or two. Something like Angular on the other hand is such a complex beast that you’ll constantly be searching for answers. The lines of code in Github per language is much more telling here than Google Trends.

  • franleplant

    When I first learnt that the Angular team have been planning to move to TS I went back again to TS docs to see if they had improved the language and I was not amazed, in fact I was thinking on how such a horrible language could be used for Angular and how the Angular team could choose such ES6 incompatible language (see module definition for TS 1.4, it is one of the worst things I’ve ever seen). It also is a little bit bad that it comes from Microsoft from my point of view.

    Now that TS is aiming for 1.5 which is strictly a superset of ES6, all those bad things I said before have been washed away.
    We are going to be using JS to JS compilers for some time since the arrival of ES6, why not use TS that offers pretty much the same and more?
    After all, when you have big JS apps, type checking becomes a bug eraser gun.
    Looking forward to 1.5.

    But lets wait until 1.5 is officially released!

  • franleplant

    When I first learnt that the Angular team have been planning to move to TS I went back again to TS docs to see if they had improved the language and I was not amazed, in fact I was thinking on how such a horrible language could be used for Angular and how the Angular team could choose such ES6 incompatible language (see module definition for TS 1.4, it is one of the worst things I’ve ever seen). It also is a little bit bad that it comes from Microsoft from my point of view.

    Now that TS is aiming for 1.5 which is strictly a superset of ES6, all those bad things I said before have been washed away.
    We are going to be using JS to JS compilers for some time since the arrival of ES6, why not use TS that offers pretty much the same and more?
    After all, when you have big JS apps, type checking becomes a bug eraser gun.
    Looking forward to 1.5.

    But lets wait until 1.5 is officially released!

  • Rohit Jain

    I have been horrified by the fact that we are doing very serious applications using JavaScript and glorified notepads. At huge cost per function point! TypeScript and tooling it comes with may be the light at the end of this long dark tunnel.

    • ikaruga

      Have you ever used Intellij aka Webstorm?

      • Rohit Jain

        Yes, that is the “glorified notepad” I was referring to.

  • Rohit Jain

    I have been horrified by the fact that we are doing very serious applications using JavaScript and glorified notepads. At huge cost per function point! TypeScript and tooling it comes with may be the light at the end of this long dark tunnel.

  • trisys

    What about remote debugging a production typescript app deployed on a cloud server?

  • Pingback: Getting started with TypeScript | Ranganathg's Blog()

  • ikaruga

    “if you use this function the wrong way, such as passing two strings rather than two numbers, your build will fail.” I’ve been authoring complex Web apps for several years now and I honestly *can’t* remember the time when using the wrong func arguments decreased developer velocity. It seems that people who like TypeScript are OOP persons who want Javascript to be like Java/C#. As for MS + Angular, one word: React. That may be a non-issue if React usurps the throne.

  • Greg Gum

    I like to think of Typescript as Documentation for JS. (If you ever have to review modify someone else’s JS, it’s far easier with Typescript and intellisense.)

  • Pingback: NativeScript for .NET Developers -Telerik Developer Network()

  • So I tried the Angular 2 tutorial. I can’t tell if it was Angular 2 I didn’t like or TypeScript. I’m thinking it was mostly typescript. I didn’t think it was possible to make JavaScript more unpleasant, but TS accomplished that. Disclaimer: I hate Java. I’m a python programmer. I used to be a JavaScript purist until I had to build on top of a CoffeeScript project. I just can’t bring myself to leave CoffeeScript. It is so much more enjoyable to program in IMHO.

  • Pingback: Creating Components in Angular 2 with Typescript and ES5()

  • Nice post, definitely I will go for TypeScript instead of CoffeScript. AngularJS 2 will be with TypeScript, also with ionic framework will be amazing!

  • Pingback: Creating Components in Angular 2 with Typescript and ES5 - Web Design News()

  • brownieboy

    To me, Typescript looks like a solution looking for a problem. I definitely won’t be using it.

    I don’t (and never will) use Angular either, so even less reason to touch Typescript.