Statically typed Javascript : Why and HowFrancisco IgorBlockedUnblockFollowFollowingJan 4In the last months I have found good experiences using Statically typed Javascript.
For example, using React with Typescript.
It helps a lot to build a robust Web development, with statically typed Javascript support, ready for a complex and enterprise-level projects.
TypeScript is maintained by Microsoft, but it’s not the only option for statically typed Javascript.
Flow, from Facebook and Dart from Google are similar options among a long list of implementations.
Why so many “big companies” are doing really big efforts to introduce static typing in Javascript development in the last years?Why static typing ?Static typing have some good benefits over dynamic typing in a professional environment:Catching bugs earlier in the development cycleBetter testing plans, more robust and specificEliminate some classes of bugs in already deployed systemsImproved code-assist (auto-complete, suggestions, documentation), linting (code quality and standards) and other tools for IDEs/EditorsEnable compiler optimizations, refactoring and better minifying.
Cleaner looking and self-explaining code.
Better maintainability in the long term.
For people working many years with dynamically typed Javascript, it might sound very complex and difficult to do a “switch”.
Taking advantage of the dynamic types and flexible syntax is a good help to improve the development efforts, but thinking about real-world and complex applications, in the long run, you can be surprised with a lot of errors, difficult to catch without type checking.
Consider the following code:function addNumbers(x, y){ return x + y;}It looks simple, but it could have unexpected results with untyped parameters (3 is dynamically converted to string "3" before adding, changing to a concatenation):addNumbers(3, "0"); // => "30"Now consider the following example using static typing.
There is no chance for unexpected results.
function addNumbers(x:number, y:number){ return x + y;}The migration problemMigrating a big Javascript codebase to TypeScript could be a big pain.
But starting new projects with a structured and statically typed Javascript code could save a lot of efforts and time in the long term.
Even if you are planing to adopt static typing in current projects, this migration could be done gradually.
Testing plan could be more strict for Typescript code, but current Javascript code could be tested as usual.
Mixing different Javascript flavours is not a problem.
Typescript has a defined procedure to migrate Javascript code.
Concrete benefits in numbersAs stated in the study To Type or Not to Type: Quantifying Detectable Bugs in JavaScript, there could be increasing benefits in adopting static types for projects.
A mean of 15% of extra bugs detectable in systems that already have completed successful tests, only adding static typing checks and annotations.
Over 400 test-cases, Flow successfully detects 59 of them and TypeScript 58.
Running a binomial test, at the confidence level of 95%, percentage of detectable bugs for Flow and TypeScript falls between 11.
5% and 18.
5% with a mean of 15%.
Achieving these results doing static typing checks and annotations, gives light about the process of static-izing current Javascript code.
It could involve extra work, but the effort is worth of it.
There is a BitBucket repository of test cases here.
Also, the annotation tool they used to facilitate the process.
Knocking down the mythsSome people could be thinking about concerns and reasons to avoid using static types, adopting TypeScript or another typed language.
There are some common misunderstandings about typed Javascript languages:Too strict: Loos of dynamism is often related to loose of productivity, but in the long term, and in growing codebases, this strictness is desirable and sometimes mandatory for enterprise-level development.
Standards: While TypeScript is not an official Standard (nor Flow), it’s becoming an industry standard.
Javascript has defined some basic types, and his standards are product of many years of “industry standards” becoming official in the latest specifications.
Difficult to learn: Basically, these languages are supersets of Javascript, adding only type declarations and some language constructs.
It could be natural to adopt these extra concepts without effort.
Difficult to migrate and integrate with existing code.
You can perform migrations gradually.
Most of the common conversions to apply are very straightforward.
Also, there are projects helping to do this migration easier, like TypeWiz, and doing automatic type assignments for the most known Javascript packages and modules, like DefinitelyTyped .
Lack of Support.
Actually TypeScript is a open source project with Apache 2.
0 License, actively maintained and with a growing community.
Language support in the most known IDEs is widely available (Eclipse, VSCode, Sublime, Atom)ConclusionFinally, is up to you to adopt a statically typed Javascript language for your development.
If you consider the benefits in the long term, you could be saving lots of development and testing efforts.
By the other hand, in dynamic developments like prototyping and small projects, it could be better to keep working in the common way.
But, the benefits of starting a new project with static typing from the beginning, could improve the entire development process.
Sometimes, once people adopt this approach, going back it’s no longer an option.
.