TypeScript – is it worth using?

I’ve always had an issue with Javascript transpilers and offshoots that promise to make Javascript better. In this article, I’ll look at both Typescript and Coffeescript.

Coffeescript was the first compiler that appeared on my radar a few years back, and after spending a bit of time playing around with it, I wasn’t convinced.

Yes, it has some niceties that make working in Javascript easier, but unlike Javascript, it’s not something that the majority of developers have dealt with. It’s not a syntax most developers have dealt with. And the learning curve is arguably bigger than just jumping into Javascript.

Now this isn’t an attack on CoffeeScript at all, it’s an observation on all the various “languages” and abstractions that require some form of “compiler” to turn them into something the browser understands. My guess is that most of these tools aren’t going away seeming as they’re open source – but what if they do? Or what if they introduce massive breaking changes? I know these things can all happen with the “traditional compiled languages” too, but they are generally very stable and maintained by entities with years of experience.

Typescript and Angular 2

With Angular 2 making its’ way out the door recently, I noticed it focuses on TypeScript. Being an Angular 1 fan, I decided to put my reservations aside and have a nosey into the language they’d chosen.

Being dynamically typed is one of Javascript’s best and worst features – with great power comes great responsibility. It’s pretty easy to end up in a mess of Javascript types and functions, especially once you expand beyond a “one person dev team”. TypeScript aims to make it easier to keep track of models and arguments.

Having spent many years in C# land, the idea of having proper types and interfaces intrigues me, mostly as it allows things to be swapped in and out with a known contract, which, in theory at least, saves many hours of testing and rebuilding stuff.

Let’s look at a real simple “Shapes” example, built purely to explore a few different areas of TypeScript. Every shape is based off of a polygon, so we create a IPolygon interface which defines everything we’ll need (for this example)

import { Color } from "../Color";

export interface IPolygon {
	name: string;
	fill: Color;
	stroke: Color;

	toString(): string;
	draw(): void;
}

Now let’s setup a square using our IPolygon interface

import { IPolygon } from "./IPolygon";
import { Color } from "../Color";

export class Square implements IPolygon {
	name = "Square";
	fill = Color.Black;
	stroke = Color.Red;
	width = 0;
	height = 0;

	constructor(size: number) {
		this.width = size;
		this.height = size;
	}

	toString() {
		return this.height + "px " + this.width + "px";
	}

	draw() {

	}
}

You may have noticed I setup a Color object too – this allowed me to explore setting up static variable. They look something like

export class Color {
	hexCode: string;

	constructor(hexCode: string) {
		this.hexCode = hexCode;
	}

	static Red: Color = new Color("#f00");
	static Black: Color = new Color("#000");
}

I then added a “canvas” that we can “draw” to which accepts IPolygon’s and has a draw function, which calls the draw method on each shape.

import { ICanvas } from "./ICanvas";
import { IPolygon } from "./shapes/IPolygon";

export class NullCanvas implements ICanvas {
	items: IPolygon[];

	constructor() {
		this.items = [];
	}

	draw() {
		for (let i = 0; i < this.items.length; i++) {
			let item = this.items[i];

			item.draw();
		}
	}

	add(item: IPolygon) {
		this.items.push(item);
	}
}

Coming from C#, it has a familiar vibe to it – it feels almost object orientated. But it doesn’t feel like writing real Javascript. Or more correctly, “old” Javascript. This may not be a bad thing, and after an afternoon of playing around with TypeScript I have grown slightly fond of it and it’s ways.

So to answer my original question – is TypeScript worth using? I’m still not convinced that having another layer over Javascript is worth it, especially with the likes of ES6, but the benefits for bigger teams could far outweigh the downsides given the safety it offers. For smaller projects and new developers though, I think ES6 offers a much more standardised approach to building applications for now.