CoffeeScript and TypeScript are a Burden
Saturday, 17th August 2013, 11:21

I try to keep up on new developments in the coding world, or at least the areas I'm most involved with, on a daily basis. Sometimes I read about interesting new libraries and think, hmmm, one day that could be useful. Other times I'll see something and think, hmmm, that may well be the alternative to AngularJS I was looking for, you know the thing that gives me the bits about it I like whilst not forcing me to deal with all the bits I hate.

I think basically what I'm saying here is, I try my best to not be a backward looking stick-in-the-mud who refuses to evaluate new technology fairly and change my ways just because it requires learning new things. I'm all for learning new things.

Just because I have a light-box plug-in that works, doesn't mean I'm not looking at new alternatives. Even though I think jQuery is a great library which is hard to match for functionality, doesn't mean if something else pops up that is better, I wouldn't give it a go immediately if it provided enough support for the browsers I have to target.

I'm all for progress.

What is CoffeeScript?

Simply put, CoffeeScript is, as ridiculous as it sounds, a simplified scripting language that has to be compiled into another scripting language, that being JavaScript.

I'm not exactly sure what it aims to do primarily, but what it does do is take something as simple as this...

    alert "I knew it!" if elvis?

...and compile it into this...

    if (typeof elvis !== "undefined" && elvis !== null) {
        alert("I knew it!");
    }

So you can look at it as a whole new scripting language, which standardises and simplifies a number of things in JavaScript, but that compiles into JavaScript.

The website also claims something which is so obviously stupid, so obviously impossibly untrue, that I have to call them up on it at this point. They claim that CoffeeScript:

This cannot be true for three reasons, firstly CoffeeScript compiles into JavaScript, and therefore can only be as fast as equivalent JavaScript. It's not magic, if the resulting code runs faster than something, then it can't be the equivalent of it. It might be similar, but it can't be the same.

Secondly, there are ways of coding JavaScript which will run faster under one engine but slower under another, so the whole "faster" thing is always going to be relative. And thirdly, it claims it creates "readable" code, and there are a few tricks in JS that make things go faster, but definitely do not produce readable code.

What is TypeScript?

In some ways, TypeScript has more valid aspirations than CoffeeScript, because it seems more aimed at fixing issues with JavaScript than overly simplifying it into a language that looks more like LUA. It seems much more interested in allowing you to define proper classes (rather than pseudo-classes) in a cleaner way, and attempts to offer more C-like type checking.

Languages Are a Compromise

Some people think that the ultimate goal for coding should be the following one line program source:

    create application Photoshop;

And then the compiler would make you a complete version of Photoshop that does everything you wanted. Other people look at the following code and think the world went downhill the moment most coders couldn't understand what it did:

    mov eax, 4
    mov ebx, 1
    mov ecx, str
    mov edx, str_len
    int 80h

Of course we need to do things closer to the former for people who don't get any closer to programming than whatever Excel lets them do, and we need things closer to the latter because without which we wouldn't have any software on our Intel computers at all to even run Excel.

But the web world is a slightly special case, because we need languages which are quick and easy to develop complicated web applications in, that can run very fast on the server side in things like Node.js, and be responsive enough on the client side in the browser.

That requirement makes whatever language we use an almost unique compromise between speed and ease of use, which is why JavaScript is such a good language for it. Google's V8 has proved it can do a very good job of compiling JavaScript into machine code on the fly, clearly this cannot be as fast as compiled C code, which in turn can never quite match hand coded ASM, but it's good enough.

So Why Are CoffeeScript and TypeScript bad?

JavaScript isn't that hard a language. Really it isn't, if you struggle with it then maybe coding isn't for you. The point of a language is to control a computer, and the best languages give you complete control.

Using machine code gives you all the control over the computer that the CPU has. Using C/C++ gives you almost the same level of control, at the expense of a bit of speed, since C/C++ compiles into machine code and most compilers let you add assembly inline if you need to.

JavaScript is nowhere near that low level, so it isn't anywhere near as complicated. There is no reason to simplify it even further with something like CoffeeScript, especially as when it comes to debugging things you have to look at the generated JavaScript anyway.

That point alone makes CoffeeScript just plain stupid, because everybody spends a significant portion of their time debugging. Of course you might be way smarter than me, and happy to keep two sets of visualisations of your code in your head at the same time as you debug. I will admit tho, I'm not that smart.

So why are you using it? Because you like the code it outputs? Just write your own JavaScript that way then, what's the point in adding this extra step? To save you typing? Just get a decent text editor which supports templates then, or copy and paste your patterns.

Anytime you spend with CoffeeScript is time better spent learning more about JavaScript, and if you think you already know everything about JavaScript and are simply using CoffeeScript to save typing, then you probably don't. Good coders use the best tool for the job, not the one that requires the least typing.

And the whole debugging point also applies to TypeScript. Sure the type checking it adds is very nice, but just bear in mind that is a substitute for knowledge about how your code is working and how JavaScript deals with things. You might be crying out that using TypeScript means you don't have to worry about a number of normal JavaScript things.

The thing is, you do, even if you don't think you do, you really do. The only exception to this is possibly where you have reinvented the entire wheel and not used a single JS library from any other source. Any other time, you need to be thinking clearly in one language, not two. Not having to worry about something stops you worrying about it, but using third party libraries means you should still be worrying about it.

I've lost count of how many times documentation for a library I'm using has been inconsistent, or thin on the ground. I know from releasing my own libraries the amount of time it takes to add information on how it works, people mostly do this sort of thing for free in their spare time, so you can never rely on the fact they added the extra overhead to list how stuff works properly or well.

What I'm saying here is if you use other people's code, stuff won't always work, or work how you expect, and you need to go poking around in there to find out why or how. If you spend your time in a different language, and both TypeScript and CoffeeScript are essentially different languages, then switching between the two is going to slow you down.

Yes But...?

I think basically what I'm trying to say is, there isn't any compelling reason I can think of to use CoffeeScript or TypeScript. There may be nice features in both, but none of them are remotely necessary. JavaScript really is not that hard a language, and it can do some really funky interesting things.

Any time you spend using pseudo-languages like the aforementioned, is time wasted. You could be learning about getters and setters, or interesting new usage patterns for objects, or just plain learning the basics that keep catching you out when simple logic statements don't quite work how you expected.

The better you get at JavaScript itself, the quicker you will develop code and the easier it will be to debug it. These alternatives might help you make less mistakes, but mistakes are how you learn, and the more you learn about JS the quicker you'll read it, and the quicker you read it the easier you will be able to understand other people's code.

And the faster you'll find your bugs, and the faster you'll find bugs in other people's code, and the better everything you do will be all round.