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.
Just to add—alongside improving readability of code—if you’re on the kind of project that sees the value of unit testing as a safety net, then strong typing can be seen as an additional safety net built right into the code. Why some people outright reject the additional safety that strong typing provides (ie. Crockford reduces it to “sweetness”/syntactic sugar), whilst still valuing the principals of unit testing is beyond me.
@Phillip
I can definitely see the value is strong typing. My experience with a more verbose language like C# and strong typing definitely reduces the amount of errors you can run into before you get to the compilation step, as the IDE will pick them up.
I like TypeScript, but I generally find that my modern workflow of ECMAScript 2015/2016 Javascript, ESLint, Webstorm IDE and Babel for transpiling is enough to cover most aspects for the projects I have been working on. On-top of essential unit tests, end-to-end tests and code coverage reporting. I think it definitely serves a niche for large teams, developers more comfortable with strongly typed languages like C# and for developers who want the added safety net in their code.
While I know that TypeScript offers more than just strong typing, to me the strong typing is the biggest and most unique selling point of TypeScript, something that not even the ECMAScript 2016 specification will have.
But it seems the latest release of TypeScript 1.5 and future releases are essentially rolling in ECMAScript 2015 features like; modules, let, const, template strings, declarations and assignment destructuring and a few others. Some of the once unique selling points beyond strong typing have been replaced by ECMAScript 2015 (probably thanks in part to the work the TypeScript team have done).
Having said that, I don’t work on projects comprised of large teams which is where something like TypeScript is a godsend. Especially if the team is comprised of developers in multiple timezones where it can be hard to get everyone on the same page. I like TypeScript, but I feel like strong typing for me personally isn’t enough for me to use it over conventional Javascript.
I am starting to really like TypeScript. I also suspect the decision by the Angular team to write Angular 2.0 entirely in TypeScript will put even more wind in the TypeScript sails.
It is however a big shift for many, but I personally think it’s worth it.
Hi. I think a very important, but often ignored, feature of TypeScript is that it gives the IDE the ability to provide much better intellisense and autocompletion. While very good IDEs (for example, Webstorm) can do pretty well with javascript, they still can’t compare with the coverage we get when using TypeScript. TypeScript’s langage service means that many code editors have very complete code-intel plugins available. This will be more important to some developers than others, but for me, having the IDE provide completions and intel is a real time saver, and can make the overhead of using a transpiled langage worthwhile.
After spending some time away from TypeScript, I recently returned to see if they had fixed some of the problems that had driven me away previously. I was happy to see a number of significant improvements, especially the addition of ‘tsconfig.json’, which allows you to avoid writing endless /// tags. (!)
I am a Python / Javascript programmer and used to be PHP programmer for a long time and a bit of Perl. These are weak typing languages. Having Javascript without strong typing is fine to me.
It is strange that Java / C# views are encouraged to be used in Javascript. Because strong typing usually brings deep hierarchy of objects and over-usage of design patters – to “link” not-so compatible types via ioc and interfaces. I already compared web related Java code and Python code. Python usually has much less of class inheritance nesting and much less of abstract interfaces. These are increasing the size of code base, unlikely improving readability.
Javascript is much more like Python / PHP / Perl / Ruby weak typing language and it is fine. Weak typing is just a different concept, different paradigm – not worse, just a different one. With strong typing you sacrifice a lot of things – your code is much longer and the development is slower. Bugs are partially catched up by unit tests, anyway.
@Dmitriy — strong typing really doesn’t equate to over usage of more traditional OOP principles.
> strong typing usually brings deep hierarchy of objects and over-usage of design patters
Not at all, it’s a certain breed of programmers who bring this. Not strong typing.
If anything, the ES6 `class` keyword does more to promote deep hierarchies than TypeScript does.
TypeScript is just as useful within functional programming. It’s up to the programmer how it’s used.
I understand what leads you to this view, but it’s important not to confuse historical usage of strong typing in other more ridged languages such as Java with modern usage within JavaScript.