The original link

TypeScript is becoming increasingly popular in front-end environments. Already, 80% of developers admit they want to use or learn TypeScript for their next project. I’ve loved it ever since I first used it. I will definitely continue to use it for all future projects.

Some worry that TypeScript is an unnecessary dependency on the front-end toolchain. Isn’t it? Follow me to learn that the reality is quite the opposite.

The story of a “dynamically typed language expert”

In my 18 years of programming, I’ve never liked statically typed languages. Since I started programming in 2001, I have chosen dynamic selection languages: PHP, JS, Ruby, Elixir. I’ve written programs here and there in C ++ and Java, but I’ve always hated those environments. (” Why do I need to pass types everywhere? That’s too bad. I can take care of them myself.” (That all changed two years ago. That was when I first started working with TypeScript. But I never fell in love with it in the first place. For the first few days, it actually bothered me. That soon changed. The more TYPE definitions I enter into my code, the more often I notice that it saves me from wasting time manually debugging stupid bugs in the console. I came to appreciate these genres. Whenever I collaborated on front-end applications over the next two years, whether Angular or React, I noticed that no matter what framework I used, one thing was missing from all.js projects: TypeScript. Now I have to admit. I don’t like dynamically typed languages anymore. I can still work efficiently in it, but it doesn’t satisfy me when I can’t just look up type definitions in the IDE or trust the compiler when prototyping code. (The only thing I still miss in Elixir is strong typing.) Fortunately, we don’t have to wait for the Ecma TC39 submitter to introduce the static typing system into JavaScript. We can use TypeScript instead. Especially in new projects, there is very little trouble to use it.

The TypeScript parameters

Still, some dare to argue that introducing TypeScript into your projects will:

  • Increase the onboarding time for new developers,
  • Maintenance complexity
  • React conflicts a lot,
  • Increase development time,
  • Lock the project into some trendy technology that won’t be around a year from now,
  • To prevent the recruitment of good JS people,
  • Makes it impossible to import code from a non-TS code base,
  • Making it difficult to edit the application in the distant future.

I dare say they are all wrong. TypeScript addresses all of these situations for you, and I can provide you with concrete arguments for why this is the case. That’s why I decided to write this article. Perhaps this will help convince you, your friend, colleague or CTO to use this excellent language. Note: I won’t explain “what TypeScript is” in this article. I’ll just focus on the “why” you should use it. If you still don’t know what TypeScript really means, I suggest you read the following links first:

  • “What is TypeScript and why should I use it instead of JavaScript?” — Lodewijk’s Bogaards, StackOverflow
  • The official TypeScript language website
  • “TypeScript — JavaScript with Superpowers” — Indrek Lasn, medium
  • “TypeScript in Depth” – ebook by Basarat Ali Syed

The advantage of the TypeScript

1. Code is easier to understand

In general, when you work with a piece of code, such as functional code, to fully understand it, you need to know the following:

  1. What arguments does it accept?
  2. What value does it return?
  3. What external data is required?
  4. What do these parameters and external data do in order to produce the return value?

In dynamically typed languages, the first three questions are often difficult to answer. If a function receives an article argument, what is it? Is it an object with some commodity properties? What are the exact attributes? Is there an article. Title or article. Name? Can I always assume that article. Title exists? I may know that the article property is incorporated into the object in most places in the application, but can I be sure that it always exists there as well?

To answer all of these questions, you usually need to do one of the following:

  1. Console. log(article) Put one in your browser, run the script, (maybe click UI), and read the log;
  2. See where the function is used, and from there keep track of what data is put into all the places where it occurs;
  3. Ask your colleagues if they’ve been using this code recently (hopefully they’re still alive, online, and memorized);
  4. Assume that its article is what you think it is, and just hope it works.

Does this sound familiar to you?

To me, this sounds like a typical Web development workflow in any dynamically typed language (e.g. JS, PHP, Ruby, Python, Elixir). In statically typed languages such as TypeScript, you can get answers to all of these questions immediately from the IDE and the compiler. You no longer have to look through the entire codebase, plague your colleagues with problems, and risk errors in production.

2. Code is easier to implement

Typically, when you have to create new features or components, your workflow might look something like this:

  1. Bootstrap the component function, compose its constructor parameters, and write the rest of the code.
  2. If it needs any external or complex data (such as user or articles), guess what it looks like, keep it in your own memory, and use it as you would in your code.
  3. Put components into your application and pass items to it.
  4. Test it manually or unit. (You need to make sure it receives the items it should have and how it should work.)
  5. If something is wrong, go back to your code, try to figure out what the problem is, fix it, and then go back to step No. 4.

In TypeScript, it’s similar, but much easier and faster:

  1. Bootstrap component functionality, define its type definition, and implement it.
  2. If you need any external or complex data, look up their interfaces and reuse them (in whole or in part).
  3. Put components into your application and pass items to it.
  4. And nothing more. (If you match the typedef correctly between the caller and the called, everything should work fine. The only thing you need to test now is the actual business logic of the component.

As a result, whenever you write code in TypeScript, it is not only more readable and error-resistant, but, mostly, easier to reason about.

3. Code is easier to refactor

You often need to refactor a lot of things, but because they involve so many things and files, you are too afraid to change them.

In statically typed languages, search and replace is no longer necessary. Using IDE commands such as Find All Events and Rename symbols, you can view all events for a given function, class, or object interface property in your application.

Every time you want to improve the build system slightly, rename components, change user objects, or remove properties that are not recommended, you don’t have to worry about the problem happening again. TypeScript will help you find all uses of the refactored bit, rename it, and warn you of compilation errors if your refactored code has any type mismatches.

4. Fewer mistakes

In years of front-end Web development, I’ve noticed that I can save about 50 percent of my bug fix time by just having a person sit next to me and yell at me whenever I make a typo. A value that may be null, or an object passed to a location that should be an array.

I’m happy to say I’ve finally met that partner: it’s called TypeScript.

Thanks to it, it is now much harder to write invalid code. If the compilation succeeds, you may be sure that it actually works.

5. Fewer boilerplate tests

When you are sure that variables are passed correctly to all given locations, you do not need to test all variables anymore. Instead of writing simple boilerplate unit/integration tests, you can focus more on testing the business logic of your application rather than testing whether function parameters pass correctly from one another. Less testing means less time to develop new features, and a smaller code base, which reduces code complexity, error rates, and ease of maintenance.

6. Code is easier to merge

The new junior developer on your team has just released PR and introduced new code. At first glance, everything looks good: the code looks good, the unit tests are there, and everything passes green.

Are you sure it works now? What if there are no proper unit tests? (yes. Let’s meet real people, many of us still don’t write enough.) Do you trust pr creators? Or do you spend five precious minutes running the code yourself and testing it?

If you include TypeScript in your tool chain, it gives you another assurance check: the typedef compilation check.

If the code looks good, you can unit test it, and the entire program compiles, and now you can be sure that the entire program works.

Using TypeScript makes it easier to trust other developers. It may improve the speed at which you view and merge PR.

(The reverse is also true: because of type definitions, it’s easier for new developers to see what other people’s parts of code are really doing without having to dig deep or run the code themselves.)

7. Help developers have the right workflow

When writing code in statically typed languages, you need to think first about the data types you will receive, and then about the data types you will generate. It is usually only after that that you sit down for the actual implementation.

Many people gamble their lives, and this is the correct coding workflow.

Whenever an algorithm is developed, for example, its theoretical formula should be considered first and then implemented.

Or, whenever you do TDD, you first need to think about how the code will work in reality (what data it will receive and what data it will produce), write it as a test, and then implement the actual code.

The same applies to TypeScript. It encourages you to think about your code’s interface before sitting down to implement its internal implementation.

TypeScript shortcomings

1. Compilation steps are required

Some of my back-end Node.js friends have told me that it’s just not worth it to introduce them to TS because of the hassle of having to pre-compile all the files before running.ts on Node. While I’m sure you can handle this with good build and development Settings, I can’t help but agree that it adds some overhead to your Node.js application. I do this differently in a front-end environment. Nowadays, everyone is compiling JS. Do you need older browser support? ES7 features? CSS – in – JS? For all of this, you probably already use Babel. You can compile TypeScript using Babel, just like any other JS syntax, including ES7 or JSX.

Bringing TypeScript to your front-end projects adds almost no overhead to the build setup. (This can be an overhead only if you don’t compile JS at all, but this rarely happens on the front end.)

2. The setup is a little difficult

I can agree with that. For example, what’s the difference between a Next-.js application in TypeScript and a Next-.js application? In the second case, you need to enable node.js servers, Webpack, and Jest test runners to work with TypeScript. In addition, typedef needs to be added whenever libraries such as React, Redux, and Styled-Components are added, such as NPM i@types/Styled-Components (unless the TS Typedefs file is included in the lib).

The question you need to answer yourself is, how often do you do this? Is it worth giving up all of TypeScript’s advantages?

Abstract

I mean should we all suddenly switch to TypeScript? Not at all. For example, switching to it in an existing project is certainly a lot of work, and should be seriously considered before doing so.

However, if you are creating a new front-end application that must be maintained over time, the situation is clear. Use the TypeScript. To be honest, I’d love to hear about your reasons for using TS in your next front-end project.

Let me just say this: You get a lot of great advantages using TypeScript with very little effort at first. Let’s be TypeScript people