Strict Types: Typescript, Flow, Javascript — to be or not to be?

According to the Global Developer Hiring Landscape Survey report 2017 conducted by Stack Overflow, JavaScript remains the most widely used scripting language among web developers around the globe. Since its inception in 1995, JavaScript established its reputation as an optimal frontend language for browsers and web pages alike. Thanks to its extensive libraries, it has secured incredible reviews for visual illustrations too. Angular JS, Ember.js and other similar supportive frameworks have provided JS with required flexibility and power.

To recall, JavaScript was basically outlined to act as a client-side language, and its functionality isn’t as elaborated as other languages. Therefore, it lacks plenty of important features required to adequately write and maintain massive applications. To deal with this concern, web developers including a few teams at Microsoft have employed tools like jslint and Script# for static typing and code scouting. In addition to that, they’ve also employed advanced methods like the module pattern to carry out encapsulation.

The statistics from GitHub over the past 3 years also showed a compelling rise in the number of projects that uses JavaScript static typing. Be it TypeScript, Python, PHP, AtScript or Flow, developers are showing more interest in embracing static plugins over dynamic.

JavaScript — History

NCSA’s Mosaic was the first generally acknowledged web browser back in 1993. Netscape introduced its popular proprietary browser dubbed Netscape Navigator in 1994, which was believed to be the only reliable option in the 90’s. Netscape recruited Brendan Eich in 1995 and JavaScript was founded by him in the same year. According to Eich,

“We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers — the Web page designers — would assemble components and automate their interactions using JS.”

Let’s admit it. We’re at a crux where most advanced languages are moving towards functional programming or strict or static typing.

JavaScript being dynamically-typed allows you to declare functions, objects and variables without declaring the type. Although this feature adds to the convenient use of the language, it’s not always suitable. To handle such discrepancies, latest tools like TypeScript and Flow have chipped in to give JS developers a choice to employ static types.

The purpose of this article is to highlight the pros and cons associated with static typing. In addition to that, we’ll also have a look at two of the most widely used static languages in the world of programming — TypeScript and Flow along with a comparison between them so that at the end of this post you would be able to decide whether or not shift your current projects to strict options instead of relying on good ol’ Vanilla JavaScript.

Why you Need Types — Entering the Realm of TypeScript or Flow

To recall, Coffeescript was extremely popular back in the initial days of Heap and I loved it. But although, I have tremendous respect for its inventor, the fact is the language had some severe glitches which IMO he had no concern in ever adjusting. And finally, with an emergence of ES6, the language required to readjust or expire. However, every effort to employ latest ES6 pattern was rebuffed.

Here I would also like to mention Babel. Both coffeescript and Babel are transpilers and have a lot in common (especially the syntax). As a matter of fact, Babel enables you use nearly all the latest features that ES6 offers these days. In addition to that, the top-notch support for plenty of diversified build and check mechanisms which makes unification with your present toolchain absolutely effortless.

The imperfections in CoffeeScript and Babel has inspired developers to explore other options, including TypeScript and Flow.

TypeScript is an open-source programming language developed by Microsoft and it is said to be the superset of JS. Flow, on the other hand, is developed by Facebook and it’s popular for its static type checking. What I find impressive is unlike Flow which is drafted in OCaml, TypeScript is literally composed in TypeScript.

In practice, Flow is comparatively less noticeable than TypeScript and it can be gradually included to the project file and you can set up type checking in it by just adding // @flow at the beginning of the file.

TypeScript vs Flow

Both TypeScript and Flow are great. Both are powerful, progressive, and constructional. So, this is going to be an unfolding and fragmentary comparison.

TypeScript

TypeScript is similar to a conventional compiler (you’d be surprised to see how stern it will be when it comes to performing a type check). It accepts (.ts) input and generates (.js) output. The compiler flag called nolmplicitAny is included, which if turned on, will need you to point out types and return values for all the arguments and functions in use.

Activating noImplicitAny may have severe consequences for your work, specifically if you wish to reinforce third-party libraries. The idea of declaration files in TS is a blessing though as it allows you to double check that you’re employing a library perfectly.

There are plenty of declaration files accessible, covering myriad of JS libraries (but not every library is included of course). Moreover, it’s not assured that the developer who penned the .d.ts file have done it accurately .Plus, you’ll be required to provide the type definition if you want to introduce a unique third party library to your coding.

The support for TypeScript is rooted in VSCode. In addition to the typical in-line demonstration of compile errors, the prime trading point in employing an IDE with TS is refactoring, click-through navigation and autocompletion feature. The autocomplete feature is of confined functionality in VSCode, with one remarkable exception for Redux state which definitely is crucial if you’re working on a Redux project.

Who Should Use TypeScript?

Well, if you want to use TypeScript for its bug catching capabilities, lookout for some other options such as TDD (Test Driven Development) as it can efficiently reduce your shipping bug density and there are hundreds of proofs to support this claim.

The popular Springer research demonstrated around 40%+ cut in bug density in connection with the identical projects that didn’t employ this practice. However, use TypeScript if you want effective intelligence tools.

Flow

Unlike TypeScript, there is no solid compilation stage in Flow. As a substitute, Flow examines your usual .js files to detect possible errors. In other words, it acts like a smart linter. In addition to that, just examining types, it also delve into the overall framework of your program, which apparently means it checks out the control flow of your program.

While Flow can include a lot of value to classic JS, the true benefits shows up when you include type annotations to your codebase. Despite the fact that type annotations in Flow look identical to the annotations in TypeScript, the fact is it’s entirely different when it comes to declaring complex types and data structures. Plus Flow makes use of nominal typing, while TypeScript depends on structural typing.

What I found most interesting is once Flow completes its examination, there’s no requirement for the type declarations as well as annotations and you can instantly run your code.

The basic error support provided by Nuclide is an added advantage. Moreover, it also include autocompletion support feature too.

So, Who’s the Winner?

Whether TypeScript or Flow, one thing is certain that type checking is expected to be the future of JS. Presumably the most noteworthy dissimilarity between Flow and TypeScript is how smoothly they can be integrated into the current projects. While TypeScript is considerably more sophisticated, Flow feels simple to introduce, admitting with a warning that it might be inspecting less of your coding as expected.

If Angular 2+ is your field of specialization, it’s better you opt for TypeScript. However, if you’re working on React, you could choose Flow as it seamlessly consolidates with Babel and other relevant frameworks. But I prefer TypeScript for React stack as well :).

In addition to that, there are numerous other aspects that you should bear in mind. Coupled with static typing, TypeScript also aim to provide excellent tooling as well as language assistance to refactoring and auto completion. But if interprocedural examination is what you intend to do or wish to have a profound understanding of your code, Flow is the option you should look up to.

The Benefits of Using Static typing

On-Time Detection of Bugs/Errors

Through Static type testing, it’s easy to validate that the mentioned invariants are true without even running the program. Plus, instead of detecting errors during runtime, it gives developers freedom to catch them before that. Since the type checker inform you about the bugs/errors in the beginning, it’s absolutely easy and comparatively inexpensive than determining about the errors once the code has been forwarded to your clients.

Next operations are valid in the javascript, but you would get exceptions in the typescript, for example:

It Communicates the Purpose of the Function

Types act as an active, living documentation for the coder as well as the other users of the program. Through Static typing, it’s easier for you to comprehend the purpose of the function, the type of data it accepts as an input or what to expect in return.

Well, if you think that including comments could serve the similar purpose, you’re not wrong. But since code comments are kind of verbose, they disturb the overall structure of your code. In addition to that, it totally depends on the developer to write good, complicated, or no comments at all.

Let’s take a look on the jsdoc:

It Scales Down Complex Error Handling

We better check that s is string, while y is a regular expression. Without static types, you need tons of code for a small bit of functionality. Through static types, it’s easier for you to avoid complex sets of coding to handle errors or bugs.

It Distinguishes Between Data and Behavior

Since static types clearly distinguish between data and behavior, it makes it achievable for developers to be straightforward about their expectations and more precisely explain their purpose. By doing so not only mitigates pressure and ambiguity but also gives them mental clarity and transparency during coding.

Wipes Out Runtime Type Errors

Type errors at runtime can be disastrous. Static types help in removing such errors, giving programmers freedom to enjoy zero errors at runtime.

For instance, the below code will work in javascript, but will flag a compilation error about the fact that signature doesn’t exist.

Domain Modeling Tool

Combining both data and its behavior, domain modeling is certainly one of the best features of static types. On one hand, it help developers check the union cases and instantly resolve how the app environment is put together, and on the latter, reduces administrative complexity: App.subapp.somefunction

The Disadvantages of Using Static Types

Similar to any other programming language, static type checking isn’t free from flaws. To make a sensible decision, it’s therefore important that we recognize and accept them. Read on to unearth some of the disadvantages that needs your consideration before opting for static typing for your projects.

It May Confuse the Budding Developers

One primary reason JavaScript is so popular amongst web developers is that they don’t need to get their hands on the complete type system before getting started. This is specifically important for the budding programmers and coders. Including types to the process can confuse them and will make the learning process steeper than expected.

Demands Lots of Time and Practice

Mastering types isn’t as easy as it sounds. It takes great deal of practice and time to understand the best ways to specify types within a program. Plus, only an experienced programmer is capable of determining whether or not adding types would meet the purpose.

It Gives Developers a Deceitful Sense of Security

Well, if you think strict typing can do wonders for you when it comes to bug density, it’s time now to seriously rethink your approach. According to the article ‘The broken promise of static typing’ published by Daniel Lebrero,

“With that in mind, I tried to find some empirical evidence that static types do actually help avoid bugs. Unfortunately the best source that I found suggests that I am out of luck, so I had to settle for a more naïve approach: searching Github.

Using static types in JavaScript — Yay or Nay?

Let’s be honest! Static types have added a complete new dimension to the world of programming. Although it takes plenty of time and effort to master the technicalities that comes with types, the security and preciseness are the factors that make these flaws less intensive for me.

However, it all boils down to your personal preferences and the type of project you’re working on. In conclusion, you can opt for static type checking if:

• Your project is big and complex

If you have a team working on a project with huge codebase, TypeScript can help you sidestep plenty of errors. A developer could come out with breaking changes at any moment. But, if your project isn’t complex, it just makes no sense to make it one by including unnecessary type annotations (With TypeScript or other static types, at least expect a 30% increase to the total code size).

• A huge team is responsible to handle the task

TypeScript is a great option if a huge team is responsible to handle the task. Plus, it’s also very important that the members are already familiarized with strongly type languages such as Java or C#.

• You may require to refactor the program in the long run

Use TypeScript if you think there will be a need to refactor program in the future. Don’t carry unnecessary burden if you have a short-term assignment in hand.

• When your Team is Familiar with Statically Typed Language

Strictly typed languages like TypeScript makes a perfect choice if you or your teammates are already familiar with strongly typed languages like Java or C#. Since, the TypeScript was developed by the same developer who invented C#, both these languages share identical syntax.

• You’re Looking For a Babel Substitute

To recall, Microsoft used to take conventional tools and include proprietary aspects to them. For instance, Java leading to J++. TypeScript is totally the identical approach. Noticeably, this isn’t American company’s first fork of JS as back in 1996, Microsoft has already forked it to develop JScript.

Although, it’s a rare case, but it’s still methodologically conceivable to transpile ES6 code to ES5 by employing the TS transpiler. That’s probably because ES6 is basically a subset of TS and the relevant transpiler produces ES5 code.

TypeScript transpiler produces fairly understandable code and that’s perhaps one of the biggest reasons why Angular 2 team selected it over Google’s popular Dart language. In addition to that, TS also includes some other amazing features that are not present in ES6.

• When a Library Suggests TypeScript

For those using Angular 2 or any other framework that suggests TypeScript should give it a try. Despite the fact that TS can make use of all the available JS libraries, if you’re seeking exceptional syntax errors, you’ll require to include the type definitions externally.

Avoid using types if:

• The needed program isn’t critical and progressive in nature

If the project you’re working on isn’t long-term and progressive in nature, it makes no sense to add needless type annotations to your codebase as it will only add to the the length of your code, making it look messy and complicated.

• You’re working alone on the project

Do not opt for TypeScript or Flow if you’re working alone on the project. These languages best caters to large teams and extensive projects. Ahead of deciding your preferred framework, it’s advisable to unearth the scope and nature of your work and take decision accordingly.

• Your requirements are limited or the task is simple in nature

As compared to static typing, setting up anything in JavaScript is easy. A big ‘No’ to TypeScript or other static type languages if the nature of your task isn’t convoluted or long-term.

• You want to sidestep possible performance penalties

Similar to Babel, the TS transpiler include features that need creating additional code and regardless of how effective your transpiler is, it can’t outweigh the performance of an experienced programmer.

Therefore, the performance penalty is possibly insignificant if set side by side with the type mechanism. But there are cases where fraction of a second counts, and in those instances transpilation of any form isn’t suggested.

Since all the type checking takes place at transpile time, it’s worth mentioning that TypeScript doesn’t include any additional coding for runtime type scouting.

• You want to sidestep annoying edge cases

The presence of disturbing edge cases is a serious flaw associated with strictly typed languages. With Sourcemaps, it’s simpler to debug TypeScript, but keep in mind the status quo isn’t indefectible. In addition to that, debugging ‘this’ keyword is another trouble.

• You want to avoid extra costs

If you select TypeScript, you will be required to do some additional bookkeeping. Again, it’s worthless if you’re working on a pure JavaScript project.

Conclusion

Once you master static types with appropriate use of including them into your projects, it’s very unlikely you return back to the dynamic options. However, it all boils down to your requirements and the scope of project you’re currently working on. Please feel free to share your thoughts in the comment section below. We would love to hear back!

by Sharmeen Hayat, author & Data Specialist

Oleksandr Knyga, Software Engineer

Dima Dmytriienko, editor & Brand Specialist