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.

- 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.


Popular posts from this blog

Writing a home-monitoring system using python + internet...

Hmmm, what's that, you say? A Python home monitoring system? Why would anyone want to subject themselves to that kind of abuse? Well, I , for one, amd lazy ... it shows in my work, it shows in my lifestyle, it shows in my weight .. and it shows in the way I write code. I'm the guy that will spend 2 days writing an app (which is available for purchase on the Google App Store) because I'm too lazy to get up and get myself a credit card ... because I'm too lazy to get up and scratch in the drawer for my old credit card so I can purchase stuff from Google Play ... Before you go ranting that I expend time and effort to write an app which costs $3 ... you must remember that I am a programmer .. code it like water to me - extremely bitter, and mostly salty water, but water nonetheless ... I eat code, I think code, I dream code and I can churn out code if I want to because it has become second nature to me. So it's simpler for me to just write it myself than it is to

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.

Self-Motivation is hard!

Ok, so it's been a while since my last update. I've been grinding away at this game so hard, and made very little progress as you can see here.   I've been grinding away at this game for a while now and I've learned a lot. The number one thing I've learned so far is that I should have spent a few weeks learning a really good game engine and then just used that.  I've spent so much time just writing boilerplate and infrastructure, that I've yet to build a decent game.  I remember complaining so much about the lack of game engine choices and how hard they are to learn - but, it's even harder writing everything from scratch. And when I say "everything", I mean EVERYTHING!  I've created resource loading classes, scene management, view trees, sound management, audio queues, playlists, rendering pipelines, camera classes, starfields, parallax scrolling, state management.  Everything, painstakingly written from scratch.  For one redeeming moment