In this author’s opinion, yes.
In many enterprise applications there is an advantage to strong typing. Enterprises are often large operations with many actors. Ebay has many actors playing the role of development and deployment. So each actor will need to understand clearly how to maintain pieces of the enterprise software. Strong Typed applications have always ‘suffered’ from being be very verbose, at least that is how some developers feel. However this developer feels that’s what provides more context to the compiler and the actor, more effort sure, but in principle you get better maintenance.
Teams are often composed of a diverse group of people, and many developers would like to think they have a unique style of development, something that makes them different from everyone else, having pride in your work. But that’s not always an advantage, it can become a problem when you are on a large maintenance team. Searching for what needs to be done is a huge waste sorting out another’s code style and any arising frustration leads to unhappy teams.
How does Typescript make ES6/Javascript better?
Legibility for Modules, Classes and Inheritance
Modules will produce namespaces, and encapsulation like we used to with closures. Modules let us break up reusable parts of the codebase and consolidate them without relying on a runtime mechanism like requirejs. In typescript many imports require only one line of code.
Import { Component } from ‘@angular/core;
Compared to the same in vanilla javascript:
var angular = require(‘@angular/core’); var Component = new angular.Component();
Further compounding things, the above would likely never work as Angular won’t work in vanilla javascript, but it’s just an example of declaration soup.
In the above ‘Component’ is a class, and we make an instance of it, like we do a javascript object. But with typescript we no longer need to be simulating a class structure with intimidating closure hacks. Instead we declare it on one line:
class Component implements AnotherComponent{ … }
Further, above we have also ‘implemented’ the AnotherComponent in our Component. This is an example of inheritance, and in vanilla Javascript you would have to make an instance of Component and then extend it manually, or merge it or whatever. It gets messy.
Ok, Whats does typescript add?
Reflecting back to Java, we can see how Strong Typing can ensure development of a good product. Java’s strong typing ensures Java’s compiler knows exactly what you want, and further keeps data mutations in check. In contrast Javascript is a breeding ground for mutations and overloading. With that in mind we can infer that Typescript will bring more stability to a development pipeline.
But… What do we give up?
In the spirit of transparency, before I preach about the virtues of typescript, let’s touch upon on what a developer loses. First, the ‘while’ loop, but that’s fine, cause that damn while loop is the devil, and second the ability to not work in ‘strict mode’.
In both cases, I’m not crying for my loss and neither should you, on a large team both of these can break a codebase.
Yes, you can use Jquery
I am not advocating bringing jquery into your typescript projects, the new native queryselector has pretty much killed jquery’s relevance for DOM manipulation. But, If you have legacy code, old libraries, etc, you can validate them with Ambient Declaration:
declare var $:any;
Just place that in your root script and you should be all set to use the namespace lodash and anything inside it. The any is telling the compiler to infer the entire module.
Interfaces and enums types
I have utilized both to represent ‘states’ in my Angular projects, In conjunction with something like Redux creating predefined models that are either of these types gives us a state machine that is checked at compile. The compiler will always let us know if a type is switching where it should not, so your states will be battle tested before even entering the field.
Both of these just give us ‘smaller’ and ‘leaner’ instances of an object or array.
Enums are just a way of declaring types that don’t have to have explicitly set values to initialize, while Interfaces will want a default value set for each property, even if that value is null.
I really like having these two types. When I used both vanilla Javascript and Actionscript I would always end up creating instances of class like items for scenarios where an enum or interface would have been better. The larger the app got the more it seemed to chug because of all the inherited items I did not need. Thank you native types.
Advanced Typing
With this strict typing though comes a concern, as a javascript developer, sometimes you WANT an argument to accept TWO types, or more. Javascript’s flexibility as a language that infers everything is wonderful, but we still could benefit from Typescript reducing the amount of computation at runtime, to infer stuff.
Wouldn’t it be great to have more leverage than just using ‘any’ all over the place? Well you can do that with an advanced mechanism like ‘Union’:
Red: color | string
Above we have red, but red can be either a very specific color object or a native type of string. Further, as illustrated below, if the compiler does not validate it as either, the compile will exit and never finish compiling, which will lead you the developer to fix the issue before it ever sees runtime.
The compiler makes certain that our method is getting what it expects, So in cases where you find yourself making type checks in methods ( if you do this at all ) you can feel safer knowing the compiler has reduced possible silent failures from 3rd party modules or others codebases.
if( Red instanceof color ){ //Do color thing }else{ //Do native thing }
On a relevant side note, If you are using a markup system like UML or any kind of system where you figure out your types and interactions before development, advanced typing mechanisms are simple enough to give you the flexibility of javascript without sacrificing the whole typing mechanism as a whole. You can develop a solid strategy of type assignment and method declaration.
In Conclusion
Typescript brings structure to a team project and legibility to a large codebase. Whether you employ the javascripts inference ability any type or use Typescript Union’s in ambiguous cases Typescript adds to javascript, and really does not take away. If you are a new developer I would still encourage you to familiarize yourself with vanilla javascript first, and then typescript, typescript is still javascript, but being able to work with the superset of typescript will benefit you and any large team your on or may manage.