DEV Community

Cover image for Why Every Developer Should Learn TypeScript: My Experience

Why Every Developer Should Learn TypeScript: My Experience

MrSuperCraft on January 23, 2025

TypeScript has become a game-changer in modern web development. When I first started coding, JavaScript was my go-to language for everything, from ...
Read full post
Collapse
 
gesslar profile image
gesslar •

Don't make the mistake I did, however, and try to refactor a WIP project from JS to TS. It's a nightmare.

I'm going to have to learn TS on something from scratch.

Collapse
 
pengeszikra profile image
Peter Vivo • • Edited

You are true! TS until don't get enough experience of it is harder at first sight - this is same for JSDoc also which is technically TS just a bit better.

my answer for title:

Because they are don't know the JSDoc are better:

/** @template T @typedef {(a:T, b:T) => T} TwoParamToResult */

/** @type {TwoParamToResult<number>} */
const add = (a,b) => a + b;

/** @type {TwoParamToResult<number>} */
const sub = (a,b) => a - b;

/** @type {TwoParamToResult<string>} */
const hello = (welcomeSentence, name) => 
  `${welcomeSentence}: ${name}!`;
Enter fullscreen mode Exit fullscreen mode

-- this generic also works in TS, my opinion of TS vs. JSDoc is: dev.to/pengeszikra/jsdoc-evangelis...
... my real world, a bit complex than a TODO list example:
dev.to/pengeszikra/javascript-grea...

Collapse
 
mrsupercraft profile image
MrSuperCraft •

I wouldn't necessarily compare between TS or JSDoc because each of them has its merits and values. JSDoc is strong for explaining JS code with the use of written types, but not as flexible when it comes to custom types that can be abbreviated, like TypeScript.
Where JSDoc misses, TypeScript shines. Conversely, TypeScript is sometimes not as safe as it seems and could largely vary with the compiled JS code based on the compiler, which lacks consistency sometimes, something which is not a problem on JSDoc.

Collapse
 
brense profile image
Rense Bakker •

The biggest advantage you mention is already being fixed in nodejs and most other runtimes had typescript support out of the box. Only the browser remains as a place where you can't run typescript directly, but nobody I know runs uncompiled code in the browser, whether they use vanilla js or not. 🤷

Thread Thread
 
pengeszikra profile image
Peter Vivo •

This is just a half solution and bleeding in many angel. Because if nodejs are make a runtime typecheck on TS code in JS before the JS JIT are run the code that means it is slower than run a pure JS code.
But I readed the nodejs solution, which is technically just a type stripping. Which is also spend a time, but lot less than a runtime type checking.
I don't know the other runtime solution. But the pervious sentence is right for them.
Other problem with this node fix thing is: on company projects are run on dedicated node version, because that is don't realistic to uppgrade every package capable to run on a latest node.js. That is a pain point of legacy codebase. Year by year that is worst.
The frontend code is run on browser, so don't option to not compile TS.

I use uncompiled code in browser, and thx that way is working very fine, also that is important, because not every js code are compiled a classic way, some are uncompiled when for example just copy paste in a wordpage or any other PHP backend. But when other non JS BE are generated html page with js code is also question that code is compiled or not.

That why JSDoc have advantage of TS.

Thread Thread
 
moopet profile image
Ben Sinclair •

I use uncompiled code in the browser too. I mean, there are loads of cases where adding a build step is just bloat, so why wouldn't I?

Collapse
 
xwero profile image
david duymelinck • • Edited

I caught type-related errors during development rather than at runtime

That is one of the biggest mistakes people make.

 function add(a: number, b: number): number {  
       return a + b;  
   }
Enter fullscreen mode Exit fullscreen mode

compiles to

function add(a, b) {
    return a + b;
}
Enter fullscreen mode Exit fullscreen mode

If you have add(5, "10"); in the codebase it will register an error. But after it is compiled the function executes without an error.
On a server it is not a problem, but the code you push to the browser is public.

Collapse
 
mrsupercraft profile image
MrSuperCraft •

You're absolutely right to point out the difference between TypeScript and JavaScript, and I appreciate you bringing it up. TypeScript's static type checking happens at compile-time, which means that while we might catch type mismatches (like add(5, "10")) during development, the compiled JavaScript won't enforce those checks during runtime.

As you mentioned, this is not as critical on the server-side, where type errors can be caught in a controlled environment. However, when it comes to the browser, it is important to be mindful of how the JavaScript is executed in a public environment. This is where additional runtime validation (such as input validation or using runtime type-checking libraries) can help ensure the safety of function inputs, which was outside the scope of my article, but definitely a key point to consider in real-world applications.

Thanks again for pointing this out!

Collapse
 
xwero profile image
david duymelinck • • Edited

I use javascript with value objects.

class NumberValue {
  constructor(value) {
    if (typeof value !== 'number') {
      throw new Error('Input must be a number');
    }
    this._value = value;
  }

  get value() {
    return this._value;
  }
}

function add(a, b) {
    return new NumberValue(a).value + new NumberValue(b).value;
}
Enter fullscreen mode Exit fullscreen mode

And that solves the problem on the server and in the browser, without any dependencies.

Typescript for me a solution that gives people a false sense of security. When people that use compiled languages see typescript, they can think it behaves as their language. And for people that start programming, they won't understand the difference between checking at compile time and checking at runtime.

Thread Thread
 
mrsupercraft profile image
MrSuperCraft •

Your provided code is clearly checking for a number type on the NumberValue class - No doubts about that. However, the solution is rather lengthy and won't be reusable for different kinds of values. For your example, it definitely serves as a good solution.
For cases in which you need a wider range of applicable solutions such as yours, I would suggest using Zod or Yup which are excellent libraries used primarily for form validation.

Typescript for me a solution that gives people a false sense of security. When people that use compiled languages see typescript, they can think it behaves as their language.

I'd argue that there is some merit to this, however it misses the point of stricter type checks and the ability to create more robust code with the use of types. Sure, compilation to JS does stuff to the code and strips off types in the process, but overall it's a superset of JS so it is expected to sometimes have problems when compiling down to JS.

And for people that start programming, they won't understand the difference between checking at compile time and checking at runtime.

I agree with you on that one. Personally, I wouldn't advise learning TypeScript before JS because you could get into the assumption that everything works the same after compilation, and that is not really the case with such a complex language like JS, that TS code is compiled to.

Thread Thread
 
xwero profile image
david duymelinck • • Edited

However, the solution is rather lengthy and won't be reusable for different kinds of values.

How is it not reusable?
I agree it is lengthy, but creating a data object in these times of AI is not more than one line of text.
Data objects are also composable, so you can add wrap a basic data object in an object with specific business rules or combine multiple ones in a bigger object.

I would suggest using Zod or Yup which are excellent libraries used primarily for form validation.

The problem with the libraries is that they serve one purpose, form validation.
Data objects can do anything you want them to do, because a part of the definition is that the data must be valid.

however it misses the point of stricter type checks and the ability to create more robust code with the use of types

I agree typing is a good thing.
I was listing a few cases where typescript can be a cause of problems because people are not aware of the trait offs that have been made by the language.
And because it is an industry standard, I think it is a very dangerous language.

Collapse
 
edem_jack_fb61387496ec3e7 profile image
Edem jack •

I totally agree! TypeScript has made a huge difference in my workflow as well. The static typing and early error detection really help catch issues before they even get to runtime Edu Updated. It’s definitely a game-changer for any developer looking to improve code quality and confidence.

Collapse
 
pedrosmasson profile image
Pedro Masson •

What about us, desktop developers? :I