Sell Me On Typescript

"why must I use it?"

You don't have to, but I think you'll learn a lot if you do.
^this

All I can do is to promise you'll thank every developer (including your past self) if they write their code with static types.

Don't like TS for typing? Maybe you'll prefer JSDoc: typescriptlang.org/docs/handbook/j...

My recommendation would be to not let it slow you down. Make good use of the typescript config file, ensuring that the strictness is calibrated to the level you need. It's phenomenally productive to catch sneaky bugs at compile time, even if it may not seem that way on the front leg of dev.

The awesome thing about the ts-config compiler options is that you can scale them up over time. The goal is to have full strictness enforced, but if and when that slows you down then by all means dial it back. The goal is DX and developer productivity, it just so happens that specifying types at compile time do allow for huge amounts of preventative measures

Once you get the "hang of it" you won't be battling with it. It will become second nature to build variables and type them.

By doing so you won't see as many type errors and such. It's just a learning curve. Persevere and you will seen the benefits !

TypeScript has a fairly large learning curve (I would say larger than some real statically typed languages like C# and Java) and it WILL slow you down on small projects. It's also easy to use TypeScript poorly, and not get much benefit out of it, if you just throw any at any sign of a problem.

But when you get into large projects, especially when you're working with other people, it will accelerate you and make your code better (if you use it well, anyway). Refactoring gets much easier, intellisense gets much better, you know what kind of data you're working with.

Some people are all-in on TypeScript and use it for everything. I'm not one of them - I find it a waste of time for relatively small, personal projects. But I'd never consider using plain JavaScript for anything substantial anymore.

My argument for typescript has 2 parts:

• intellisense benefits from the definitions as you write them, and it paints a picture for other developers that come before you (though I know jsdoc can do this as well, it is easier for developers used to strictly typed languages to adapt)
• many of the features of typescript come out long before javascript adopts them, so it has a great track record of predicting what javascript will do. Having a head start on newer patterns gives you an advantage when the world eventually phases out typescript and leaning into most of its features.

My own personal reasons for using typescript involve being able to be self-accountable and make sure all the contracts I write with the code are properly handled. It can give you some freedom when writing internal code, so you don't need to necessarily write tons of runtime checks on the data since you know the compiler will check for a lot of that. The only areas where data checking is really important in typescript is when you have an external data source (or input) that could come in during runtime that can possibly not meet the structure contract. As you adapt to the nuances of the flavored language, it gets easier and faster to build.

The biggest evidence of your struggle not being with the language is that the code you write does not obey the rules you write, so its more of an issue of how you are writing the code, not with typescript itself. Think of it like training wheels. Eventually with enough coding in typescript, writing a specific way will become second nature and you can take those practices with you into JavaScript.

Typescript is simply the same Javascript but extended with typing, but not only that. You’ll become better JS dev, with the full picture of this technology whether you use it widely or not, OOP, style of coding, tests, security, new features (ES2022..) and etc.

You do not "have to" use it. You would use it, because from what it offers on top of JavaScript you could think it is worth it. There is no need to use it, because you "have to". Typescript bascially is just an extension of JavaScript and allows you to use strict typing, which would make it comparable to lanuages like C#. Editors can make use of it and make development easier (show you allowed methods etc.) as well as allow you to integrate these types as a kind of "rules", which will lead to code, which does not get built, if you break these "rules". There would be no error during the execution in this specific cases, if you could not use it this way. If you want to use some of these points, which I just have described, for your project, you can see them as a must.
But you are not forced to used it and if you are still learning JavaScript, then stick to it for some time before you add with TypeScript to the language's complexity (my opinion at the moment).

Adding types to your code in general is tremendously helpful when working on larger projects, regardless of the language. I've found static analysis tools like Psalm incredibly useful in PHP as well - it's found an awful lot of problems in legacy code.

There's a few options for adding types to JavaScript and while I have used Flow in the past, and still prefer it conceptually to the idea of a whole new language, the tool support is significantly better in Typescript. There are some things Flow does better (opaque types are frustratingly still not a thing in Typescript), but overall Typescript is the better experience.

I hear you Brother. I've been told right here on Dev.to that I'm dumb, stupid, illogical, and many other pejoratives. They all were Javascript only purists who even denounced their own language adopting classes. These are the same folks that write 5,000 line mono repos filled with magic strings who don't follow DRY. Talking about insanity.

You should only use typescript if you care about the mental wellbeing of whoever has to maintain the code after you're done with it.

Btw, you can always make typescript happy by typecasting to unknown firsts and then any. Not saying you should do this in production code, because you essentially lose all the benefits of typescript if you do this, but it can be helpful while learning. Once you get your code running, you can revisit the ugly type castings and determine how much time you want to take to "fix" it (spoiler: its usually much easier than you think and gets even easier as you learn more about the typescript typing system).

It also helps to use packages that have proper typings, or that have associated @types packages. You don't usually have to do any typing when packages are properly typed.

The primary value-add that I have found with TypeScript is that its features add quality controls to your JavaScript project.

Is it necessary? No, but the value does become evident when an active project scales in complexity and age.

One of my active SaaS products is a Node.js app that started in 2012. Little/no tests, callback hell, and enough features to sell to the enterprise. When I was the team lead on that product’s mobile application, I would have to remediate bugs several times a year when a team member building features for the web modified a shared method and removed/modified an output. If we had types (or tests tbh) around the method’s I/O contract then it would have been caught before merge.

Additionally, callback hell paired with an architecture that IDE’s didn’t fully understand meant significantly more time mapping out process flows within the application. I had to do it a couple times when turnover left me as the one responsible; those efforts took several hours over multiple days, often repeating the exercise multiple times to validate the flow was accurate.

Today, I write all of my application source in TypeScript for new projects if I’m building a JavaScript runtime, but some things like Grunt.js are still authored as regular JavaScript

for frontend, i don't think it requires that much of types except when you are passing different data throughout the components and for the back end it becomes incredibly useful when you are able to look up what you need to pass and in which format

Well I don't know.

On one hand I love static typing. In Rust or Kotlin, it takes you by the hand and helps you figure where you are and what you are doing. Very useful.

There is also the case of typing annotations in Python which are super useful for the same reason. I write them all the time and it's no bother at all.

But then when I try TypeScript I feel like I'm fighting against the world. The whole JS world is not built around typing and especially inputs from the API. Taking in all this external data (which let's face it is the largest chance of getting a typing problem) is always super tricky.

On the other hand I'm using Vue and PyCharm, which handles Vue super well so all the auto-complete basically just works without me having to take care of annotating anything.

Not sure what to make of that. JSDoc is indeed probably a better way to go. Getting 99% compliance (JSDoc) is easy but 100% compliance (TS) can be a fucking pain in the ass.

Just another layer of crap that's not needed in most project's.

Have you tried typescript yet ?
What was your experience like ?
After trying out typescript by building some toy project, why on earth would you go back to using some awful alternative like flow or even @JSDoc