In my mind the number one point is, "do you work with data"? For me this is always the case. Database schemas are always are tightly bound contract. Knowing the shapes of your documents/entities/models/etc are important. There is never a time when I want to guess what the fields of a table/the properties of an object are.
Apart from the want for types, Typescript itself is an amazingly well designed piece of software. It's ability to express types that can actually translate fully into a dynamic language is amazing. It's option for strict checks seriously do help me write better code.
The refactoring support from Typescript is well noted, the VS Code support is fantastic, the ability to target multiple versions of Javascript with Typescript is very useful (not to say Babel isn't, using Babel with Typescript is also good), and the ability to read Typescript in my opinion is better.
I frequently read open source code on Github, and when I'm reading Javascript code, there isn't enough information for me to fully understand it. Typescript gives me a much better description of what I am reading.
Types are like adjectives; they are meant to describe things. Most of the time, I want to be able to clearly describe what is happening in my code, and I want the code that I read to be descriptive enough as well. Types are not a replacement for documentation, but I feel like they definitely need to both exist. Types not only help human users understand code better, but it also helps your tooling understand your code better.
Maybe I'm biased after using compiled statically typed languages for so long, but after using languages like Rust, C#, or Kotlin, I just feel like not having a proper type system is almost always bad when writing large projects that interact and describe a lot of data. I'm just going to document the types anyway; I might as well have just written it in the type signature.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my mind the number one point is, "do you work with data"? For me this is always the case. Database schemas are always are tightly bound contract. Knowing the shapes of your documents/entities/models/etc are important. There is never a time when I want to guess what the fields of a table/the properties of an object are.
Apart from the want for types, Typescript itself is an amazingly well designed piece of software. It's ability to express types that can actually translate fully into a dynamic language is amazing. It's option for strict checks seriously do help me write better code.
The refactoring support from Typescript is well noted, the VS Code support is fantastic, the ability to target multiple versions of Javascript with Typescript is very useful (not to say Babel isn't, using Babel with Typescript is also good), and the ability to read Typescript in my opinion is better.
I frequently read open source code on Github, and when I'm reading Javascript code, there isn't enough information for me to fully understand it. Typescript gives me a much better description of what I am reading.
Types are like adjectives; they are meant to describe things. Most of the time, I want to be able to clearly describe what is happening in my code, and I want the code that I read to be descriptive enough as well. Types are not a replacement for documentation, but I feel like they definitely need to both exist. Types not only help human users understand code better, but it also helps your tooling understand your code better.
Maybe I'm biased after using compiled statically typed languages for so long, but after using languages like Rust, C#, or Kotlin, I just feel like not having a proper type system is almost always bad when writing large projects that interact and describe a lot of data. I'm just going to document the types anyway; I might as well have just written it in the type signature.