DEV Community

loading...
Cover image for A Simple Argument For Typescript

A Simple Argument For Typescript

nas5w profile image Nick Scialli (he/him) ・1 min read

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:

linting error

Any javascripters intrigued?

Discussion (25)

pic
Editor guide
Collapse
lampewebdev profile image
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.

Collapse
nas5w profile image
Nick Scialli (he/him) Author • Edited

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.

Collapse
lampewebdev profile image
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?" 🤣

Thread Thread
nas5w profile image
Nick Scialli (he/him) Author

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.

Thread Thread
lampewebdev profile image
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...

Thread Thread
nas5w profile image
Nick Scialli (he/him) Author

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.

Thread Thread
lampewebdev profile image
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 :)

Thread Thread
nas5w profile image
Nick Scialli (he/him) Author

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

Thread Thread
lampewebdev profile image
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 :)

Collapse
seanmclem profile image
Seanmclem

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

Collapse
patarapolw profile image
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).

Thread Thread
seanmclem profile image
Seanmclem

Self-documenting code is pretty nice too.

Collapse
thomaslombart profile image
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.

Collapse
emptyother profile image
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.

Collapse
thomaslombart profile image
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.

Collapse
karataev profile image
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.

Collapse
baso53 profile image
Sebastijan Grabar • Edited

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.

Collapse
patarapolw profile image
Pacharapol Withayasakpunt • Edited

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).

Collapse
abdullahdibas profile image
Abdullah Di'bas • Edited

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)

Collapse
rawrasaurus profile image
Rawrasaurus • Edited

Declaring a property that doesn't match your model and having the linter complain should feel natural to most developers especially for those coming from a lower level language like C/C++ or even Java static typing is so crucial and important to understand IMO. The main advantage being that the compiler has a chance to perform all kinds of type checking therefor eliminating trivial bugs at an earlier phase in your application.

Collapse
richardeschloss profile image
Richard Schloss • Edited

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 ?

Collapse
somedood profile image
Basti Ortiz (Some Dood)

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.

Collapse
jwp profile image
John Peters • Edited

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