it depends. you don't need typescript if you're approaching the problem differently. prop types and flow and named parameters with defaults all contribute to cutting down on type errors without having to add another language/transpile step to your project.
the cost of managing (preventing?) interfaces and classes inheriting from each other exists. the cost of finding and maintaining valid types for your project exists. there's cost in just integrating typescript projects with the rest of the frontend development ecosystem.
you don't want typescript if the added complexity isn't bringing you enough added utility.
Actually the 'added complexity' is subjective. Why? Because, to some of us, there is zero added complexity when using Typescript.
Auto completion at code-time catches bugs, rather than at run time. Bypassing Typescript says 1) For each runtime bug press F12 for debug mode 2) Select console and read the message 3) Go back to editor and put in a change 4) Save which reloads code 5) Repeat for every bug
There is absolutely an overhead, cognitive load if you will, to typescript. There's tooling in the JS ecosystem that catches bugs as you write code that work really well. Typescript has its place, but it shouldn't be a default for JS.
the added complexity isn't subjective though. typescript increases the complexity of the language so it can handle typing and type errors. it's right in the name.
and, man, i don't know, if your workflow includes refreshing blindly and hoping that you've fixed your bug, typescript isn't going to save you. you need a much deeper level of re-education and tooling than just a type system to get rid of that bad habit.
You're clearly wrong if you think I need a re-education of how to debug software. I don't run into these issues with the language because I've never relied on the falsehoods you're touting and learned the language without using training wheels.
that's an interesting paper, for sure. but it does kind of undermine the original point of saying typescript is less error-prone than javascript, right? neither typescript or javascript (or coffeescript for that matter) were associated with a higher or lower number of bug fix commits.
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.
it depends. you don't need typescript if you're approaching the problem differently. prop types and flow and named parameters with defaults all contribute to cutting down on type errors without having to add another language/transpile step to your project.
the cost of managing (preventing?) interfaces and classes inheriting from each other exists. the cost of finding and maintaining valid types for your project exists. there's cost in just integrating typescript projects with the rest of the frontend development ecosystem.
you don't want typescript if the added complexity isn't bringing you enough added utility.
Actually the 'added complexity' is subjective. Why? Because, to some of us, there is zero added complexity when using Typescript.
Auto completion at code-time catches bugs, rather than at run time. Bypassing Typescript says 1) For each runtime bug press F12 for debug mode 2) Select console and read the message 3) Go back to editor and put in a change 4) Save which reloads code 5) Repeat for every bug
There is absolutely an overhead, cognitive load if you will, to typescript. There's tooling in the JS ecosystem that catches bugs as you write code that work really well. Typescript has its place, but it shouldn't be a default for JS.
For me, Typescript will always be the default tool, it's simply a better choice.
For me, it doesn't provide enough value yet for me to implement it in any code base I'm working on.
the added complexity isn't subjective though. typescript increases the complexity of the language so it can handle typing and type errors. it's right in the name.
and, man, i don't know, if your workflow includes refreshing blindly and hoping that you've fixed your bug, typescript isn't going to save you. you need a much deeper level of re-education and tooling than just a type system to get rid of that bad habit.
You're clearly wrong if you think I need a re-education of how to debug software. I don't run into these issues with the language because I've never relied on the falsehoods you're touting and learned the language without using training wheels.
that's an interesting paper, for sure. but it does kind of undermine the original point of saying typescript is less error-prone than javascript, right? neither typescript or javascript (or coffeescript for that matter) were associated with a higher or lower number of bug fix commits.