paint-brush
Why I no longer use TypeScript with React and why you shouldn’t eitherby@dominik.t
96,512 reads
96,512 reads

Why I no longer use TypeScript with React and why you shouldn’t either

by Dominik TarnowskiNovember 15th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Don’t get me wrong, I absolutely love TypeScript. JavaScript code can get messy, and strict type checking has saved me countless hours of debugging. However, there are two main reasons why I don’t use it in my react apps and I’ll get into that soon.

Coin Mentioned

Mention Thumbnail
featured image - Why I no longer use TypeScript with React and why you shouldn’t either
Dominik Tarnowski HackerNoon profile picture

Don’t get me wrong, I absolutely love TypeScript. JavaScript code can get messy, and strict type checking has saved me countless hours of debugging. However, there are two main reasons why I don’t use it in my react apps and I’ll get into that soon.

Why we use TypeScript

There are quite a few great benefits of using TypeScript, especially:

  • Instant type error detection
  • Better IDE experience
  • More self-documenting code
  • More readable & easier to understand

However, this comes at a cost. TypeScript, requires much more time to compile. Let’s take React as an example. I set up the default create-react-app project with and without typescript (for typescript, I usednpx create-react-app my-app --typescript ). The difference?

To me, the time taken to create the project and the project size are somewhat insignificant. However, when it comes to the re-compile time, time taken for the change in our code to show up, it get’s really tricky. I’ve always wondered why angular projects take so long compared to react and vue to re-compile, and I think I know why now. TypeScript seems to add quite a big overhead even when re-compiling an out of the box cra project:

TypeScript, takes a few seconds

JavaScript, near instant

However, even this massive delay wouldn’t necesarrily encourage me to switch to pure JavaScript, simply because I love the Intellisense (autocomplete and type error detection) that comes with TypeScript with VsCode. Flow seemed like a great alternative, it doesn’t low down the compilation time as much, but it’s integration with VsCode is pretty bad at the moment. However, since TypeScript 2.3, TypeScript and VsCode support type checking JS files using JSDoc. This doesn’t add any delays as nothing is transpiled, and it’s completely optional!

Type checking with JSDoc

In the official TypeScript documentation, you can find a section on Type checking JavaScript files. In order to get started, you can either add a comment ( // @ts-check ) at the top of your .js file, or add the following line to your vscode settings.json file:

"javascript.implicitProjectConfig.checkJs": true

And just like that, we have VsCode Intellisense type checking, using JSDoc types:

Its only drawback is the size of the type declaration. With TypeScript, you can declare types on the same line as your variables and parameters, whereas with JSDoc you need to dedicate a whole new line to each.

Personally, there is one more reason I hate don’t like using TypeScript with react, the 3rd party dependencies. Some libraries are of course written in TypeScript, such as material-ui, but some require you to install an additional @types/ dependency which can be a bit annoying, not mentioning the packages that don’t support type definitions well or not at all. In those cases, you’ll have TypeScript errors all over your project and will have to use the any type anyway,whereas the Flow and JSDoc do the same thing but are less strict with the any type.

In my opinion, when it comes to react applications, you don’t need TypeScript, nor Flow. JSDoc can do the job just as well, and it doesn’t slow down your compilation process or requires yet another dependency. If you’d like to check it out, have a look here. It’s much easier to switch to it, all you need to do is add a single comment at the top of your code, instead of having to install and configure a transpiler.