DEV Community

Cover image for Pitch me on TypeScript
Ben Halpern
Ben Halpern Subscriber

Posted on

Pitch me on TypeScript

Part of a new series! Feel welcome to dip in and weigh in on a past question.

Let's say I've never used TypeScript before. Can anyone give the run down of what the language does and why you prefer it? Feel free to touch on drawbacks as well.

Top comments (48)

Collapse
 
mxrcochxvez profile image
Marco Chavez • Edited

I can’t believe this doesn’t have more discussion yet! My favorite part about using Typescript is that it’s self documenting! When you specify the props and the return type when defining the function and you’re using an editor like visual studio code - wherever you call the function you can hover over the name with your mouse and it tells you exactly everything about that function.

An added benefit for us React devs is that it helps you with remembering to send all required props to a component in React since you’re able to pre-define prop types.

It’s balanced. Depending on the project you’re making, you can configure Typescript to catch more or less code quality inconsistencies in the config file!

Collapse
 
haydenmcp profile image
Hayden McParlane

I've never actually written any serious TypeScript though I've been working with JavaScript for a while. Even for me, though, the self-documenting nature of TypeScript is really helpful. For example, when I'm looking at an npm package to see how to use it TypeScript makes it easy to understand. I read it all the time.

Collapse
 
mxrcochxvez profile image
Marco Chavez

Yeah exactly! Even when you aren’t using TypeScript it’s beneficial that people have written npm packages with TypeScript. Thanks for your contribution to the discussion. That’s another great point.

Collapse
 
diballesteros profile image
Diego (Relatable Code)

The self-documentation is definitely one of my favorite parts. Used correctly it helps me come back to my code months later and understand what the heck I was trying to do.

Collapse
 
gavravs profile image
Gourav Dhongadi

Can you suggest some good resource to learn typescript

Collapse
 
harrywonder profile image
stephen

Hello Gourav, I’m currently working on a typescript project for beginners. Hope you don’t mind if I share the repo with you once I’m done?

Collapse
 
mxrcochxvez profile image
Marco Chavez

youtu.be/BwuLxPH8IDs

This is a YouTube video I followed! But I mostly just used the documentation and experimented in the projects I was working on.

Collapse
 
nickytonline profile image
Nick Taylor • Edited

I've written about it before, but the big things for me are the refactoring story, discoverability, avoiding silly mistakes, and adopting into as much type safety as you want. For example, you can add TypeScript (TS) to your project and enable the compiler options to allow for JavaScript (JS) files. Just that alone you'll already see a benefit. I would suggest being as strict as possible, but when migrating a project from JS, this is a great way to do this.

Generics and having types inferred from other types is what also makes it super powerful. Is it a silver bullet, no, but it's a great tool.

And even if you don't use TypeScript, you still get a lot of its benefits if you're using an editor like VS Code. It's what provides Intellisense and refactoring to your JS projects (as well as TS projects)

#vscode

Official tag for Visual Studio Code, Microsoft's open-source editor
Collapse
 
cerchie profile image
Lucia Cerchie • Edited

Pros: type safety will help you catch errors and save you development time, esp since you can see them at deployment before run-time

Cons: if you're a fan of strict type safety, the partial types might annoy you. also, you probably don't need this for small applications. no big performance benefits over JS since it's a superset of JS so if you're looking mainly for that you can try web dev with Golang or Rust or something similar.

Collapse
 
jaeming profile image
jaeming • Edited

I was an extreme skeptic on the use of Typescript over just regular Javascript. When my team decided to try an experimental project with it on AWS Lambdas, I saw some benefit in it when I imported the aws event interfaces. I thought, oh this could be really useful for asserting an API interface and getting all the intellisense for that in vscode so I don't have to look at docs as much.

Because of that thought, a year later my team moved an existing legacy project to GraphQL. On the FE we ran a script that used a codegen tool: graphql-code-generator.com/
This hits the introspection endpoint on graphql and genrates all the types for queries and mutation and fields. It will also generate an sdk for your FE GQL queries, which are typed of course.

This was the point of no return for me and I commited to TS 100%, at least in the work environment. It saved so much time and made it so much more enjoyable to work with the data layer in the FE.

Occasionally I still spin up some small projects at home using just a node script but when it grows to a certain level of complexity, I start missing TS and feel the urge to define some interfaces, so I'll end up switching over back to TS pretty quickly. In a team environment I wouldn't consider going any other way as it just saves so much time and grief and no one has to interpret the intention or parameters of functions, etc. We do have at least one team member that hates Typescript. Sometimes he complains about how a particular typing error is just wrong or unnecessary but when one of us looks at it, it almost always turns out that TS was trying to help him cover a case he hadn't thought of or that he had a wrong concept of what the data was. On the other hand, that developer is very good at running down production bugs so I guess there are different strengths and preferences out there and it depends on what type of programmer personality you have.

For myself, if it's a question of, do you want to move fast and fix bugs in prod vs, take a bit longer solidifying your data abstraction and have less bugs later, I'll go with that latter choice.

Collapse
 
lexlohr profile image
Alex Lohr

Don't bother using typescript, unless you want to avoid classical coercion mishaps due to JS' weak types, write code that should be maintained or used by other people including yourself after a few weeks or work professionally in front-end. You don't need the comfort of helpful IDE Integration, because obviously you're omniscient at least in terms of your project. It has a transpilation step that could take up to a few seconds and nobody got time for that, right? Even though it allows you to use more recent ES standards and finds bugs in your code. But you're not going to need that, because you know all browser versions from msie8 and their weird quirks by heart, don't you? Long story short, you don't want typescript, unless you do, don't you?

Collapse
 
abhinav1217 profile image
Abhinav Kulshreshtha • Edited

Considering JSDocs is lagging behind in keeping updated to the newer js specs, Typescript is only real way to go if you want a stable, large scale application in Javascript ecosystem.

Ironically, I just use the typescript only for its datatypes, keeping the actual code as close to javascript as possible. Only other thing I use from typescript is private properties, but I am slowly migrating that skill into JS private properties syntax with#var in newer code that I write.

Collapse
 
thejaredwilcurt profile image
The Jared Wilcurt

Everything TS is trying to do is done better with eslint-plugin-jsdoc. It lets you document the types, and as you write your code your editor will do the exact same thing it would with TS types. However on hover, it doesn't just tell you the name and type of a variable, it also gives you the context of what it is, and why it exists (the stuff that actually matters).

Cons of TS:

  • SLOW: TS is notoriously slow. On any project of decent size expect to save one file, wait 20s seconds for the entire project to compile, then the page refreshes. It removes you from the flow of coding. Inexcusable experience.
    • JSDocs - No impact on speed, other than the time it takes to lint, which can be done in the background by your editor and highlighted in your code in real-time.
  • Learning curve: Everyone knows JS, only some people know TS.
    • JSDocs - No learning curve just do eslint --fix and it starts writing the comment block for you. You fill in the details, run eslint --fix again and it corrects your formatting and tells you what you missed. Level of enforcement is up to you.
  • per-character annoyance: If you type a single thing wrong, your compiler is mad.
    • JSDocs - per PR annoyance: if you want to wait until the end of your PR to do all the linting before it gets merged, that's fine, it's just linting.

Pros of both:

  • autocomplete (identical)
  • warning of potential errors and mismatches between expected types (identical)
  • code quality enforcement (eslint does a better job)
  • documentation (jsdocs does a better job)
  • being trendy bullshit (actually jsdocs doesn't do this one, hey TS is finally better at something!)

Problems of both:

Editors are using the TS engine to give you hints/warnings, and honestly, it's pretty dumb. Over-reliance on it causes more errors than just not using anything like this at all. I have seen people write up interfaces for 3rd party API's and be done. No safety checks. Like..... they genuinely don't know why that's really bad. There are also "runtime bombs" where your code will break in production and the compile time checks aren't smart enough to figure that out.

Neither of them are good for runtime checking. See: dev.to/thejaredwilcurt/comment/1212g

Collapse
 
kayis profile image
K

I like TypeScript, but...!

I'm an average dev that was never very fond of statically typed languages like Java or C.

When I learned it in school and university I resented it.

At work I learned langauges like PHP and JavaScript, and they felt much more lightweight. It felt like finally learning something that was created with a getting things done attitude.

Obviously, these dynamically typed languages came with their own downsides in the long run. So, I really appreciate TypeScript helping out here.

But I think, I mostly like TypeScript because I'm already veeery deep into JavaScript. Like, I have most of the types in my head when coding. This means, TypeScript feels like simply writing down what I have in my head and don't have to remember it all the time. Which is nice.

But I think, for people less versed in JavaScript it can feel a bit confusing, because the not-so-optimal type system of JavaScript (and in turn TypeScript).

I know the idiosyncracies so it doesn't confuse me... okay sometimes it does, and that is actually nice, because TypeScript shows me where my model was flawed. But yeah, when you get such errors while still beginning with programming it's daunting.

What I also like about TypeScript is the opt-in and structual typing. You can always throw an unknown around and clear it up later and if something is simply called different, but has the same structure, things still work out, which is a huge improvement over Java.

Collapse
 
hunghvu profile image
Hung Vu

Pros:

  1. Statically type => type safety
  2. Statically type => type safety
  3. Statically type => type safety

Cons:

  1. Library compatibility issue
  2. Transpiling issue
  3. Web development is really dynamic in nature due to API calls, so type error is occasionally raised but the code should work in reality

In my opinion, all is about the typing system, without that, most of the benefits (Intellisense, debugger, etc) won't exist. Also because of the types, weird/troublesome errors just pop up every now and then. That said, I always try to achieve as much type safety as possible since it's valueable in the long run.

Collapse
 
codewander profile image
codewander • Edited

ReScript - high quality js compiler without the OO garbage or unsound typing

Collapse
 
lyrod profile image
Lyrod

And without the npm ecosystem 🤣

Collapse
 
codewander profile image
codewander

sadly, you end up using js/typescript libraries for a portion of your work and rescript-react ends up depending on react, which is why I am more excited about elm, but if someone is considering typescript for frontend, then one should at least try rescript before settling on typescript.

Thread Thread
 
lyrod profile image
Lyrod

I tried rescript like 6 months ago. I quit when I saw how hard is to import the basic of "fs" or "path" from nodejs.

Thread Thread
 
codewander profile image
codewander

Makes sense. But for front end, it's not as big a deal. There are repos that show common node library bindings, but I would only use rescript for front end currently.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.