There are no plans currently for any kind of abstract class syntax. If you have some compelling scenarios that would benefit from their implementation in JavaScript, please open a thread in the "Discussions" section (perhaps under "Language Specification"). Thanks!

How about:

module Shapes {
    // Interface for all shapes
    export interface Shape {
        draw(surface: Drawing.ISurface): void;
    }

    // Helper base class - implements lots of common code for all shapes
    export class ShapeBase implements Shape {
        constructor(public x: number, public y: number) { }

        draw(surface: Drawing.ISurface): void {
            // I CAN'T IMPLEMENT THIS - I'M AN ABSTRACT BASE CLASS AND CAN'T DRAW
            throw new Error('I want to catch this at compile time!!!');
            // THERE IS NO REASON I SHOULD NEED TO IMPLEMENT THIS
        }
    }

    export class Circle extends ShapeBase {
        constructor(x: number, y: number, radius: number) {
            super(x, y);
            this.m_radius = radius;
        }
        
        draw(surface: Drawing.ISurface): void {
            // This is OK - I know how to draw myself
        }

        m_radius: number;
    }
}

This sort of thing crops up a lot and it would be nice to be able to handle this in TypeScript rather than resort to runtime errors if a call occurs to a method I am forced to implement even though it doesn't make sense.

Or is there an alternative way to stop ShapeBase objects being created? Then at least I could catch the error at compile time, even though I would still be forced to implement a method that can never be called!

It would be great, in my previous example, if we could write something like:

export abstract class ShapeBase implements Shape {
    constructor(public x: number, public y: number) { }
}

export abstract class ShapeBaseEx extends ShapeBase {
    constructor(public x: number, public y: number, public foo: string) {
        super(x, y);
    }
}

and have the compiler not complain about draw not being implemented in either. I.e. classes should be able to extend/implement base classes and interfaces but remain abstract (non-instantiable) and not be forced to implement all methods of the parent item. It is preferable that those method be compile-time (type) checkable rather than handled with runtime errors.

Abstract classes are not needed to model common idioms in JavaScript in a strongly-typed fashion, so I think this feature deserves less priority than other features like "this" typing.

However, abstract classes are very common in object-oriented programming. In our code base, we already have a several of instances where we are doing the following to "mimic" abstract classes:

class X {
    public abstractMethod() {
        throw new Method("This is an abstract method");
    }
}

If advatanges of using TypeScript over JavaScript are minimized to losing time using a new environment I don't want to wrk with, I will stay JavaScript. Thanks.