As Javascript slowly becomes a less salty language thanks in part to ECMAScript 2015 (formerly ES6) amd ECMAScript 2016 (formerly ES7), the question of whether to choose a superset of the Javascript language or write POJ (Plain Old Javascript) is a question we need to ask ourselves.
My experience with TypeScript is rather minimal, whilst investigating Javascript frameworks a few months ago I used TypeScript for a little while to get a feel for it and see what it would offer me in terms of workflow and efficiency. The fact the project would be built in .NET which means using Visual Studio 2013 was also a point towards TypeScript (of which Visual Studio fully supports).
What does TypeScript offer us?
For a long time Javascript has suffered from some pretty serious flaws, which supersets and compile-to-Javascript languages like CoffeeScript have tried to solve. TypeScript takes the concept a step further and gives us strong typing and static compilation. It allows us to discover flaws in our code before they’re pushed into production, if your code isn’t valid, it won’t compile.
Whilst we can achieve the same thing in conventional Javascript, it usually requires the use of one or more front-end CLI tools that check our types, ensure our code adheres to the styleguide, handles minification and ensures that everything will work in non-spec compliant browsers.
A handy feature of TypeScript courtesy of its strict types is that it addresses issues with the loose equality operator ==. In conventional Javascript doing so would coerce the types, converting them before they are compared. In TypeScript however because you defined the types being compared beforehand, TypeScript knows when you’re trying to compare using == two values with non-matching types like Number and String and produce an error.
It also addresses a few other quirks in Javascript that I won’t go into. It is worth pointing out that TypeScript obviously doesn’t fix Javascript, but because it compiles to Javascript, it prevents us from making basic and sometimes hard to see errors in our code before we even get to run it. Your TypeScript code is compiled to resemble the good parts of Javascript. You get classes, modules and all of the other nice features that we’ve grown to love in ES2015 and future specifications.
You also have to factor in to the equation that TypeScript made its debut in 2012, before we had the great choice of front-end tooling and support we do today thanks to the concentrated efforts of the TC39 committee.
If you’re working in a large codebase (the purpose of which TypeScript was originally designed for), then there is a benefit to TypeScript how it strictly enforces types. It is more verbose and designed to catch errors earlier before they’re introduced into a codebase.
If you’re already working with a language such as Java or C#, then you will probably hate Javascript itself and prefer to use TypeScript instead which will feel right at home. Using TypeScript within a C# heavy project makes a lot of sense and helps reduce the context switching efficiency drop you traditionally run into when switching from front to back-end (or vice-versa).
While TypeScript offers many other features, the strong typing is definitely the biggest and unique aspect of TypeScript that sells it. As witnessed in TypeScript 1.5, a lot of ECMAScript 2015 features were rolled into it and presumably TypeScript 1.6 will roll in more features from the current and future specification.
What does conventional Javascript offer us?
Before transpilers like Babel hit the scene, we had Google Traceur and while it allowed us to write future Javascript, we didn’t have support for at the time only early draft concepts of what ES2015 would look like. In 2012 we didn’t have much, in 2015 we have a lot of choice.
In the latest spec we get; classes, arrow functions, modules, let and const, for..of iterator, enhanced object literals, generators, weakmaps, proxies, symbols, promises, tail calls, reflect api, module loaders and plenty more. It turns out your regular run-of-the-mill Javascript has grown up, it offers the kind of things we could only dream about 5 years ago.
However, conventional Javascript still lacks static types. But is being able to verbosely define your types that big of a deal in Javascript? The benefit of types (besides preventing errors) is they make it easier for other developers to understand your code.
However, given that ES2015 finally brings order to the court of Javascript, IDE’s like Webstorm are now able to appropriately check your code (especially now we are not all using different implementations of prototypal inheritance).
Conclusion
As much as I think TypeScript is great, I believe using it is a niche preference that boils down to; if you’re comfortable with C# or Java, you use Visual Studio as your IDE of choice, you have a lot of type guards in your code (instanceof checks), you are working on a massive codebase and finally: you work on a large team and you want to avoid styleguide clashes, ensure that all developers are writing the same code, the same way.
TypeScript is a great way to ensure that code is consistently written and appropriately checked before being compiled to Javascript and pushed into production.
If you don’t fall into the above categories, then standard Javascript is also fine. Honestly, at the end of the day, TypeScript and Javascript are the same thing, they’re both Javascript, one is just more stricter and C#/Java like than the other.
At face value, the only difference between TypeScript and Javascript is the static types and honestly, if you can live without needing to declare your types and you’re using other tools that catch your coding errors (or a great IDE), then TypeScript looks the same as modern Javascript. If you need type checking, you can always just use instanceof and typeof to check types before using/mutating them.