DEV Community

Cover image for Why You Should Use Typescript Over Javascript?
Shreyansh sheth
Shreyansh sheth

Posted on

Why You Should Use Typescript Over Javascript?

What Typescript Actually Is?

Typescript is a strongly typed programming language like Java or C and typescript compiles into javascript so that we can use it in our browser or other platforms.

Reasons To Use Typescript Over Javascript

  1. Type Safety

    Typescript Typecheck
    When we do dynamic assigning in javascript it allows us to do that and also it will give us expected results. but if you are working on a large codebase you are not going to track each variable and ensure the types of each of them

  2. Better Auto-Complete

    Typescript provides a complete type system so that ide/text editors eg.vs code can give you better autocompletion on your whole project and increase your productivity.

  3. Conversion From Javascript To Typescript

    jsts
    Every valid javascript is a valid typescript. so you can start by converting your file to typescript files and set the rules of typescript low and make it strict as time goes on

Where To Start

Tyescript Website And Doc
Freecodecamp Video For Typescript

conclusion

Typescript is better tool to use when you are comfortable with javascript and need more control over your codebase and want to catch silly mistake on compile-time rather than runtime.

Discussion (23)

Collapse
tqbit profile image
tq-bit • Edited on

Note that you can also use jsdoc for ts-like typing.

jsdoc.app/tags-typedef.html

VSCode also has this convenient builtin feature that allows you to infer types from those comments. You just have to activate this one:

"javascript.implicitProjectConfig.checkJs": true
Enter fullscreen mode Exit fullscreen mode

I get why people prefer TS over JS Really. I just also noticed TS types clutter the code quite a bit (especially if you're used to dynamic typing) and require an additional compiling step. I seldom see this considered in posts about the two languages.

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

Yes, I do use JSDoc, along with // @ts-check, if I had to use JavaScript.

However, not only that it is harder to declare complex types, but also that IntelliSense is still less smart, even with ts-check on.

Collapse
tqbit profile image
tq-bit

Your comment got me curious on complex types - I haven't used JSDoc trying to declare such yet. Can you please explain this a bit further?
I couldn't find a lot of good examples in the ts docs, neither on the www.

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt • Edited on

As far as I know, you can

  • Use /** @type {} */ to specify types for a variable
  • Use /** @type {} */ (x) to force a variable to type
  • Use /** @typedef {} */ to declare a type in advance

But still,

  • I don't know how to declare generics.
  • I don't know how to export types of JSDoc from a file.

BTW, much of typing works inside /** @type {} */'s bracelets. You can even use import().Class and use TypeScript interface syntax inside them.

Collapse
shreyanshsheth profile image
Shreyansh sheth Author

Yes, JSDoc is also a nice alternative if you don't want to use typescript .basically they both achieve the same things differently. ‚Äč
And One more compiling step does not affect anything at all because in the end, you are getting what you need.

The main thing is it boils down to personal preference that how you prefer writing your code.

Collapse
jfbrennan profile image
Jordan Brennan • Edited on

One more compiling step does not affect anything at all

But it does. It adds dependencies to your project. Dependencies have to been installed, updated, and peer-dependency issues are major pain. It also increases build time. It also requires additional configuration, which is often a pain to work with. As the complexity of the project grows you have cases that conflict with TS and you have to start making tradeoffs between doing what needs to be done vs. making the compiler happy. You also have to remember that the compilation step is a bit of false sense of security, i.e. programmers often joke "But it compiled!" when the app fails at runtime.

Like many others, I've found the cost of writing non-standard dependency- and config-laden code that still doesn't ensure runtime safety is too high to justify its small benefits. A good IDE does all the inference and code-complete you need, the rest is noise imo.

Collapse
anuragvohraec profile image
Anurag Vohra

jsdoc is way cumbersome to use, as compared to typescript (especially Typescript infering many things on its own, where as jsdoc is bit verbose).
Further more, Typescript provide compilation, and future javascript now.

Collapse
tqbit profile image
tq-bit

I get your point. You've got to learn it, but so would you have to get used to Typescript syntax. I didn't really find it cumbersome. And about verbosity - that's what JSDoc is there for I guess. But instead of having all the types inside your code, you can keep them separate and even enrich them with intel that eventually ends up in your technical documentation. I'm sure there are ways around this as well, but then again why use TS next to JSDoc for automated doc creation?

Collapse
kalashin1 profile image
Kinanee Samson • Edited on

TypeScript was built for application development, i Write and ship out products built with TypeScript faster than those built with JavaScript.

Collapse
morgantuber profile image
morganTuber

TS types clutter the code but I am fine with js doc lengthy types clutter.?????????

Collapse
jonrandy profile image
Jon Randy • Edited on

Horses for courses.

For a lot of projects, TS is simply overkill (like a lot of stuff these days - looking at you, React). Often, we should simply embrace JS for what it is, and how it works. Dynamic typing can be extremely useful, as can features like implicit type coercion - if you understand them and how to use them. A lot of developers simply use TS as a crutch when coming from a strictly typed language, to avoid having to learn how JS does things. This is a mistake

Collapse
shreyanshsheth profile image
Shreyansh sheth Author

That is not the case when you use typescript. You can use dynamic types when needed but dynamic type is so much prone to errors when working with team.
Also note that typescript does not change anything it just add layer of types on top of javascript so developer can get better experience programming.

Collapse
jonrandy profile image
Jon Randy • Edited on

I know what TS is, what it is used for, and how it works - I've used it, and can see why it can make sense in some projects. I'm just saying it isn't a good fit for some projects and it just adds unnecessary fuss and overhead.

It's also debatable whether having a layer of types on top of JS gives a better experience to the developer. Some developers (myself included) prefer dynamically typed languages and dislike the extra formality of working with typed code.

Thread Thread
shreyanshsheth profile image
Shreyansh sheth Author

At the end it is personal preference. But if you are working on team than person preference does not matter that much and also type safety is must in some situations where you have to manage lots of things.
Every team that I've worked on uses typescript for better development experience across the board.

Collapse
rammina profile image
Rammina

Typescript still has some scenarios in which it should not be used over JavaScript.
One of the few reasons include more boilerplate, longer build/compile time, less flexibility, lack of support in some libraries, and so on.

There are more here, if you'd like to check it out:
dev.to/rammina/downsides-of-typesc...

Collapse
haaxor1689 profile image
MaroҰ Beҕko

None of the points you've mentioned there are points against using typescript. I would argue there isn't a single project that you shouldn't use Typescript on. Even if you just add a bare minimum non-strict tsconfig and use no explicit types at all it's basically javascript but safer. You can't be bothered by thinking about what your function arguments types should be? Just use any and go the js way. But don't complain when half your codebase catches fire in 2 months after you decide to do a seemingly unrelated refactor.

Collapse
rammina profile image
Rammina

Let me ask you questions:

  • would you use Typescript if an important library you will be using has no type definition files?
  • do you think it is worth writing type definition files down yourself?
  • are you sure that using any over and over again will not have any negative consequences or create a false sense of security for a development team that uses Typescript?
Collapse
shreyanshsheth profile image
Shreyansh sheth Author

any is only useful when you are stuck in something that does not have type defs and also when you are working with some javascript library that does not have any types. also note that i wrote starting out with loose typescript configuration and make it strict along the way.

Thread Thread
haaxor1689 profile image
MaroҰ Beҕko

Not even for that. You shouldn't use any at all and use unknown and never instead. I've used any as an example for someone who doesn't really want to use typescript.

Thread Thread
shreyanshsheth profile image
Shreyansh sheth Author

i 100% agree that any is the troublemaker and we should be using never & unknown.

Collapse
bcowley1220 profile image
Brendan Cowley

Different strokes for different folks. It really comes down to personal preference, and maybe one day we'll all get on the same page with there is no one right way to do anything and that you pick the right tool for the right job not use a 10 ton sledge hammer in every single instance.

Collapse
kalashin1 profile image
Kinanee Samson

Once you start building industrial scale apps, you can't use JavaScript.

Collapse
cjsmocjsmo profile image
Charlie J Smotherman

So what did the large industrial scale apps use before typescript was released then?

So yes you can use just javascript, typescript just makes it easier