Pitch me on TypeScript

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.

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!

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.

Consider Using TypeScript

Nick Taylor (he/him) ・ Oct 8 '17 ・ 5 min read

#typescript

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)

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.

Pros:

• Cleaner code
• Static type checking
• Less compile errors and debugging

Cons:

• Longer project setup
• You have to write more code
• It still compiles to vanilla JavaScript

Having a static typed language gives you the possibility to work on a project without having to run it, this is the thing I most prefer about ts compared to js.
It also lets you describe all your code so you don't need to jump around the codebase to understand what is what.

TS adds a sweet mental map for you when writing code. Especially for bigger applications. I get Marco's point on self documenting code and I feen like there's even more to it. Let's make a comparison:

• In Javascript, you might wonder: Why did I write this part of code? Why the naming? Have I seen this type of data structure before?
• In Typescript, well you probably wonder the same. But there's an additional layer of information that describes logic and data.

So next to the function itself, TS provides this abstract construction of static types and enriches code with context. I found this extremely annoying and limiting when I started. Right now, I use TS whenever I kick off a new project. Even the small ones which I know I'll touch more than one during the coming weekends.

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.

I would like to add that TypeScript is much better at communicating fundamental object oriented principles over JavaScript.

If you're only used to writing JS, you might not have a clear picture of how interfaces, abstract classes, access modifiers, and return types can not only simplify a design but also greatly communicate intent.

This is especially true if you are trying to learn design patterns, or understand how JS is quite different from other programming languages.

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?

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.

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

This one's easy: You can build your frontend, backend and mobile apps using a single language with similar build/test tools.

It's like a global currency that you can spend anywhere.

Work in a React with pure js for about 6 months. Then do it again with a typescript based React code base.

Hello, I am here to bash TS, specifically a particular painpoint I have found that was not mentioned yet. I submit this to provide contrary evidence to its merits, not necessarily as a verdict; TS may or may not make sense for any particular project.

As is often the case with technologies with feature bloat, users will inevitably misuse features available to them. For TS, that would be the rather ambiguous nature of interfaces vs enums vs types vs classes.

I strongly recommend all engineers to avoid object oriented paradigms whenever possible and instead favor functional programming and composition. TS tries to open that door, but at the same time attempts to support OOP paradigms based on traditional languages. As such, we wind up with these not so clearly defined concepts, complimented with the usual conventions that follow them around (ISmurf, IServlet, IResponse...)

I just find that languages that offer this many features give rises to codebases swamped in an unhealthy blend of OOP code, OOP code with anti patterns, mixed with functional and compositional approaches along side it.