Written by Paul Cowan✏️
Before I start, I would like the jury to know that I am, for the most part, a TypeScript fan. It is my primary programming...
For further actions, you may consider blocking this person and/or reporting abuse
Yes.
End of discussion.
There are many other answers to the same question here: dev.to/bettercodingacademy/typescr...
I literally was in the same room as a team of 5 debug Typescript for 4 hours, just to get it up and running on 1 box. There's some perks, but there are some pitfalls. It's not for every project. Large, complex apps existed prior to TS and will continue to do so. It's not a zero-sum game.
Why did debug session take so long?
Not too sure, as I was working on another project; being productive. 😉
I think a lot of people think swithing to TypeScript can be done overnight with the press of a button. People forget that you still need to learn a new programming language. But once you do, it's always worth using it for projects larger than single file scripts, especially when there are multiple people working on the same project.
I've been writing JS for over a decade. Still haven't needed typescript and the latest, large project I worked on, Typescript would have been a major inhibitor to velocity. Not bc itself, but due to the team's seniority.
When compilers first came out all the folks who wrote assembly language said "We been writing assembly forever, we don't need no stinking "language".
When C++ came out many C people refused to use it.
When Java came out, non-OOP people saw no value.
When Functional programming styles were introduced in C# via the static extension methods, many established C# shops refused to use them. Why? "They chew up memory"
When LINQ came out, many didn't use it for years. Once they figured it out, they can't live without it.
When RXjs came out, many said it's too complex I'll stick with events.
When REST came out, SOAP people were skeptical.
When LESS and SASS came out, the expert CSS folks didn't need or want to adopt it.
When React came out, Angular people panned it.
When JavaScript came out OOP folks laughed at it's design. Some refused to use it (choosing server side for rendering). Once client side MVC was introduced, JavaScript became ubiquitous.
Each new generation of "things" ultimately won adopters. Most were successful, some were not (Silverlight). This means that each company adopts different "things" and if we want to work there we must learn what they have.
Typescript is only a inhibitor to velocity when the people using it have to learn it. After that, it can be argued to be faster than JavaScript due to auto-completion and catching type error before run time.
Typescript is a wonderful fit for OOP crowd as it is no different than other languages such as C# and Java in concept. Angular and React support it and many companies want Typescript people right now. Yes there is now a fractured Typescript vs JavaScript world. Why not know both?
You are right, any new thing used in any project is ultimately a minimum of 6 months to get fluent and feel comfortable. We often say it take 1.5 years to become a real Subject Matter Expert. Most of this is easy "if you have the time". On the other hand, it's a guaranteed toxic environment when there's no time.
A lot of what you said is subjective.
Typescript is great for devs that don't really want to learn JS and stick with an OOP paradigm. That's what I've seen from my experience and those devs will flourish. The question of: Why not both? Because type checking and the cost benefit is not worth it at all. The tooling that exists already is good enough and easy to implement. Why not learn JS and move away from the C#/Java-esque syntax?
I do see value in a JSDocs mashup with Typescript being of value. That way there's less C# in the JS written and you get some feedback from the type checker. That's a solid implementation imo.
medium.com/@trukrs/type-safe-javas...
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.
We need and prevent any type issue from our side as devs. Is more easly to incur on a typing mistake from us instead caming from the API or the user side.
I come from CoffeeScript, that is kinda dead now.
I tried TypeScript, observed the same that this post mentions.
I tried some Python-to-JavaScript compilers, they were not good at all.
I tried Nim, solved my problems, including TypeScript ones.
:)
I've seen you mention a few times in here, it likes nice but there is a really tiny community and ecosystem for web apps, unless you can point out otherwise
It is a language to work with other languages too, I use it for Python,
I am part of the Python community, and find it searching for alternatives to Cython,
you can "import" C and JS libs and use them from Nim,
it is Python-like syntax instead of JavaScript-like so that may or may not be a disadvantage,
besides that no one forces you to abandon JS community.
But JavaScript community is biggest on the whole world anyways,
all communities are tiny communities compared to JavaScripts...
🤷♀️
Our team has been using typescript for a year now, reasons why we use typescript:
Asserts gets us some of the way for runtime type checking.