Have you ever worked with a piece of JS code and thought any of these?:
"I wonder what fields are in this object"
"I wonder what exports are available in this module"
"I wonder if I can pass an object instead of a string here"
I certainly have, and all 3 of these things (not to mention several more) slow me down and annoy me as a JavaScript developer. Oftentimes I would have to dig through 3 (sometimes 5+) files to see where an actual value comes from, and sometimes even it comes from an external service that has little or no documentation about its return types.
In TypeScript - unless you are dealing with anys - the problems go away and your IDE or terminal can give you answers to these questions in real-time. Huge productivity boost.
That is why I will never again work on a codebase that doesn't leverage static typing.
I have the experience that people that behave like OP in thinking "this is a waste of time tool I prefer raw", usually is people that think their code is a piece of art and there's no imperfection on it, which translates later in a disaster code base.
Have you tried using an IDE that does this for you with JS though?
New developer on our team is trying to convince us to switch to Typescript with arguments like this. He has only ever used VSCode (which is terrible out the box for JS) and was trying to impress me with its intellisense. I then showed him IntelliJ and atom which have been doing the same since before TS was born.
I realise I am now in quite a luxurious environment where we use ES6 modules and current functionality with good IDEs. Many people seem to have written JS 5 years ago and are coming back to Typescript with the impression it's that which has somehow "fixed" JS. Almost all the good benefits boil down to things JS now has / VsCode support.
I am currently loving development with ES20## no build step in dev / Babel . Typescript just adds an unweildy and (IMHO) really bad typing system on top and enforces a build step. They could have at least looked at Hindley–Milner types and languages that use them rather than running with what they have.
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.
Have you ever worked with a piece of JS code and thought any of these?:
I certainly have, and all 3 of these things (not to mention several more) slow me down and annoy me as a JavaScript developer. Oftentimes I would have to dig through 3 (sometimes 5+) files to see where an actual value comes from, and sometimes even it comes from an external service that has little or no documentation about its return types.
In TypeScript - unless you are dealing with
anys - the problems go away and your IDE or terminal can give you answers to these questions in real-time. Huge productivity boost.That is why I will never again work on a codebase that doesn't leverage static typing.
This.
I have the experience that people that behave like OP in thinking "this is a waste of time tool I prefer raw", usually is people that think their code is a piece of art and there's no imperfection on it, which translates later in a disaster code base.
Have you tried using an IDE that does this for you with JS though?
New developer on our team is trying to convince us to switch to Typescript with arguments like this. He has only ever used VSCode (which is terrible out the box for JS) and was trying to impress me with its intellisense. I then showed him IntelliJ and atom which have been doing the same since before TS was born.
I realise I am now in quite a luxurious environment where we use ES6 modules and current functionality with good IDEs. Many people seem to have written JS 5 years ago and are coming back to Typescript with the impression it's that which has somehow "fixed" JS. Almost all the good benefits boil down to things JS now has / VsCode support.
I am currently loving development with ES20## no build step in dev / Babel . Typescript just adds an unweildy and (IMHO) really bad typing system on top and enforces a build step. They could have at least looked at Hindley–Milner types and languages that use them rather than running with what they have.