How I Came To Love TypeScript

love_typescript_header

When I started writing this article, the original working title was “Angular Didn’t Ruin JavaScript, TypeScript Did.” However, that’s not really the conclusion of this article (and rather “link-baity” after all). I love you all entirely too much to do that to you.

But let me start by saying something a bit incendiary that explains why I originally thought that TypeScript did in fact ruin JavaScript.

JavaScript, Welcome To Hell

I remember when TypeScript was first released, I watched a video with Anders Hejlsberg doing some demonstrations of types, classes, interfaces, and other such static language fare, all of which was transpiling down to just plain JavaScript.

And I thought, “No. No NO NO NO NOO NOOOOOOOO!”

I Hate Types

I’ve always loved JavaScript. From the moment I first set eyes on it. The first language that I learned was ActionScript and then eventually C#. And I hated C#. Well, not the syntax of C#, but I definitely wanted to see the compiler rot in hell.

It seemed to me that the compiler was unnecessarily dumb.

Consider the following…

var i = 1;
var x = null; 

Console.WriteLine(i == x);

// ERROR: Cannot assign <null> to an implicitly-typed variable

Really? There’s only one null value in the language, and you can’t deal with it?

“Well, no Burke. Because you have to know what type to set to null in case it’s not null at a later time.”

I’m not sure why we can’t just deal with that when we are actually interested in a type, but ok, I’ll conceed that.

var i = 1;
int x = null; 

Console.WriteLine(i == x);

// ERROR: Cannot convert null to 'int' because it is a non-nullable value type

You can’t set the value of an integer to null without first saying that it’s nullable. Too much manual labor has already been required of me at this point. I’m trying to solve real problems here, and I don’t have time to hand-hold the computer through basic concepts such as numbers. I’m sure there’s a good academic reason for nullable types, but I don’t care.

idontcare_spongebob

I spent so much of my time as a C# developer just fighting types. That’s all. And that’s not even considering things like reflection, a trivial affair in JavaScript that equates to an absolute circus in C#.

My fundamental problem with typed systems is that they force you to know – in advance – the exact format of every incoming data structure you’re going to be working with, which is often impossible.

Consider a scenario where you have a database that accepts a null type in an integer field. Let’s say you’re working with a module that you cannot change that is using non-nullable integer types. How do you handle the null scenario? Usually, it’s like this:

db.propertyToUpdate = sealedModule.fieldINeed == -1 ? 
    null : sealedModule.fieldINeed;    

At this point, besides feeling like a complete failure in life, you’re also incurring technical debt as you are forced to mutilate your code to please the compiler.

So if strong typing is so awful, why do so many developers like it? In a word – Increased Productivity.

Increased Productivity

Ok, that was two words.

I know I just made a case for how types cause developers to incur technical debt and then I said that typed languages increase productivity and that’s more than just a smidge contradictory, but it’s one of those double-edged sword thingies.

Types are what make an IDE more than just a text editor. More often than not, we’re working with code that we did not write, most commonly via use of a framework. The framework has an API we (at least initially) know nothing about. This means that in order to be productive with a framework, you have to not only know how to code, but also have mastered someone else’s code. Seems kind of unfair, doesn’t it?

And learning an entire framework is no small task. After 5 years, I still find myself in the jQuery docs and that’s not even a complex or large API surface. When you’re talking about something as large as the .NET framework, or Cocoa, there is simply no way to know it all without years of experience.

Let’s take just a String in C#. According to the official documentation for .NET 4.5, The String class has 8 constructors and 120 methods! That’s not even including extension methods or operators.

By contrast, the JavaScript String object has 1 constructor and 21 methods. Even with just 21 methods, I still find myself looking them up from time to time.

This is where the IDE steps in and makes it possible to use frameworks as enormous as .NET. I don’t need to refer to the string documentation, I just need to start using a string. When I do, the IDE will let me know what methods I can use, and will tell me what they do, without me ever leaving the editor and losing context.

string-intellisense

And this is where we finally get to TypeScript.

Up until now, strongly typed languages were an all or nothing bag. TypeScript is different. It brings the best parts of typing – specifically the increased productivity via IDE integration – and leaves the ridiculous casting part as optional. I didn’t fully grasp the power of this until recently when I was doing some NativeScript development.

The Value Of TypeScript

I’ve been doing a lot of NativeScript work lately, and NativeScript treats TypeScript as a first class citizen – a BFF really. In fact, the entirety of the cross-platform modules in NativeScript (tns_modules) are written in TypeScript. AppBuilder For Visual Studio provides a TypeScript template for NativeScript, so I decided to give it a shot and see what it’s actually like to use TypeScript in Visual Studio.

If I’m writing a simple application in NativeScript, I start with the markup for a page (mobile view). As I do that, Visual Studio prompts me with some events that I can use, such as the oft utilized loaded event in NativeScript. This is done because NativeScript provides a schema defintion to Visual Studio for the markup. But it’s Visual Studio that provides the editor magic. I can also create a TextField without having to remember what the markup is for one.

xml-page

Consider the following code from a NativeScript page which handles the loaded event. This can be written with standard ES5 JavaScript like so…

var viewModule = require('ui/view');

exports.loaded = function(args) {
    var page = args.object;
    greeting = viewModule.getViewById(page, "txtGreeting");
    greeting.text = "Hello Indeed";
}

This is CommonJS, which NativeScript also supports as a first-class citizen. The problem with this is that I frequently find myself going back to the NativeScript documentation to try and remember what properties are on what objects and what objects are passed to which events.

Here is what is happening in this code…

  • The loaded event is defined.
  • A reference to the current page (xml) is obtained.
  • A reference to the TextField is obtained.
  • The text of the TextField is changed to “Hello Indeed”

The problem is that this is just JavaScript and I have to know a lot about NativeScript here. I have to know about the loaded event, I have to know what object the event receives, I have to know how to obtain a reference to the page. I have to know that I need the view module in order to get that reference and I have to know what the method on the view module is and what parameters it needs. Lastly, I need to know what method to call on the control instance to set it’s text.

That’s a lot to have to keep up with and we’re not really doing much. Also, none of this code is checked at design time, so any null object or method references are going to result in an unceremonious application crash.

Now lets re-write this with TypeScript and see how this gets simplified.

Since TypeScript is a first-class citizen in NativeScript, we can re-write this in a .ts file

I’m just going to start under the assumption that I know that I need a loaded event based on what I built in the XML.

export function loaded() {
    //...
};

So far, this looks familiar. Now we just need to know what type of event the loaded function is going to receive. According to the documentation, all events receive an observable. To use an observable, we need to import one.

import * as observable from 'data/observable';
export function loaded(args: observable.EventData) {
    //...
};

If that import looks terrifying to you, then you are just like me. That’s actually ES6 syntax for modules. One of the neat things about using TypeScript, is that it implements quite a bit of ES6 where it can, and uses proprietary syntax where the spec is incomplete or missing.

In this case, we are saying, “Import everything from the observable file and put it all in an object called observable.”

Now watch the magic unfold after we have gotten this far. I know that I need a page reference, so I check the args object.

args-page

I’m given two options – eventData and object. These are the only two properties that are coming in on the event. I can safely assume that object is what I need. Now I need to cast it to a page. I need the Page module to do that, and TypeScript is aware of the type.

import * as page from 'ui/page';

And now I can cast the object to a Page type.

args-to-page

More ES6! I can use the let and const keywords in TypeScript. I could also just use var and that would be fine too. Now that I have the page and TypeScript knows that it’s a page object, I can use the getViewById method to get a reference to the TextField.

get-view-by-id

That returns me a generic view object, which is subclassed by all the UI components. That means I need to cast it to a TextField type.

set-text

There’s a lot going on in that GIF. Notice that I make a mistake and try to set the text via a method. TypeScript catches this for me and points out that this is a property, not a method. Also notice that my import of the TextField type looks a tad funkier than the other imports. That’s because ES6 modules allow you to import any property or method exposed by a module as a single import. This allows you to cherry-pick just want you want from a module.

My favorite thing about all of this is the fact that I know, without a shadow of a doubt, that when I run this, it’s going to work. If not, it’s not going to because I made some stupid mistake. The browser is forgiving. Native applications are not. Errors aren’t just shelled to the console. They result in nasty app crashes and in the case of mobile apps, the app just crashes and doesn’t tell the user anything at all. I’ve always thought this was a horrible user experience.

The Best Part

Now the best part of all this? I can still do this…

var x = 1;
var i = null;
console.log(x === i); // FALSE

HAHA! I win! All of the benefits of the IDE and none of the soul crushing insanity of strongly typed systems. As they say in the sales game, it’s a “win-win.”

Should You Use TypeScript?

It depends.

I think that due to the browsers’ incredibly forgiving nature for your crappy code, you are just fine with plain JavaScript. I’m not convinced that the browser environment demands such stringent expectations of your code. I think you will iterate faster without it to be honest.

However…JavaScript is being written in more and more places, including being used to create native mobile application. NativeScript is just one example. In these cases, I imagine that you would want the power of TypeScript.

I also think that TypeScript encourages you to learn ES6. That’s imperative since ES6 is coming at us at a screaming pace. It’s a pretty big change, and you can’t avoid it forever. TypeScript is a great way to ease into some of the essential ES6 concepts, such as modules.

In any case, TypeScript has made a fan out of me. I know that I prefer to use it in my NativeScript projects, and I’m looking forward to doing more with it, especially as Angular 2 looms on the horizon.

TypeScript support is available today in the AppBuilder Plugin For Visual Studio.

Header image courtesy of photosteve101

NativeScript

Comments

  • Great article, makes me want to switch

    • burkeholland

      I think it can. Ironically enough, TypeScript AND ES6 support in VS Code seems to be better than in Visual Studio (go figure).

      In fact, I’ve been VERY disappointed with the Visual Studio 2015 support for TypeScript via the plugin. It works so well in NativeScript because it’s treated as a first-class citizen. If you have to transpile it using Visual Studio, it will lead to generalized anxiety disorder and self loathing.

      Glad you liked the article! TypeScript with NativeScript is pretty freakin awesome.

    • Martin Molina Alvarez

      VSCode instellisense is great. There are plugins for other editors
      (Atom, Sublime Text …) that works so good too. I use Typescript in Atom
      and I am so happy with the results.

    • guyAtHockeyBiasDotCom

      Superbly.

  • Gibran Malheiros

    It was really interesting to read this article, great thoughts!

  • Matthew Leathes

    Interesting that someone coming from an ActionScript background would
    initially feel antipathy towards TypeScript – I’m also from an AS
    background and I’ve really missed the power of being able to use a
    language that’s typed and properly object-oriented. Although I haven’t
    had a chance to give TS a proper go yet I’ve been watching its
    development with interest and waiting for the opportunity to give it a
    try…

  • derekgreer

    Nice article, Burke.

    • burkeholland

      Well thanks Derek! It’s no Los Techies article, but you know, I try.

  • You wrote “My favorite thing about all of this is the fact that I know, without a
    shadow of a doubt, that when I run this, it’s going to work.”

    Are you really that sure? I think you may be reading too deeply into the IDE’s method checks.

    Take your last three lines of code:

    let mainPage = args.object;

    let txtGreeting = mainPage.getViewById(‘txtGreeting’);

    txtGreeting.text = “Hello Index”;

    You are certain this works? Alarm bells are going off in my head. Casting an unknown, untyped object to a concrete type is like an “if” statement. The “if” is always…. is this object actually a type, or not? I don’t know how TypeScript handles your casts, but I bet it’s either going to immediately throw a runtime error when the cast fails, or it’s going to return null and let the next line of code fail.

    Don’t believe me? Change the “txtGreeting” id on your view to “greeting”. Or change it to “txtGreeting ” because of an accidental typo later. Or change X or Y or Z… changes *over there* can affect changes *over here*.

    Of course, you know this, we all know this, we just don’t speak of it… but why do we talk with such certainty about the infallibility of code that is just as susceptible to failure with-or-without your types? Look what you said again:

    “My favorite thing about all of this is the fact that I know, without a shadow of a doubt, that when I run this, it’s going to work.”

    Without. A. Shadow. Of. A. Doubt.

    Maybe your IDE can reach deeper. Maybe it can catch a rename of a property in the code and yell at you. But we all know — no matter how tight we squeeze our code into types and interfaces and IDE plugins and bells and whistles — the runtime errors won’t stop. So why is this myth of static typing = reliable code keep getting perpetuated with such wild claims?

    I think the only way to know that code works is to run it. Run it with lots of inputs and test that the right outputs come out. *That* is certainty… but only certainty for the inputs we offered to our tests! That’s as good as it gets, and we can go really far with that.

    So my suggestion, I guess, is that more focus be put on testing our code reliably, and less focus on Intellisense.

    • burkeholland

      GOOOOD points made here. “Without a shadow of a doubt” is not true. I should have said “Much more confidence”. It’s far from perfect and that’s the truth.

      Even more important is not to use the compiler as a unit test, which is the crutch of typed systems.

      I still think that meeting in the middle between types and the typeless void of nonsense that is javascript is the best of both worlds.

      • John Galt

        Welcome to why your “optional” typing is a bad idea too.

        If the original object was “Page” instead and was of type “Page” originally or implemented an interface of type iPage then you could be sure. This is how real languages work and yes, it makes it hard to write originally if you don’t know what you’re doing, but it makes good code where you’re infinitely more sure you’ve done it right. Blind casting is just a really bad approach and is the result of badly written javascript where any property can change types at any time.

        In short, intellisense isn’t the point to typescript and typescript only helps you prevent this kind of thing if the entire system is strongly typed everywhere. As soon as you allow javascript stupidity where variables can be set to different types of things in it’s lifecycle you’ve blown up your security and made your application less secure. Intellisense is a convenient side effect of good coding to strong typing. Javascript (like all script languages without typing) allows lazy programmers to be lazy. That is not a good design feature, it’s just crappy apps in the making and bad developers getting away with bad coding.

        See Twitter switching to Java if you have any questions.

        • fatfisz

          Providing Java as an example of a “real” language?
          Java isn’t a real language. It doesn’t protect you from side effects as much as functional (Real) languages do.

          • John Galt

            Don’t disagree. It’s just more of a real language than JavaScript and every other scripting language (PHP, Perl, Ruby, Dart, etc. etc. etc.) made.

          • fatfisz

            What is a “real” language anyway? Who are you to judge what is “real” and what is not? Are your comments as fake as the glorious language that makes it possible to post them?

            And lastly, can you provide any source that proves your claims about changeable types making applications “less secure”?

          • John Galt

            “real” programming languages have type-safety and were not designed to script another application (In the case of JavaScript that’s a browser). PHP, Perl etc. are scripting languages because they’re scripting a runtime within HTML instead of generating HTML from code. (i.e. if you look at typescript + knockout or angular etc. you’ll note that the presentation markup is separated from the code unlike PHP and Perl)

            This separation of concerns combined with type safety and compilation instead of interpretation is what makes the difference between a script language and a real programming language. I dare you to find even one enterprise scale PHP, Perl, JavaScript etc. application that isn’t bug ridden. This is a large part of why twitter converted to Java and why others have either blown their brains out trying to fix the mess created by the scripting language choice (Facebook) and ultimately moved huge portions to a real language. They don’t work beyond play toys, they don’t scale, and they are not reliable. (The best being PHP + direct database access. Makes for so many SQL injection attacks it’s comical.)
            C++ also has it’s issues because of buffer overflows and unchecked strings if not done right, but at least the tools exist in C++ to do it right and just aren’t used or for speed are “optimized out” of code causing issues. With scripting languages the tools aren’t even there and it teaches developers really really bad coding habits (variable transmutability, operator overloading in the same method signature, etc. etc. etc.) which seem like great ideas for novices and badly educated beginners and then once you have to maintain one of these monstrosities you realize just how bad it is, and that there is no real way to properly fix the mess created when you finally educate yourself on how to really program effectively and without being lazy.
            Once you realize this, that’s why you seek out Typescript to try and fix JavaScript since you have no choice in a browser and use real programming languages like Java or C# etc. in the backend. (why anyone uses mvc or asp.net, php, jsp etc. on a new project and not Angular, Durandal etc. in the browser other than for enforced security at login, I don’t know but hey, if you must, at least use an MVC or asp.net model, don’t go scripting programming logic inside your HTML!)

          • I’ve read Atlas Shrugged. You, sir, are no John Galt.

            You said:

            “I dare you to find even one enterprise scale PHP, Perl, JavaScript etc. application that isn’t bug ridden.”

            Your ignorance is a barrier for you to fix, not anybody else. They exist, I’ve seen them. If you haven’t, it’s because you haven’t looked hard enough. There are many large applications written in languages you don’t call “real.” Generalizing a situation is not fair if you’re not using a fair representation of all of the examples.

          • John Galt

            Sure they’re are some. But they also will prove the generalization. They (i.e. Facebook) will have spent huge amounts of money maintaining a platform on a scripting language instead of a real programming language to do so. Facebook took $500 million investment from MS because they needed cash so badly to fix their bad choice of MySQL and PHP. Instead of doing a re-write they hacked the heck out of both to make it work. But by the end of it, it cost them billions more than what it would have cost to just write it in a real language.
            Can it be done? Sure. But what you’ll find when you do find one is someone that was so invested that they perceived that they had no choice but to continue and dump piles of cash into it with dubious benefit over scrap and re-write.
            I stand by the generalization because as I noted previously in other comments, it’s possible to do, but those exceptions prove the point. Why did a generalize with my handle? Because of tl;dr because if I’d typed any more no one would read because they’re lazy and just like most people that claimed to read Atlas Shrugged and just skimmed it because it was too hard and then judge it from their incomplete knowledge they would have made lazy assumptions.

          • Have a good day!

          • fatfisz

            You didn’t prove anything and didn’t provide any sources, you are just religiously repeating what you believe in.

            You are blaming the language for the bad habits of some programmers, but it’s not the language’s fault. That’s like saying that crayons are bad, because some children try to eat them instead of drawing with them. Every child needs a teacher, every programmer needs a teacher too. Or at least some good learning source.

            And I guess you’ll have something interesting to say about PayPal’s moving away from Java’s code bloat to Node.js. I’m sure they don’t care about security and only want to be cool.

            I don’t seek TypeScript and I don’t need to fix JavaScript. JS has its bad parts (which don’t hinder you at all if you really know the language), but the lack of types isn’t one of them. If anything, it motivated me to write better code. Types won’t protect you from mixing up the order of arguments if they have the same type. Creating a consistent API will.

            Of course I don’t deny the speed benefits from using types, but as JS engines get better and better, they won’t matter that much. They already don’t matter in most cases.

      • Burke,

        That’s the thing… I know you don’t mean what you said, at least to the explicit words. Obviously, you couldn’t, because it’s really easy to find ways to break it. But why did you say them, and why do others make this argument?

        I’ve written apps with others on both sides of the static/dynamic side, and they’re all just as prone to being buggy. Types are not the barrier when writing accurate applications — it’s human nature. We’re fallible human beings that can hold only so much in our heads at one time, yet we’re building these “perfect” systems (perfect in the sense that a computer does what it’s told) that are very complicated with many, many details. *These* are the two worlds that have to come together, humans vs. computers… and it’s not that the compiler check is not enough, it’s… it’s…. *irrelevant*.

        And every static typing fan will say so. They’ll talk about how great it is to have a compiler check, but all you have to do is point out that applications in static languages are buggy, too… and they’ll say, “oh yes, of course, we should test too.” But if it’s not enough… why does this myth about static typing correcting errors persist? Why do we talk about Typescript as “enterprise level” when we’ve all seen multiple apps in other “enterprise level” languages that are so buggy, the application fails?

        It’s like running head-first into a wall, getting knocked-out, waking up, declaring that our head is not enough to break through the wall… then we put our head down and charge again. Because everybody knows…. the human head is a great tool for breaking down walls!

        • burkeholland

          I think it’s because we so desperately *want* it to be true. Compilers are like a warm blanket for the developer soul.

          • Haha, good point! I actually never thought about it that way… 🙂

            Thanks for the blog & discussion, take care,

            Darren

  • Great article, thanks for sharing.
    My question is, if TypeScript tries and feels like ES6, why should I try and learn TypeScript? ES6 already has most of the features.

    • Anton V

      ES6 is not typed.

      • John Galt

        … and ES6 isn’t available in most browsers (and the ones that do support it only support some of the features, even Chrome doesn’t have 100% coverage), so you need to transpile anyhow. Typescript allows you to write like ES6 with type safety, and compile that code to ES5 which is supported by most browsers (and even ES3 if need be).
        Hence Typescript lets you use a semi-sane version of JavaScript, adds typing and lets it work on today’s browsers. Even when all browsers support ES6 Typescript will still give you full type safety while generating ES6 code.
        Win-Win.

      • burkeholland

        Totes. ES6 won’t give you the types and therefore your IDE will never be as smart as TypeScript enables it to be.

  • enzi

    You know nothing, Burke 😛
    JavaScript developers always claim to be “more productive” and complain about the “soul crushing insanity of strongly typed systems”.
    Then they update some plugin or change some code and sure as sunrise, after the next deployment I will read `something is undefined` or `x.y is not a method` in my browser console.

    Ah, the productiveness.
    A strongly typed language will protect you from harm and warn you when things don’t add up anymore.
    On the other hand, JavaScript (which I always envision as a drunken hippie) will just shrug and drive your app right against a tree. Then it’s up to you to find out where in your code you’re using that outdated function name or have to use a new object because stuff got moved around.

    • burkeholland

      FOR THE WATCH! 🙂

      In over 10 years of programming, I have not ever been bitten by something that the compiler would have otherwise saved me from. Unit tests alone get you closer to confident, and dumb luck gets you the rest of the way there.

  • John Galt

    Translation: A script-kiddy comes of age and learns how to really program. It’s a really clear progression througout the essay showing the “light bulb” going on. (I don’t mean this in a mean way, but it’s important to understand that scripting is not programming.)

    JavaScript generates horribly buggy code that is also horribly slow. Why? Because there is essentially no design or compile time debugging and because JavaScript doesn’t know about types, everything is an object which is SLOW.

    Real programmers understand both of these and understand that real apps are complex and have a huge number of dependencies. The only real way to be able to maintain these as the application gets larger is through strong typing. This means that you have to get off your lazy ass and put in the work that Burke moans about at the beginning and define everything strongly so that if you change one thing, the compiler errors immediately. The best example of this is an API changing and your JavaScript web/native-script app blowing up silently because it had no way of telling that the objects coming back changed or the definition of a rest interface changed.

    Real developers generate typescript interfaces for the data that’s coming through using T4 or similar and do the same for every endpoint as a static function call that wraps the Ajax call and ensures that strong types are passed everywhere. Then when you change something in the backend, the front end blows up on compile, your continuous integration fails and you don’t get magic new errors from your customers. (Think every single php, ruby, JavaScript app ever written because you can’t write enough unit tests to handle all of these permutations and combinations.)

    And no, this isn’t a rant about real developers using C++. It’s one thing to do garbage collection for you (real .NET developers do it themselves too) and another to be punished with the horrible syntax of C++ for no real reason, especially now with native compiling in C# and even java. The point is that only strongly typed languages are real programming languages and result in maintainable, useful code that can scale to enterprise level applications or even consumer grade applications of any significant complexity.

    • Oletros

      No sure if serious

      • John Galt

        100% serious as evidenced by all of the startups that end up rewriting their applications when they grow up in real programming languages from the toys (Ruby, PHP, Perl etc. etc. etc.) that they started with.

        • Oletros

          “from the toys (Ruby, PHP, Perl etc. etc. etc.)”

          Someone that calls Perl a toy is just not serious, trying to start a flame bait or just ignorant

          • John Galt

            Completely serious. I’ve written enterprise scale apps in Perl because that’s how you did it at the time. It’s brutal to maintain and the code you write is just plain difficult to unwind which makes building a large team to support said application almost impossible.
            Doing the same thing with a properly designed app with separation of concerns in Typescript + Angular or Durandal with strongly typed interfaces and view models automatically generated using T4 from Web API C# backend using Azure Elasti-scale and Entity Framework is a joy. Developers can specialize and update code and builds fail at compile time because there is nothing loosely typed anywhere in the entire system.
            Further the presentation is properly separated from the code that controls the presentation unlike Perl/PHP while the DTOs are strongly typed across domains to ensure code doesn’t magically break in the front end because of backend changes.
            That’s a real architecture with real programming languages (typescript to be fair still is not, but it’s a heck of a lot closer than JavaScript and it’s the best of a pile of bad options in browsers) that can scale to millions of users (150 million so far) trivially for very little development cost compared to what others have spent on the system outcome using scripting languages.

            And no, I’m not saying that C# + Typescript is the only way to do it. But whatever language(s) you choose to use the result needs to be the same: Strong typing throughout the system and across domains with design and compile time error reporting and no optional typing anywhere. Entity Framework happens to add sql injection protection and strong typing across the database domain as well which is another huge win that alternatives do not provide.

          • Kasper Peulen

            ” (typescript to be fair still is not, but it’s a heck of a lot closer than JavaScript and it’s the best of a pile of bad options in browsers)”

            What about dart ?
            https://dartpad.dartlang.org/0dfeb25a33be007e1d0f

            And don’t come with this dart is dead crap, 50+ google engineers are daily working on the dart sdk and the dart ecosystem: https://github.com/dart-lang/

          • John Galt

            Sure. Dart is another alternative. The difference is that I don’t see major projects from Microsoft or anyone else switching to Dart, but I do see Google projects (Angular) switching to Typescript instead of their own Dart project.

            The interesting question is if we’ll see either typescript or Dart become a native language of the majority of browsers any time soon. It would be nice to see Typescript become first class and do full compliation binaries that the browser uses. People that know JavaScript would be ok with it, and man it would speed up the web and make websites better.
            (still wouldn’t fix developer.telerik.com ‘s certificate error 🙂 )

          • Kasper Peulen

            If google would have made angular 2 in Dart, it wouldn’t have been possible for javascript users to use angular 2. This is because of some limitations in Dart (that are soon to be removed). Typescript can be converted to readable Dart, so writing it in typescript makes sure that angular 2 can be written in Dart: https://angular.io/docs/dart/latest/quickstart.html as well as in ts, es5 and es6.

            Btw, there are big projects written in Dart. Google’s own AdSense for example.

            > The interesting question is if we’ll see either typescript or Dart become a native language of the majority of browsers any time soon

            I don’t think there is any change of seeing dart or typescript becoming a native language, but not sure how much that matters. At least for Dart you can develop in dartium (which supports dart natively). For typescript, it seems to me that compiling to javascript is good enough. Debugging with source maps seems fine.

          • burkeholland

            I know for a fact that Google is always trying to reverse engineer everything back into Java. Why that is, I’m not quite sure. I just know they are HUGE fans. That’s why we see projects like Dart and why they will not be dying. Google will keep them alive for their internal projects. Just look at GWT. It’s still alive and well and OMG!

          • Jason X Bånd

            “I don’t think there is any change of seeing dart or typescript becoming a native language”
            TS is a (partial) implementation of ES6 with interecepts of ES7. So yes it will be native some day. Whether or not that extends to run time type-checking, probably not.

          • Jason X Bånd

            dart is dead. the fact that nobody told the 50+ google engineers doesn’t change anything

    • burkeholland

      I would say that I was first a real programmer, and now a script kiddie. And also a much happier human being. 🙂

  • fatfisz

    I think that your problems with C# “var” were caused by you having a misconception about what it really does. In C# it’s only a syntactic sugar – the compiler has to determine the type anyway. It is really useful for cases where you have types like this: Type<Type1, Type2>. Without “var” you’d often have to type that twice in one line (declaring variable type and invocating a constructor).

    In ECMAScript that is not the case: variables can change the type in the runtime, and the “var” keyword means something entirely different than “var” in C#.

    This is a broader problem – people writing in language A, then coming to the language B which has some similarities with A (syntax, keywords) and expecting the language to work the same way.
    I saw a lot of comments about JS prototypal inheritance being bad – coming from people writing in languages with class inheritance. And often those people don’t have any arguments that make sense, it’s only them being close-minded and not learning the new language from scratch and understanding it completely.

    • Jason Shinn

      I agree with your main point completely – don’t complain that language A is bad because it’s not language B – learn to use the language you’re using, or use a different language. Burke’s point about typing still stands – there are a range of tasks and problems where weak typing allows you to more directly express your logic in an intuitive way than does strong typing.

      • fatfisz

        I agree. That’s why in the end i prefer pure JS.

  • Great article Burke – I featured it in this week’s issue of http://csharpdigest.net/digests/67.

    • burkeholland

      Thank you @jakubchodounsk:disqus! Very kind of you. Will promote.

  • Pingback: Giner Web and Data Services | Web | Front End Fuel # 21()

  • PaulTopping

    I like your post. It helps a lot to explain, especially to people who have only written relatively small JavaScript programs, why one needs types. If you write large programs with more than one programmer, then types let you keep things straight and communicate programmer intent.

    There’s also a potential boost in run-time efficiency with strong types. It is very difficult for the JavaScript processor to “know” that you are only going to assign numbers to a given variable. It always has to allow for the possibility there’s some path through the code where you assign a string to it. However, if you declare the variable’s type, then the system can generate optimized code safely.

    All of these things are becoming more and more important as people writer bigger and bigger apps in JavaScript. TypeScript is a really great language. I am looking forward to using it in most of my future projects.

  • Pingback: Will Angular 2 be a success? You bet! -Telerik Developer Network()

  • Morten Øien Eriksen

    Nice article Burke, I just wanted to give an example of a fairly large Typescript project – the UI for our web platform (the back-end is Java).

    https://github.com/enonic/xp (modules/admin/admin-ui)

    Regards,
    Morten