DEV Community

5 Reasons To Use TypeScript

mattstobbs on October 28, 2021

This post was originally posted on my blog, 5 Reasons To Use TypeScript. Some changes have been made from the original post to fit the styling of d...
Read full post
Collapse
 
rkallan profile image
RRKallan •

nice to have Compile-Time Errors.
But Most of the time data used in JS is dynamic. So cool to have compile error, but what if data has different type as expected. It will throw a error and application isn't useable anymore.

Clear code when using Typescript? I disagree. There readability of code most of the times is very hard

Safe Refactoring
you are changing a type! These type check could also be done with propTypes or Flow. 2 tools which are var way faster then typescript on development time. And Safer there they do the check on run time. So check the console output of your browser

Incredible Autocomplete
Hope this is a joke, there i have full compatibility of auto-completion of JS code

TypeScript As A Default For New Projects
My opinion is a big NO. It woud help on code time. But the ability of bug fixing on runtime is not in scope, and these developers would always point to external excuses. And aren't able to find the problem of the bug without doing a lot of debuggers.
Also Javascript isn't a type programming. Typescript will be translate to Js with out typechecking.
Also to compile in development takes more time.

 
babakks profile image
Babak K. Shandiz • • Edited

Data validation is a totally different thing than strong typing. The latter ensures your codebase is consistent regarding various data types flowing through it, whereas data validation asserts runtime input compatiblility (of course from outside world, AKA application boundaries) with what the code expects.

While strong-typing is not a must (however makes design/develop a whole lot easier and insightful,) but validation is always required, no matter what programming language or platform you use.

If that helps, as a metaphor, data validation is like the security guard that verifies legitimacy of people entering a military base and makes sure everyone is suited with their formal camo with visible names/ranks, while strong-typing is like the set of military rules that defines the hierarchy and the chain of command.

Thread Thread
 
rkallan profile image
RRKallan •

@jfbrennan & @babakks
nice clarifications.

As developer i learned and will teach also defend programming.

@lukeshiru
I strongly advice you to be open for different views. Listen and try to understand the arguments. Try to avoid putting people in a box, saying they didn't actually did any real work, they missing points etc etc. Changing given examples to proof your vision.

Collapse
 
rkallan profile image
RRKallan • • Edited 
const typedAdd = (value1: number) => (value2: number) => value1 + value2;
Enter fullscreen mode Exit fullscreen mode

Will be after transpiling and production ready

const x = (a) => (b) => a + b
Enter fullscreen mode Exit fullscreen mode

So after building a production build all your ts type check will be gone.
And therefore your function will except all kind of types.

You mean the same propTypes that were removed from the core of React because we have TypeScript and the same Flow that nobody wants to use nowadays?

propTypes is removed from the core because the vision of react is that you must be able to configure your dev app as you want and with the most minimum amount of package size.

It depends. Yes, you get autocompletion of JS but only when the editor can infer the types of stuff or you added the proper JSDocs for that.

I had never problems with auto completion with my created libs in JS. And still I doesn’t have
Yes when your lib has a .ds.ts file it will only use the declared and exported for auto completion

And JS is a typed system, just because you don't write the types it doesn't mean you don't have them.

JS isn’t a type program. TS is a superset of JS. To be able to run your code it needs to be transpiled to JS. JS doesn’t care if value changes from type.

Even with unit or e2e test you can’t prevent when api gives you a different type then discribe with TS. Also on production there is no type check. Even on development there is no type check on runtime. In that case you don’t see warning / error on development when running your code and calling an api.

I have enough examples in professional business settings where developers couldn’t find the bug. Because they said testing is succes and no compile errors.
And they said there is no bug. But on production the code was failing and throwing an error

 
rkallan profile image
RRKallan •

it usually happens when you didn't actually did any real work with TS

It might be wise not to make assumptions. Assuming I haven't actually worked with TS?
Led multiple projects as lead where we use TS

// Let's say I want `x` to only have numbers, then the code stays the same:
let x = 1; // type is number
x = x + "hello world"; // type of `x` is still number, so error here because you're trying to assign a string to it.

// But now I want `y` to be either a number o a string:
let y: number | string = 1;
x = x + "hello world"; // No errors here, in the line above I said this is actually what I want.
Enter fullscreen mode Exit fullscreen mode

the last x will throw an error with TS

My assumption, it needs to be

let y: number | string = 1;
y = y + "hello world";
Enter fullscreen mode Exit fullscreen mode
 
rkallan profile image
RRKallan • • Edited

When you use it you have the types, but the browser or node don't need those types, the types are there to help you as a dev

You mis the point that you still need to code checks to prevent unexpected behaviours and crashing application.

const toHex = (value) => value; i get autocompletion in my editor

You really need to read a little more about JS types. JS uses types internally. Just use typeof with a value.

typeof has a disadvantage see example code

console.log(typeof []); // object
console.log(typeof null); // object
Enter fullscreen mode Exit fullscreen mode

to get the correct type of your value

console.log(Object.prototype.toString.call([]).slice(1, -1).split(" ")[1]. toLowerCase()); // array
console.log(Object.prototype.toString.call(null).slice(1, -1).split(" ")[1]. toLowerCase()); // null
Enter fullscreen mode Exit fullscreen mode

I'm expressing myself wrong, to say JS is not a type program. What i meant JS is a weakly dynamically-typed language and type checks are at runtime and it allows implicit conversion between unrelated types

TypeScript / Python is a strongly typed programming language and type checks are on compile-time and doesn’t allow implicit conversions between unrelated types

example JS

let x = 1 // type is number
x = x + "hello world" // type is string
console.log(x);
Enter fullscreen mode Exit fullscreen mode

example Python

x = 1;   #type assigned as number.
x = x + "hello world";   #type-error, string and number cannot be concatenated.
print(x);
Enter fullscreen mode Exit fullscreen mode
Collapse
 
rammina profile image
Rammina •

Thank you for sharing your insights about Typescript!
While I do agree with the majority of your points, here are some downsides that make me not use it sometimes.

 
rkallan profile image
RRKallan •

You see, you didn't read what I wrote at all

And again making a wrong assumption. I read your comments.

If the API gives you different values, the problem is not with the types, is elsewhere (API architecture, mainly).

my comment

TypeScript / Python is a strongly typed programming language and type checks are on compile-time and doesn’t allow implicit conversions between unrelated types

your reaction

You're wrong again, but I understand, it usually happens when you didn't actually did any real work with TS.

one of the first things on typescriptlang.org

TypeScript is a strongly typed programming language that builds on JavaScript

and so we can go on.
I notice already you are avoiding given points.
I wish you luck on a national / international big brand, own JS package national / international used.

 
rkallan profile image
RRKallan •

No need to tell me the difference, ether i don't need to google to get now about the differences. And this is exactly a point which i mentioned on my previous comment and is not the first time you do this, not only on me.

As previous said, where my feeling is you are ignoring it, i'm working with TS on my projects, Im up to date and now how to use. On these projects i'm the lead.

The fact is you don't care about runtime behaviour.
In your opinion you have a perfect code with type check on compile / development time.

All unexpected behaviour on runtime is a problem from outside.
Even when your application crash you will point out to external facts, and not your problem.
And i can bet you won't be able to find the bug, or you will need a couple of days to figure out the problem.

 
rkallan profile image
RRKallan •

Good to hear that you don't put people in a "box", and you open for different views :)

From my side, and my assumption of your opinion is as follow.

As i understand your opinion is when using type check, on compile time / development time, is safe enough for your code. And when there is unexpected data coming from example an api, the api needs to deliver as expected.
Based on this it could crash the application because unexpected data. User can't continue and refresh will lead losing data stored with for example Redux.
So my vision is as JS develop you need always be aware and prevent application crash and unexpected behaviours on runtime.