CoffeeScript? TypeScript? How about JavaScript?


Please note that the following post is simply my biased opinion. I struggle to understand the reason to write JavaScript using a compiler such as CoffeeScript or TypeScript. I come from a background rife with, I mean rich with, statically-compiled, strongly typed languages and frameworks. I worked with TypeScript once at a previous job because I had to. It was anything but pleasant and I’ll leave it at that.


I’m fortunate to have freed myself of such obstacles and burdens, and am now extraordinarily happy to be writing full stack JavaScript! If my enthusiasm about this change isn’t obvious, please let me assure you that I’m now much happier. It’s important to note that I’m not implying that there’s anything wrong with statically-compiled or strongly-typed languages, as there certainly is not. It just isn’t my cup of tea anymore.

Given the dynamic nature of JavaScript and lack of static type-checking, then perhaps I’m writing lower quality code riddled with bugs not caught at compile time, right? The answer is unequivocally, no! I’ve never been more motivated, productive, expressive, and efficient. Nor have I written such quality code with minimal bugs, or been able to fix bugs as quickly, once discovered. Perhaps you’re wondering if I’m writing consistent JavaScript that follows best practices and styles without a compiler? The answer is yes! I don’t mean to toot my own horn here, but rather to indicate that the lack of static compilation does not necessarily result in increased bugs and lower quality code.

Statically, there are plenty of ways to ensure JavaScript code is properly written and follows recommended styles and best practices. Not to mention that writing high quality JavaScript becomes second nature after a while, and you naturally tend to follow the same good patterns that you’ve learned. You should also always write proper tests, which is a best practice and another defense against bugs, and helps ensure intended functionality. Let’s not forget that code review’s are also a best practice and should be used as well.

JavaScript vs. Compilers

So why the use of these compilers and what are the benefits? The answer is that I have no good answer to that question. Should there also be a RubyScript and PythonScript that compiles to Ruby and Python respectively? You should probably not be a JavaScript developer if you do not like, or want to write JavaScript in my opinion. Is it a quirky non-perfect language? It absolutely is, but it’s getting better all of the time. Many of these quirks and omissions are being addressed in ECMAScript Harmony, aka ES.Next.

There is only one reason to use one of these compilers in my opinion. It’s if you’re an advanced expert JavaScript ninja guru that doesn’t like native JavaScript and wants to make things more terse and shortcut driven. If you’re not the aforementioned expert, then I truly believe that you’re only hurting yourself by avoiding native JavaScript. Why you ask? The answer is that JavaScript is becoming ubiquitous and is a serious and formidable language. It’s found baked into all Web and mobile environments, servers using Node.js, as well as in databases (e.g., MongoDB), and lately even hardware-level processing (e.g., arduino).

I read a lot of blogs, newsletters, books, articles, papers, documentation, MDN, and so on related to JavaScript. They all contain code written in native JavaScript. I’ve rarely read something where the author presents the code in TypeScript or similar. In the rare occasion that I do, I stop reading immediately since I’m only interested in JavaScript and not some other version of it.

If you ever plan to, or are interested in working with a JavaScript-based database such as MongoDB, you need to know how to write JavaScript. You can’t query MongoDB in TypeScript or CoffeeScript. You also can’t write server-based JavaScript for Node.js using these compilers without pre-compiling, or shouldn’t, even if you can.

One of the primary arguments people give for using a compiler like TypeScript is the ability to write JavaScript that leverages pre-officially published ECMAScript features (e.g., ECMAScript Harmony). For me, however, this is a moot point as there are many ways to leverage these features without using these compilers, and are also able to do so using native JavaScript syntax.

What about those seemingly millions of JavaScript libraries and frameworks flooding the landscape and on GitHub? This includes the big ones like jQuery, AngularJS, Underscore, and so on. I highly recommend learning JavaScript inside and out so that you can not only read and understand the source code, but debug it as well. Oh yeah, and speaking of debugging, whether you are debugging JavaScript in a browser, or using Webstorm for Node.js server code, that involves native JavaScript too.

The last point I’d like to make deals with collaboration with others (a la GitHub for example), or taking a job in a JavaScript shop. The benefits of mastering native JavaScript should hopefully be obvious here. Can you imagine walking into work on your first day in a serious JavaScript shop and asking how to fire up the ‘ol TypeScript compiler?


Again, if you’re an advanced expert JavaScript ninja guru, then perhaps a compiler is OK? I doubt you would even be such a guru though, if you avoided learning and writing native JavaScript in favor of one of these compilers. If you’re worried about static checking and styles, try some of the build tools out there (e.g., Grunt, Gulp, Node, NPM, etc). Many of the plugins work really well. Perhaps use CoffeeScript or TypeScript to see the compiled JavaScript for a given code bit, and then mimic the output in your native code. In either case, do yourself a favor and master JavaScript first.