JoelBonetR 🥇

Posted on Apr 26, 2022 • Edited on May 8, 2022

To TS or not to TS, that is NOT the question. Is it?

#javascript #typescript #discuss #devjournal

There's like a fight or something like that about JS vs TS and I always like to go against TS in TS posts and against JS in JS posts. This way I get solid sentences about pros for one or another.
This makes me look like a troll but most of you guys only put a good amount of attention when you read something that bothers you or that is against your believes 😆 be honest and don't blame me much for this (please).

I'll try to recap things straightforward and give you a good option as middle point in a vague try to stop that war from now on.
You can laugh as much as I'm laughing at the time of writting that down 😆

The question would be:

Which are the main reasons to use TypeScript?

1. Type Inference

Type inference is the automatic deduction of the data types of specific expressions in a programming language.

It works when calling a function/method so the IDE knows how many params does it need, which type they should be and will complain if there's something wrong.

It also lets you hover your mouse over the function name and you'll get inferred information about this function/method like the params and it's types, what it returns and so.

2. Real-time type checking

When you have an object in JavaScript, you can access every property of that object either the object having this property or not.
This can lead to errors that are difficult to debug. In Typescript, your IDE tells you in real-time that you are trying to access something that doesn’t exist or that lacks this property or if you try to use some non-compatible method/function on it.

TypeScript always points out the compilation errors at the time of development (pre-compilation). Because of this getting runtime errors is less likely, whereas JavaScript is an interpreted language.

3. Interfaces

You are able to set up interfaces in TS by default whereas in JS you need some external lib like implement-js or validate a schema using validation libraries like Joi.

Ok so we all understand and agree that the points 1 and 2 are a MUST.

Can we all -please- agree as well on the sentence "to reach this in JavaScript (nicely) we need TypeScript"?

Ok, let's move on.

How can we reach that?

We have 2 ways to use TS in our projects.

1- One is to add TypeScript as project dependency, perform the setup and start coding. You all know about that or you can find tones of information about this online so I'm not extending on that.

2- The second one is to use TS Pragma in your JS files along with JSDoc and enforce the overall with a linter like ESLint.
VSCode will handle that out of the box in real time. Zero config needed.



// @ts-check

/**
 * Calculates the total weight of the inventory
 * @param {string} inventory
 * @returns {number}
 */
function inventoryScore(inventory) {
  let totalInventory = 0;

  inventory.split(',').forEach((item) => {
    totalInventory += getItemWeight(item.trim());
  });

  return totalInventory;
}

/**
 * Retrieves the weight of a given item
 * @param {string} item
 * @returns {number} weight of the item
 */
function getItemWeight(item) {
  if (item === 'gold cup') return 5;
  else if (item === 'puppy') return 4;
  else if (item === 'magic cup') return 10;
  else if (item === 'tooth of a magestic whale') return 20;
  else if (item === 'tentacle of a giant squid') return 100;
  return 0;
}

Copied this code from my own comment on this post as example.

Which benefits do we get using TS Pragma and JavaScript?

We got documentation enforced by the workaround:
Type-checking in Dev Time:
Type inference (Even without explicitly declaring puppyWeight type):

Of course the same happens with variables:

We can also define variable and constant types with inline JSDoc like that:

We also avoid the extra-build time that adding TS as dependency causes.

For those thinking on "yeah but people will refactor things and forget about documentation", well, TS Pragma will use TS behind the scenes to ensure it's OK plus we have a linter, so we can use it. Check the ESLint plugin JSDoc.

As extra benefit, this approach can serve as introduction to TS, getting yourself used to declare types and forcing you to document your code (which is always good).
If you want at any point and for any reason to migrate your project from JS to TS it will be much easier.

Cons:

This workaround does not let you use all features that TS brings. i.e. you can't use generics afaik.

Till next time! 😄

Do you like my content? ☕Buy me a coffee

Still here? Pin this JSDoc Reference

Will you take a try to this approach? Let me know in the comment section

Best regards

Top comments (63)

Christian Engel • Apr 26 '22 • Edited

I was strongly against TS not too much time ago. I hated it. It made me feel incapable of expressing my thoughts in code anymore. It prevented my from using JS as I was used to. My code worked stable most of the time and JSdoc helped a lot in adding types to functions and variables.

When i started using TS, I was constantly fighting the compiler which spit out long and complicated error messages.

Those days are gone now. I fought my way through and came to piece with TSC. I use it every day now and would not start any JS project without additional TS guidance.

About your post:
JSdoc is good and fine but it has its limits. I am much in favor for adding descriptive comments on top of functions but the type descriptions just dont cut it. The TS syntax is extremely more expressive.

I also have the feeling you are missing a lot of what TS can give. You mention for example that TS interfaces are only good for OOP. Thats wrong. You use interfaces to describe objects and their properties - and objects are passed around in JS all day. In fact interfaces are my most used feature of all.

JoelBonetR 🥇 • Apr 26 '22 • Edited

Totally agree,

Editing the OP according to that!

my scope for the last year has been React and NextJS (plus few Node) so prop-types work best than adding TS interfaces as prop-types are checking in runtime plus it lets you define clearly which props are required, which ones are optional and in case they are optional, it makes you add a default.

In Node I usually use Joi which covers the same need.

About JSDoc limits... I don't think it really has many, check this out typescriptlang.org/docs/handbook/j...

Christian Engel • Apr 26 '22

I am working in a similar environment (nextJS frontend for a huge news portal in germany).

We are not using prop types at all in favor of: typescript interfaces! :D

Ususally, a component looks like this:

interface Props {
    id: string;
    title?: string;
    count: number;
    currentUser: UserObject; 
}

function MyComponent({id, title = "Default", count, currentUser}: Props){
    ...
}

JoelBonetR 🥇 • Apr 26 '22

You can combine the JSDoc approach with PropTypes.
Remember that TS interfaces and Prop Types are not covering the same need.

Prop Types offer runtime checking while TS does not plus it lets you define optional and required props and enforces you to add a default for those which are optional 😀

Christian Engel • Apr 26 '22 • Edited

Runtime checking is absolutely unnecessary - except at the point where foreign data enters your system. So static type checks are better since they do not unnecessarily clog your runtime execution.

About optional and defaults: thats perfectly possible and I used it in my example. title is optional and has a default.

Christian Engel • Apr 26 '22

Oh and by the way: as far as I know, the runtime checks of prop-types only work in development mode and is removed from production builds - so you get the sameas with TS.

JoelBonetR 🥇 • Apr 26 '22 • Edited

In my current specific use case there is a headless CMS that manages both the structure and the data to show on it.

It's better to not remove them and fallback to a controlled error if it suits instead.
Removing them is something that you need to actively config, not something that works like that out of the box.

On the default thingy, we can receive relatively big chunks of data thus It's less invasive or more maintainable to get defaults defined in prop-types instead on the component definition.

It's all about the use-case like always :)

On the other hand, by all means this post is about having different options, not an allusion to fight between two tech stacks. You can use whatever you want, but you should use whatever your project needs.

A possible TL;DR would be "Is better to use TS, but just use the amount of TS you really need" 🤷🏻‍♀️😂

CuriousDev • Apr 27 '22

At least if we are about the question "should I learn JS or TS?", I would say, that it makes more sense to start with JS in case this did not happen yet, because TS just extends it. Regarding the usage, as you ask with this article, I guess TS should be preferred, if possible. Requirements can be fundamental knowledge about JS and having additional experience with TS.
There is still the option to switch from a JS project to a TS project, especially if you have well written code (but I do not have much experience to verify this at the moment). If this is not the case I would also doubt, that TS necessarily makes everything "magically" better. You still need to code carefully.

JoelBonetR 🥇 • Apr 27 '22

I completely agree with that. It has been a mantra on the community that TS makes your code better but it simply can't be true.

Experience, practice and having enough time is what makes a better code and a better coder. I've seen with my two functional eyes big messes using different languages, frameworks and so and I've seen beautiful code in some of them (including vanilla JS).

Which are the main reasons to use TypeScript?

1. Type Inference

2. Real-time type checking

3. Interfaces

How can we reach that?

Which benefits do we get using TS Pragma and JavaScript?

Read next

pyya - The way to manage YAML config in your Python project

Why are Props Immutable in React?

State of JS 2024 Outreach and Diversity Report

My 2025 AI Engineer Roadmap List