Damn you JavaScript typing
Lately there is a new trend to use static typing in JavaScript projects. Now, why would you do that when one of the strong points of JavaScript its dynamically typed nature? The simple answer: there is no real reason to use static types in JavaScript, but as we know it, there is nothing simple when it comes to software development.
One of the arguments that some developers use in favor of static types is that they will catch errors at compile time instead of runtime. Well… guess what? JavaScript was not meant to be compiled, it came to existence as a frontend language meant to run directly in the browser. So although nowadays there is a need to compile JavaScript applications(ex: React, Angular), I don’t think this is a good argument on enforcing static typing. Type correctness does not mean code correctness. It is a known fact that type checking has little effect on overall bug density and that responsible unit testing have greater impact on this.
So, at the moment of writing this article, there are two popular ways of writing static typed JavaScript: using Flow library or with Typescript (superset of JavaScript developed by Microsoft).
Although Typescript became popular with the release of Angular 2, you can write any frontend application with it(even React and Vue). You only need to configure and compile it using Babel. Basically Typescript is just ES6 JavaScript with static typing(primitives and interfaces).
Flow is a library that promises you will code faster, smarter, confidently and bigger. From my experience with both Typescript and Flow, I find none of this statements to be true.
There is no way you will code faster using static typing. As you get more and more deeper into static typing you will find that this will create more syntax noise, that in the end will make the code harder to read and maintain. If you are fluent in old fashioned JavaScript you will see that there are some other things that become harder to implement:
- Generic functions & polymorphism
- Higher order functions
- Object composition
So instead of spending time developing new features or unit testing, you will lose a lot of time of thinking how to make your JavaScript code pass type checking.
Personally, I’m not totally against static typing, but I think it’s a very fine line from improving your project to totally destroying it altogether.
So why the harsh title? Because I’ve seen its evil head first hand on multiple projects. Poorly or draconic configured typings on projects can slow development a lot and make code really hard to maintain. This is specially true when static typing is added in a more advanced stage of the project or when using strict typing(banning any/Object/Function types) in combination with any third party libraries. In the second case you will need to create types for every event callback you use from that library.
So does this mean there is no use of static typing in JavaScript projects. No, but it means you should take a lot of things in considerations when deciding to add it in your project: type of the project, stage of the project, how comfortable is the team with it and how loose or strict the typing rules will be.
Truth be told most of the projects only need some loose primitive typing, object interfaces and an agnostic approach in development. JavaScript is indeed evolving and we must make good use of new functionalities, but if you are in desperate need of strict typing you probably choose the wrong technology for your project in the first place.
