Typing in JavaScript — Flow vs. TypeScript

There are two typed extensions of JavaScript, Microsoft’s TypeScript and Facebook’s Flow. In this article, we’ll look at and compare the features of each of these.

At Sulu we have decided to use Flow for static type checking, and I am still convinced that it was the correct decision back then. However, today TypeScript seems to be the much more popular choice. This claim can also be supported by earlier blog posts and presentations being more about what to choose, whereby more recent ones are about how to switch. So I think it is time to reconsider that decision, therefore I am going to compare these type checkers in this blog post.

#@ What is static type checking?

Static type checking has the goal of finding errors before you even run your code. This will catch quite a bunch of errors for you, and helps a lot to deliver higher quality code. Let’s have a look at a short example:

console.log(5/"5");

This code is syntactically correct, so JavaScript will not complain about this, until it executes that line of code. Since it is pretty obvious that you cannot divide a number by a string, you might say you are not doing that anyway, but imagine that the value of "5" is stored in a variable, and the value of that variable is not completely clear, because it is determined in a 100 lines of code. In that case it would be quite easy to mess this up in some way, without immediately realizing it. A static type checker would tell you about the error at the moment you introduce it, and you are much more likely to know what’s wrong than when finding out about this error at runtime a year later.

Now there are different ways on how to apply static type checking. Many compiled languages do this during their compilation step, which means that the program does not compile at all if you get any type errors in your project. This is a valid approach, and you will also know about the error very soon. But you are losing the opportunity to quickly test doing something in a slightly different way, because you might have to adjust a huge amount of types before you can even compile the program.

JavaScript is not a compiled language, therefore it can only check the code when it is being interpreted, i.e. at runtime. And that’s exactly where TypeScript and Flow jumps in: These are tools that allow to annotate your JavaScript code with type annotations and check based on top of them if everything can work as expected. However, you are not writing pure JavaScript anymore, but instead you have to somehow turn that into pure JavaScript in order for browsers to understand your code. TypeScript comes with its own compiler for that, whereby Flow just relies on Babel to get rid of the annotations for you. TypeScript needs that compilation step for certain features it implements, because strictly speaking it is more than just a static type checker.

The advantage of the latter approach is that you can adjust the code in a way that types will fail, but you can ignore that for the moment, if you are just trying to quickly test something. In a compiled language you would have to fix all the type errors first. Now you can say that the program won’t run anyway as expected (although that is not completely true, because you might use it in a way that the type errors don’t matter), but at least it can run until a certain point, where you might be able to already do a console.log to check on something. That’s something I really enjoy.

On a sidenote, there are also languages like PHP, which have improved their type system over the last years significantly, but it still feels a bit weird. PHP comes with the possibility to annotate your code with types in many different places, but it does not allow to check these errors before runtime. So you can e.g. define in a function that the parameter must be a string, but if you are calling the function with a wrong type, you will not realize that before this code is being executed, in which case you will get a runtime error. In my opinion this is the worst of both worlds, because you can’t tell about the errors before actually running the code, and it doesn’t allow you to quickly test something with different types. To be fair, there are tools like PHPStan and Psalm that work in a similar fashion than TypeScript and Flow, but PHP will still not allow to execute your code with wrong types.

#flow #javascript #typescript #web-development #developer

What is GEEK

Buddha Community

Typing in JavaScript — Flow vs. TypeScript

There are two typed extensions of JavaScript, Microsoft’s TypeScript and Facebook’s Flow. In this article, we’ll look at and compare the features of each of these.

At Sulu we have decided to use Flow for static type checking, and I am still convinced that it was the correct decision back then. However, today TypeScript seems to be the much more popular choice. This claim can also be supported by earlier blog posts and presentations being more about what to choose, whereby more recent ones are about how to switch. So I think it is time to reconsider that decision, therefore I am going to compare these type checkers in this blog post.

#@ What is static type checking?

Static type checking has the goal of finding errors before you even run your code. This will catch quite a bunch of errors for you, and helps a lot to deliver higher quality code. Let’s have a look at a short example:

console.log(5/"5");

This code is syntactically correct, so JavaScript will not complain about this, until it executes that line of code. Since it is pretty obvious that you cannot divide a number by a string, you might say you are not doing that anyway, but imagine that the value of "5" is stored in a variable, and the value of that variable is not completely clear, because it is determined in a 100 lines of code. In that case it would be quite easy to mess this up in some way, without immediately realizing it. A static type checker would tell you about the error at the moment you introduce it, and you are much more likely to know what’s wrong than when finding out about this error at runtime a year later.

Now there are different ways on how to apply static type checking. Many compiled languages do this during their compilation step, which means that the program does not compile at all if you get any type errors in your project. This is a valid approach, and you will also know about the error very soon. But you are losing the opportunity to quickly test doing something in a slightly different way, because you might have to adjust a huge amount of types before you can even compile the program.

JavaScript is not a compiled language, therefore it can only check the code when it is being interpreted, i.e. at runtime. And that’s exactly where TypeScript and Flow jumps in: These are tools that allow to annotate your JavaScript code with type annotations and check based on top of them if everything can work as expected. However, you are not writing pure JavaScript anymore, but instead you have to somehow turn that into pure JavaScript in order for browsers to understand your code. TypeScript comes with its own compiler for that, whereby Flow just relies on Babel to get rid of the annotations for you. TypeScript needs that compilation step for certain features it implements, because strictly speaking it is more than just a static type checker.

The advantage of the latter approach is that you can adjust the code in a way that types will fail, but you can ignore that for the moment, if you are just trying to quickly test something. In a compiled language you would have to fix all the type errors first. Now you can say that the program won’t run anyway as expected (although that is not completely true, because you might use it in a way that the type errors don’t matter), but at least it can run until a certain point, where you might be able to already do a console.log to check on something. That’s something I really enjoy.

On a sidenote, there are also languages like PHP, which have improved their type system over the last years significantly, but it still feels a bit weird. PHP comes with the possibility to annotate your code with types in many different places, but it does not allow to check these errors before runtime. So you can e.g. define in a function that the parameter must be a string, but if you are calling the function with a wrong type, you will not realize that before this code is being executed, in which case you will get a runtime error. In my opinion this is the worst of both worlds, because you can’t tell about the errors before actually running the code, and it doesn’t allow you to quickly test something with different types. To be fair, there are tools like PHPStan and Psalm that work in a similar fashion than TypeScript and Flow, but PHP will still not allow to execute your code with wrong types.

#flow #javascript #typescript #web-development #developer

TypeScript vs. Flow: Type Checking Front End JavaScript

Lots of things about development and code comes down to preferences, but when it comes to type checker for JavaScript, it’s hard to pick Flow over TypeScript.

Although both are backed by a big tech company and have similar type checking syntax, TypeScript has great support from popular JavaScript frameworks and has a clear development roadmap so that you know what to expect in the future.

#javascript #typescript #flow

TypeScript VS Flow: Type Checking Front End JavaScript

#react #typescript #javascript #reactjs #flow

Learn Object Key iteration in JavaScript and TypeScript

Looping through an object by its keys is a common task for many #JavaScript developers. In this lesson we discuss why your assumptions can break when migrating your code to #TypeScript and a quick fix you can use if you trust you code completely 🌹

#typescript #javascript 

The Definitive Guide to TypeScript & Possibly The Best TypeScript Book

TypeScript Deep Dive

I've been looking at the issues that turn up commonly when people start using TypeScript. This is based on the lessons from Stack Overflow / DefinitelyTyped and general engagement with the TypeScript community. You can follow for updates and don't forget to ★ on GitHub 🌹

Reviews

• Thanks for the wonderful book. Learned a lot from it. (link)
• Its probably the Best TypeScript book out there. Good Job (link)
• Love how precise and clear the examples and explanations are! (link)
• For the low, low price of free, you get pages of pure awesomeness. Chock full of source code examples and clear, concise explanations, TypeScript Deep Dive will help you learn TypeScript development. (link)
• Just a big thank you! Best TypeScript 2 detailed explanation! (link)
• This gitbook got my project going pronto. Fluent easy read 5 stars. (link)
• I recommend the online #typescript book by @basarat you'll love it.(link)
• I've always found this by @basarat really helpful. (link)
• We must highlight TypeScript Deep Dive, an open source book.(link)
• Great online resource for learning. (link)
• Thank you for putting this book together, and for all your hard work within the TypeScript community. (link)
• TypeScript Deep Dive is one of the best technical texts I've read in a while. (link)
• Thanks @basarat for the TypeScript Deep Dive Book. Help me a lot with my first TypeScript project. (link)
• Thanks to @basarat for this great #typescript learning resource. (link)
• Guyz excellent book on Typescript(@typescriptlang) by @basarat (link)
• Leaning on the legendary @basarat's "TypeScript Deep Dive" book heavily at the moment (link)
• numTimesPointedPeopleToBasaratsTypeScriptBook++; (link)
• A book not only for typescript, a good one for deeper JavaScript knowledge as well. link
• In my new job, we're using @typescriptlang, which I am new to. This is insanely helpful huge thanks, @basarat! link
• Thank you for writing TypeScript Deep Dive. I have learned so much. link
• Loving @basarat's @typescriptlang online book basarat.gitbooks.io/typescript/# loaded with great recipes! link
• Microsoft doc is great already, but if want to "dig deeper" into TypeScript I find this book of great value link
• Thanks, this is a great book 🤓🤓 link
• Deep dive to typescript is awesome in so many levels. i find it very insightful. Thanks link
• @basarat's intro to @typescriptlang is still one of the best going (if not THE best) link
•  
• This is sweet! So many #typescript goodies! link

Get Started

If you are here to read the book online get started.

Translations

Book is completely free so you can copy paste whatever you want without requiring permission. If you have a translation you want me to link here. Send a PR.

• Filipino
• Italian
• Chinese
• Russian
• Portuguese
• Japanese
• Spanish
• Korean
• French
• Polish
• Thai

Other Options

You can also download one of the Epub, Mobi, or PDF formats from the actions tab by clicking on the latest build run. You will find the files in the artifacts section.

Special Thanks

All the amazing contributors 🌹

Share

Share URL: https://basarat.gitbook.io/typescript/

Author: Basarat
Source Code: https://github.com/basarat/typescript-book/ 
License: View license

#typescript #opensource