Typescript is Hard

So, for a work-project, the language choice handed down by the Overlords-Of-Jobbing has been TypeScript.

You see - where I work, we build websites, and we build the infrastructure to support those websites. We also build platforms to support the website-supporting-infrastructure . . . so we like to iterate quickly and be as agile as possible in our workflow.

For the current clientele we're servicing it has been decided that TypeScript on the Babel toolchain would be the most productivity-boosting language we could use, and as a result I've had to learn this new-fangled language with all its idiosyncrasies.

Now, TypeScript is awesome, it supports both static and dynamic typing, lambdas, the entirety of JavaScript and all the associated libraries and frameworks which come with JS.
TypeScript is awesome.

TypeScript:
- will mend fences
- paint your garage
- spay your cat
- neuter your dog
- rent Clerks II on DVD
- run you a nice hot bath after a long day

But, the more I tried to "learn" TypeScript, the more I realized that TypeScript was missing something fundamental, something so earth-shatteringly basic that I couldn't even wrap my head around it.

Before I reveal this missing piece, let me just dive into how awesome TypeScript is. One of the interesting things that makes JavaScript great for beginners, is the very permissive language rules. Essentially, in JS, if you're guessing that something "should" be typed (on the keyboard) in a certain way, then you're probably going to get the right syntax without much hassle. As I was learning JS, it kept occurring to me how often my syntax guesses were actually right, let me give you an example.

In JS, if you were to try to declare an object of some type, which held some variables, there are several ways to do it:

// To define an object of type "Person"
// 1

function Person(first, last, age) {
    this.firstName = first;
    this.lastName = last;
    this.age = age;
}
var myFather = new Person("John", "Doe", 60);

// 2

var Person = {
    init: function(first, last, age) {
        this.firstName = first;
        this.lastName = last;
        this.age = age;
    }
};

var myPerson =  Person;
    myPerson.init("John", "Doe", 60);

// 3

var Person = function (first, last, age) {
  return {firstName: first, lastName: last, age: age};
};

var myPerson = Person("John", "Doe", 60);

While these are all subtly different, they're similar enough to allow a n00b to forget about the hassles of syntax and get on with his task. Please allow for some syntax/logic errors as I don't have the desire to fire up my trusty editor right now to verify it all compiles.

Enter TypeScript - the vast, all-knowing language must-have that will cook your dinner and spoon-feed it to you when you want.

TypeScript does something unique - it imposes a formal syntax as the one and only expected way to create objects -

export class Person {
    var firstName: string;
    var lastName: string;
    var age: number;

    constructor(first, last, age) {
        let self = this;
        self.firstName = first;
        self.lastName = last;
        self.age = age;
    }
};

let myVar = new Person("John", "Doe", 60);

With this being said, I'd like to point out that I'm still very happy with TypeScript at this point. We've got well-defined classes, we've got inheritance, heck - we even get interfaces and proper types which throw compilation errors when you try to stick a string into a numeric type. All is still good and well in the land of TypeScript. So what's the glaring problem, you ask? Well, I was implementing something the other day, and I realized I'd need a linked list in order to allow for the nice dynamic insertions, removals and lookups I wanted. Arrays in TypeScript, I think even in JS are based on linked-lists, but I really wanted the code to reflect this as it was code that not-only was the basis of a larger feature-set, but also code that I may not be maintaining directly after release. I really wanted the implementation details to be crystal clear for any coder at any level, and a linked list is the universally accepted data structure on which my solution is based. I could have put a comment in the code about how the arrays are based on linked-lists, I could have changed my solution - but no. It's a universally accepted solution, well tested and well taught. It's also a universally understandable solution - granted that you have the correct data structure supporting it. So, I started typing import 'LinkedList' from ... When I realized that my IDE didn't know what a linked-list was . . . strange. I went to Google, and tried to search for it there, given how TypeScript comes with some of the default containers one would normally want . . .but nothing. Interestingly enough, I found some libraries which add this data structure and some more, but those would cause an external dependency which I was trying to avoid. That's when it dawned on me. TypeScript has an incomplete Standard Library! Yes, you are welcome to flame me and hate my guts, but it's true. If one were to look at Python, PHP or even C++ for that matter, you'd find that their std::* or 'It-Ships-With' library set includes most of what you'd want. However TypeScript does not. I can appreciate that the language is lean and mean, but this caught me by surprise - standard data structures are something I kind of took for granted, especially since I had spent some time in Python and C++ building an eBook formatting system and never ran into this problem - not even once. C++ especially comes with a 'First Create Matter' mentality, so I was expecting it, but their standard library is second to none. PHP is geared towards HyperText, but again - their standard library is second to none, especially given what the language was intended to do. But for something this trivial, to have to roll my own (Yes, 20 minutes well-spent: Writing the class, and some unit tests to prove to myself it was working) just boggled my mind. Fair enough, it's only 1 data structure, in 1 language, for a fairly standard thing one would be expected to do on a browser page, but still . . . it would have been nice. After a lot of searching and reading, I found that this was almost intentional - since the entire idea of TypeScript is to implement as little as possible over pure JS to keep everything blazingly fast, I can nearly forgive this, and since you have control over how the JS is emitted, it all becomes 1 large file, which means you don't force the browser to hit a remote site where all the third-party code is hosted. Also, many of the third party 'standard' stuff doesn't require attribution - even for commercial use, I can also forgive the lack of meaningful standard stuff . . . but what I can't forgive is the amount of time I have to spend researching the respective repositories - reading their issues list to find out if the developer fixes bugs quickly. Checking around the web to see if the component is being used by trusted sites and developers - if there's a community following etc. With other types of languages, that's a given - C++ would have a nearly rock-solid standard library with official language versions, which have lots of documentation in 1 place . . . same with Python, PHP, etc. So, instead of complaining, I propose that we all jump onto a single bandwagon - we set up a standard-library repo which typescript developers can check out if they need a clone of the C++ or Python standard libraries. I'll be putting something together at some point - purely by bundling my entire utils folder into a standalone repo and giving it some epic name. So, while the language itself boosts productivity, it also kind of hinders it with the nature of the design philosophy, and that makes TypeScript hard.