A Simple Argument For Typescript

My favorite argument for typescript is that, in many cases, it doesn't even let you do the wrong thing.

Let me show you what I mean.

In this example, I forgot the name of the complete property of the todo object. Typescript won't even compile my code and my editor shows linting errors:

type Todo = {
  name: string;
  complete: boolean;
}

const newTodo: Todo = {
  name: "Walk the dog",
  finished: false
}

And the linting errors showing my type is wrong:

Any javascripters intrigued?

Comments

[Michael "lampe" Lazarski]

I'm now developing for over 10 years and this kind of error may happen like I don't know once a year.

My favorite argument for typescript is that, in many cases, it doesn't even let you do the wrong thing.

Bold claim. I still want to see the language that does not let me make stupid things.

Looking at statistics from projects usually, TypeErrors are around 20%. I think the biggest I have seen in the reduction of bugs was AirBnb which was like 38% percent.

The bigger category of bugs (In avg 80%) can be caught by code review and for example TDD.

Both of them have nothing to do with the language you are using.

I'm not arguing against TypeScript.

[Nick Scialli (he/him)]

Is it a bold claim, or are you misinterpreting the word “many” as “all?”

Clearly I’m not suggestion Typescript is the only code quality measure you need, but the way you’ve responded seems to suggest that’s your interpretation.

[Michael "lampe" Lazarski]

My response is that on avg TS will help you 20% (if your Airbnb 38%).

So is 20% equals to many cases?

What helps with many cases (80%) is reviewing code and testing.

To say it in other words:
The language you are using is like on avg 20%.
Good design, good practices, good testing, good communication and a lot of other things go into good code :)

OR

maybe I'm just triggered by sentences like "Any javascripters intrigued?" 🤣

[Nick Scialli (he/him)]

Sound like you’re triggered to be honest. I don’t know what percentage is “many” but, it means a lot. And the truth is typescript helps catch a lot of potential bugs.

[Michael "lampe" Lazarski]

That is what people think but if we look at data from projects and companies actually other things are way more important then the language they use ;)

Here is one study for example but please feel free to look into more!
earlbarr.com/publications/typestud...

[Nick Scialli (he/him)]

I’m definitely not trying to understate the importance of other code quality measures, but this study appears to say typescript would have caught at least 15% bugs on average. That’s huge.

[Michael "lampe" Lazarski]

A software production, in general, has a time limit and if you are not working on a hobby project you are hoping for a good ROI.

Having 115% more money in the bank after one month or having 180% more in the bank ;)

I would go with 180% since it has a way bigger ROI :)

Thats just my point :)

[Nick Scialli (he/him)]

Doesn’t this oversimplify things? Saving dev costs doesn’t matter a ton if your app is buggy and unusable.

[Michael "lampe" Lazarski]

The bank example was more of a metaphor.

ROI in this means less bugged code in less time :)
We invest less to get more out :)

[Seanmclem]

My code has grown simpler to write and maintain since I started using typescript for everything

[Pacharapol Withayasakpunt]

You might also try JSDoc. But if you are stuck with JavaScript, but what strict type checking, try // @ts-check.

Every JS dev should document with JSDoc, I think, even if no type checking.

However, TypeScript is not always friendly with JSDoc (or even TSDoc).

[Seanmclem]

Self-documenting code is pretty nice too.

[Thomas Lombart]

Though I think TypeScript is useful and adds a good layer of safety in your code, I don't think it should always be used. You have to weight the pros and cons of integrating TypeScript in your codebase before making a blind decision.

[emptyother]

I think typescript should always be used. In build scripts, browser-side, serverside, or even code snippets.

Its also my opinion that most projects type definitions don't haveto be watertight. Only define the types one need when one need them, and dont overcomplicate things.

Typescript as language is only the type definition parts, the rest is just javascript. So the way i see it typescript is just forcing well-documented javascript.

[Thomas Lombart]

If TypeScript were the standard for many years, I would definitely agree.

But if you have a whole codebase to migrate or a team that is not proficient with TypeScript, I'm not sure if that would be a good choice since it would cost a lot. That's why I think the pros and cons should be measured beforehand.

[Eugene Karataev]

I really like TS, but I still prefer vanilla JS for small R&D projects. Setting up TS infrastructure and fighting with types is waste of time if you just need to check a hypothesis and throw away the project when it's done.

[Pacharapol Withayasakpunt]

I actually use // @ts-ignore more often than I should sometimes.

Especially when there is no @types/xxx and I don't want to create declaration.d.ts.

Explicit generic type declaration and as can also create faults.

But when I had to write JavaScript, I prefer to include types in JSDoc as well.

There is also things like false type security in TypeScript as well, especially when you would rather use @hapi/joi in JavaScript (or io-ts / runtypes in TypeScript, but TS will never force you to use it).

[Abdullah Di'bas]

I think that the normal development of a language is by minimizing the options the developer has to make errors, and definitely no harm with that. (I'm a .NET and TS developer, so I may not be able to see others' point of view :D)

[Sebastijan Grabar]

TypeScript really does catch these kinds of bugs. To whoever says that it isn't that often that you find yourself in this situation, I don't think you are looking at the whole picture. Maybe when you're writing new code, yeah, you don't do these kinds of errors that often, but consider refactoring.

Rename a property name and your IDE doesn't refactor the name in all the places. TypeScript will tell you that a property name isn't correct somewhere else in the code and in turn, won't compile (okay, yeah, maybe it will if you have it configured like that, but it will at least print out the error for you). This is the kind of situation where TypeScript saves my ass and my time. I was literally in this situation TODAY.

But maybe even more importantly, where TypeScript really shines, is when it provides you the valuable information about types in a project you've never seen before in your life. Of course it's okay when you're working on a project and know the domain and know exactly what type each property is going to be, but for f*cks sake, you aren't the only person in the world who will work on this project. Someone will come after you eventually, and to THEM, TypeScript is a godsend. This is especially true for open-source projects. If you want to make a small change, you can do that in literally a few minutes, without TypeScript you would first be digging through tons of API documentation just to know what the hell is going on.

TypeScript is underrated.

[Richard Schloss]

What would the automated test look like for the above code? Forgive me, I'm not really up to date with TS.

For JS, it might be:

test('addItem method', async (t) => {
  const newTodo= {
    name: "Walk the dog",
    complete: false
  }
  const resp = await addItem(newTodo)
  t.is(resp.name, 'Walk the dog')
  t.false(resp.complete)
})

Would TS be able to simplify my test to something like this?

t.is(resp, newTodo)

Is there an advantage to using TS over a library such as validate ?

[Basti Ortiz]

The additional tooling is definitely my best argument for TypeScript as well. In particular, the VS Code IntelliSense integration makes development much easier with all the autocomplete suggestions.

[John Peters]

Yes intellisense errors prevent finding them at run time. Also if you comment code with \** comment **\ the comments show too.