Skip to main content

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.

Comments

Popular posts from this blog

Finding a Game Engine is Hard

Well, if you're new here - congratulations on finding the most useless blog on the planet. If you're not new here, thanks for coming back to another installment of "And he just keeps moaning!", this weeks episode deals with how hard it is to select a Game Engine for your development needs. As I've mentioned in the past, there are many things to consider when developing a game: Storyboarding Specification document Game Engine Resources (art / sound / levels) Time constraints Return on Investment Since I've preached about the Specification Document all throughout my last post , I'll save you a little bit of reading by saying it's nearly the most important part of the entire process - nevermind having a compelling game - without the specification document, nothing gets built. Storyboarding is kind of like the specification document, but it allows you to draw little screens of the game as you imagine it to be, without too much detail.

A few thoughts on Game Development

For those of you who follow my blog, you'll notice that I talk about building games, but I never really release anything useful or fully playable. I'm more interested in studying the individual parts of game development, without really caring about building a game as a whole. Well, for the most part this is perfectly acceptable, as I'm not a game developer by trade, and my bread and butter comes from being a utility developer. I've defined utility developer as someone who codes a variety of things without specializing in any specific discipline. As a self-taught developer, it's been hard for me to pivot into a role where I'm classed as a game developer by trade. This is all good and well, but I still want to talk about game development as a whole - specifically how to get a game off the ground. If you've been following any blog about game development, or any programming course which walks you through the process, you've most likely heard of all the jar

XBOX ONE Game Dev is supposed to be hard.

So I recently took the plunge and joined the Xbox One Creators Program with Microsoft. It turns out that it's supposed to be incredibly hard to build these little games we see all the time, and for the most part, it is. Not only do we have to deal with the fact that the XBOX One does not use the stripped down PowerPC architecture that the Xbox360's used to run on, we now have to contend with the fact that it's basically running Windows 10. I remember the good old days when win32 and GDI (Graphics Device Interface) were sufficient to get a decent game running on a Windows PC - especially if the game wasn't too resource intensive. Then came Direct(X/3D/2D/11/12) with all its COM (Component Object Model) Glory -> which, perhaps most asinine of all -> is still being used today. Getting into the creators program costs a little bit of money, and that's mostly to keep the chancers out and cover administration fees. After that you really only need to abide by the