Why TypeScript is the best way to write Front-end in 2019
And why you should convince everybody to use it.
TypeScript gets more and more popular in the Front-end environment. Nowadays, 80% of us would like to use or learn TypeScript in their next project. I have loved it since I used it for the first time. I would love to use it in my next projects as well.
Some of us might raise concerns that TypeScript is an unnecessary dependency in our front-end toolchain. Is it? I’ll try to answer it in this article.
My story of a dynamically typed languages guy
Throughout the most of my programming career, I had never liked statically typed languages. Since I started out programming in 2001, my languages were always dynamically typed: PHP, JS, Ruby, Elixir. I had done some programs in C++ and Java as well, but I hated it back then. (“Why do I need to pass the types everywhere? That sucks. I prefer to care about them myself.”)
Everything changed about 2 years ago when I used TypeScript in one of the projects. I hadn’t loved it so much initially. In the first few days it kinda annoyed me. It changed quickly though. The more I used TypeScript and the more it saved me from wasting time on debugging stupid bugs, the more I appreciated it.
When in the last 2 years I have been doing front-end apps in both TS and JS, both Angular and React, I noticed there is this one thing I was really missing in all of my JS projects: TypeScript.
Now I have to admit. I don’t like dynamically typed languages anymore. I can still work very well in them, but it saddens me when I can’t just look up type definitions or trust the compiler while prototyping the code. (The only thing I still miss in Elixir are strong types.)
Fortunately, in JS we don’t need to wait until ECMAScript introduces static type system. We can use TypeScript instead. Especially in the new projects, when the hassle of using it is minimal.
Nevertheless, some might still argue that bringing TypeScript to your project will:
- increase the duration of on-boarding new developers,
- complicate maintenance,
- introduce a lot of conflicts with React,
- increase development time,
- lock-in the project to some hipstery tech that won’t exist in a year from now,
- prevent recruiting good JS people,
- make it impossible to convert components from non-TS apps,
- make it difficult to edit the app in the distant future.
My opinion is the opposite. I dare to say that TypeScript will help in all of the above cases, not make it worse.
That’s why I decided to write this article. Maybe it will help convincing them, and some of your friends or workmates as well.
Note: I won’t be explaining what TypeScript is in this article. I’ll focus only on why should you use it. If you’re still unfamiliar with what TS really is, I suggest you reading some of the following links first:
Code easier to understand
Usually when you work on a piece of a code, i.e. a function code, to understand it fully you need to learn:
- What arguments does it take?
- What value does it return?
- What external data does it require?
- What does it do with those arguments and external data in order to produce the return value? (To answer this question, you need answers for questions no. 1–3 first.)
In dynamically typed languages, very often it is difficult to answer the first three questions. If a function receives
article argument, what exactly is it? Is it an object with some article attributes? What exact attributes are there? Is there an
article.name ? Can I always assume that
article.title exists? How about
article.isPublished? I might know that this attribute is merged into
article object in most of the places of the app, but is it present in this place as well?
To answer all of these questions usually you need to do one of the following:
a) put a
console.log(article), run the script in your browser, (maybe click through the UI a bit), and read the log;
b) see where the function is used and from there track down what data is put into all of its occurrences;
c) ask your colleague that recently had been working on this code (while hoping that he/she stills remembers what kind of
article is being used there);
d) assume that
article is like what you think it is, and just hope it works. (Additionally you can write an unit test for it to increase the chance that it will work.)
Does that sound familiar to you?
To me that sounds like a typical web development workflow in any other dynamically typed language like JS, PHP, Ruby, Python, Elixir and so on.
In statically typed language like TypeScript, you can get the answer to all of the above questions immediately from your IDE. No longer you need to look through entire code base nor keep asking your workmates.
Code easier and faster to implement
Typically, when you have to create a new feature or a new component, your workflow probably looks something like this:
- Bootstrap the component function, make up its constructor arguments, and write the remaining code.
- If it requires any external or sophisticated data (like an
articles), guess how will it look like, keep it in your memory and use it like that in your code.
- Put the component into your app and pass props into it.
- Test it, either manually or with unit tests. You need to make sure that it receives the props it should have and that it works how it should work.
- If something isn’t right, go back to your code, try to figure out what’s wrong, fix it, and go back to step no. 4.
In TypeScript, it is similar, but a bit easier:
- Bootstrap the component function, define its’ type definition, and implement it.
- If it requires any external or sophisticated data, look up their interfaces and reuse them (fully or partially).
- Put the component into your app and pass props into it.
- If you matched the typedefs correctly between the caller and the callee, everything should work flawlessly. The only thing you have to test now is the actual business logic of your component.
Thus, the whole process gets simplified and quicker in TypeScript.
Code easier to refactor
There’s often quite a lot of things you’d like to refactor, but because they touch so many things and files, you’re just too afraid of changing them.
In TypeScript, such things can often be refactored with just one click of “Rename Symbol” command in your IDE.
In dynamically typed languages, the best thing you can get to help you with refactor is probably Search & Replace with RegExp.
In statically typed language, Search & Replace isn’t needed anymore. With IDE commands like “Find All Occurrences” and “Rename Symbol”, you can see all occurrences in the app of the given function, class, or selected nested property of an interface.
Whenever you want to improve your build system a bit, rename your components, change your
user object, or remove a deprecated attribute, you don’t need to be afraid of doing that anymore. TypeScript will help you find all the usages of the refactored bit and will throw an error whenever your changes have caused type mismatches in other parts of the code.
Throughout many years of front-end web development, I have noticed that I could save up around ~50% of my time in bug fixing just by having somebody next to me that would immediately tell me that I did a typo, used a value that might be null, or passed an object into a place where it should be an array instead.
That somebody is called TypeScript.
Thanks to it, it is more difficult to bring invalid code into the codebase. If it compiles, you might be quite sure that it actually works.
Less boilerplate tests
When you are sure your variables are passed correctly into all given places, you don’t need to test it that much anymore.
Instead of writing simple boilerplate unit/integration tests, you can focus more on testing your app real functionalities, instead of testing whether your function arguments are being passed between each other correctly.
Less tests means shorter time to develop new features, and a smaller codebase, which in turn is less complicated, less error-prone and easier to maintain.
Code easier to merge
New junior developer in your team has just issued a PR introducing new code. At a first glance it looks all right: the code looks good, the unit tests are there, everything passes green.
Can you be sure at this moment that it works though? What if it doesn’t have proper unit tests? (Yeh. Let’s meet the reality folks, a lot of us still don’t write sufficient number of them.) Will you just trust the PR creator? Or will you focus your precious 5 min to actually run the code on your own and test it?
If you have TypeScript in your toolchain, it gives you another assurance check: the typedef compilation check.
If the code looks good, the unit tests are there, and the whole thing compiles, now you can be pretty sure, that the whole thing works well.
Thus, TypeScript makes it easier to trust other developers. It might improve the pace with which you review and merge PRs.
(The same goes the other way: thanks to type definitions, for new developers it is easier to see what other people’s portions of code are really doing, without the need of deep diving into them or running them by themselves.)
Aids the developer in having the correct workflow
When writing code in statically typed language, you first need to think about the types of the data you’ll receive, and the type of data you want to produce. Usually only after that you sit down to its’ implementation.
Many people will bet their life that this is the correct coding workflow.
For example, whenever you develop an algorithm, you should first think about its’ theoretical formula, and then implement it.
Or, whenever you do TDD, you first need to think how your code will work in reality (what data will it receive and what data will it produce), write it as tests, and then implement the actual code.
Same thing applies to TypeScript. It encourages you to first think about your type definitions before writing your actual code.
“It will harm our recruitment”
Regular JS surveys clearly show that more and more people are both programming in TS or willing to try it.
This shows that as of 2018, 80% of front-end developers would like to work in TypeScript.
Having TypeScript in your stack probably won’t harm your recruitment. It might actually do the opposite. If a developer sees that you use the best tools currently available in the market (like Redux, React/Vue/Angular, TypeScript, Next.js), he might be more willing to work in your company. Modern tools bring modern developers.
“On-boarding will take more time”
On the contrary though, if you have an already built project in TypeScript, it will be super easy for him/her to fit in. TS Syntax is intuitive and very easy to understand (which probably is the reason why it has gotten so popular). Generic function interfaces, type guards, conditional types? You’ll never have to touch nor understand those in 99% of your daily work. The remaining 1% is usually something that has to be done only in the beginning, which can be prepared by an already fluent TS programmer.
Moreover, thanks to TS advantages (which I mentioned earlier on), it will be easier for a new developer to start doing things in your existing codebase. If he has only to change a small thing or implement something new, he doesn’t need to browse through entire codebase anymore to understand what data is passed and where. He can read it instantly in his IDE and play around with the data. The TS compiler will give him instant feedback about the variables he uses and will guide him whenever he makes any kind of a mistake.
“React/Redux and TS doesn’t suit each other”
False. TS has had TSX support since long. Also, thanks to simple generic types like
React.Component<Props, State>, you can get rid of PropTypes (emulated basic runtime types used only for component props, but nothing else) and use real type system instead.
It is true that about a year or two ago it was required to write quite a bit of boilerplate code to make TypeScript work with Redux action creators. But since TS 2.8 has been released in February 2018, this is no longer a case. You can have both typed and simple React/Redux code in TypeScript. FYI, React Context API also works very well with TypeScript.
“It will be impossible to reuse JS code in a TS app”
Again, false. Any JS code is a valid TS code.
It is true, that if you use TS in strict mode (
noImplicitAny), you’ll have to add some types here and there to make it work. But that’s it! There is even an IDE plugin that can automatically convert your React-PropTypes component directly to TS.
And when you need to copy some weird old vendor js lib to your TS project: just do it. If there are no TS typings for it (which happens less and less often now), add them yourself or just use
any when referencing the vendor. It’s not like you’ll lose type safety in your whole app. You’ll lose it only in a couple of lines which touch the vendor. You can always add the typedefs later on, if you think they’d be helpful.
“By choosing TypeScript, we might end up being locked with some legacy tool, that nobody will support in the future”
TypeScript is at the moment used by Microsoft, Asana, Lyft, Slack, all Angular 2+ developers, multiple React & Vue.js developers, and thousands of other companies. Many others are joining every another day. TypeScript is the most popular superset of JS at the moment and isn’t going down anytime soon.
What is the chance that such language will be abandoned?
Probably it will never die. The only scenario in which TS could die is if JS would bring in types to their language on their own. But this won’t happen anytime soon for sure. At least not in the next ~5–10 years. And even if it would happen, I’m pretty sure that there would be tools that would let us easily migrate from TS to typed JS.
~5–10 years from now might be a time in which nobody knows React, Vue nor Angular anymore. But you don’t see a problem with sticking to those frameworks nowadays I guess? ;)
“What about Flow?”
TypeScript gives you the same thing that Flow does, and more. It is also way more popular.
Just this should be already enough for you not to consider Flow at all. If it’s the same thing, but with less functionality and much smaller community support, why would you consider it?
In hindsight, Flow used to be as popular as TS about ~3 years ago, when both of them were fresh players on the market. One of them was being pushed by Microsoft and Angular community, while the other was preferred by Facebook and some of the React community.
TypeScript eventually won. Nowadays more and more developers from all the front-end frameworks are switching to TypeScript.
There’s also a few other typed-JS alternatives out there (like PureScript or Elm), but let’s not consider them here. I want to talk about something that has wide community support and multiple companies already using it in production, not just a few hobbyists. (Sorry, folks.)
Requires a compilation step
Some of my back-end Node.js friends told me that introducing TS for them is just not worth it, because it would bring a lot of hassle with the need of precompiling all of the
.ts files before running them on Node.
While it is something that for sure you can handle with good build and development setup, I can’t disagree that it adds a bit of overhead to your Node.js application.
I can’t agree on this in Front-end environment though. Everybody compiles their JS in the front-end nowadays. You need legacy browser support? ES7 features? CSS-in-JS? For all of these you probably already use babel. And TypeScript can be compiled with Babel as well, just like any other syntax of JS (including ES7 or JSX).
Bringing TypeScript to your front-end project brings almost no overhead to the build setup. It will bring it only if you don’t use any code compiler at all like babel at all.
A bit difficult to set up
I can agree on that. What is the difference between a Next.js app and a Next.js app in TypeScript? In the second one, you need to make your Node.js server, webpack, and jest test runner to work with TypeScript. Also, whenever you add some library like React, Redux, Styled-Components, you also need to add typedefs for it, like
npm i @types/styled-components (unless the lib has TS typedefs file included in it).
The question you need to answer yourself though, how often do you do such a thing? Is it that much effort, to be worthy to resign from the all of TypeScript advantages?
Am I saying that all of us should suddenly switch to TypeScript? Not yet. For example, switching to it in an existing project is definitely a lot of work and it should be strongly thought over before doing so.
However, if you’re creating a new front-end application, which you will have to maintain over time, the case is different. I’d strongly suggest TypeScript then. Honestly, it’s difficult for me to find any reasons for not using TypeScript in your next front-end project.
I just want to say, that by using TypeScript you get loads of powerful advantages, for the cost of little extra effort in the beginning.
Let’s do TypeScript folks 😉 💙
“Switching to TS” Case Studios
- “TypeScript at Lyft” — Mohsen Azimi, Medium
- “TypeScript at Slack” — Felix Rieseberg, Medium
- “How we migrated a 200K+ LOC project to TypeScript and survived to tell the story” — Kleo Petrov, Hashnode
- “Converting 600K lines to TypeScript in 72 hours” — Paul Draper & Ryan Stringham, LucidChard TechBlog
Others reviews of TS
- “7 bad excuses of not using TypeScript” — Dmitry Pashkevich, Medium
- “Why use TypeScript, good and bad reasons” — Charly Poly, Medium
- “Typescript — Why should one use it?” — Majid, Medium
- “Why TypeScript Is Growing More Popular” — Mary Branscombe, The New Stack