Why use TypeScript, good and bad reasons
This article is part of the collection “TypeScript Essentials”, this is Chapter One.
If you are asking yourself:
Should I use TypeScript? Do I need it?
Then, this article is for you.
⚠️ This article only reflects my opinion, lessons I learned and quoted the opinions of other developers.
The bad reasons
With TypeScript, no need for writing tests
As explained by Eric Elliot in the following great article, “static types do not reduce overall bug density”. Types are written by the developers and not checked at runtime, so the “strength” of your program depends on your usage of TypeScript. If you looking at TypeScript to reduce your bugs, please look at TDD instead.
However, a recent study shows that the use of type results in a 15% decrease of bugs. Quoting Adrian Colyer:
Is a 15% reduction in bugs making it all the way through your development pipeline worth it to you?
If you like data and are willing for more details about this “15%”, I highly encourage you to read the full article:
Develop with JavaScript using types won’t make programs less error-prone. Still wondering “why?”, this brings us to the next section 👇.
With TypeScript, I can trust my code at runtime
TypeScript is a static type-checking tool, it does not guarantee that your code will run as expected at runtime. Example with the following snippet:
Although your function is “typed”, TypeScript ignores the type validation if a developer chooses to type-cast the argument to any .
For more information about type-casting, please follow me for Chapter 2.
Remember that TypeScript will not make type assertions at runtime
TypeScript looks more like C#, I don’t need to understand JavaScript
As a JavaScript lover for a long time, I always privilege a functional approach compared to Object-Oriented one.
I consider that TypeScript should be here to facilitate teamwork, increase velocity, and improve project maintainability.
TypeScript shouldn't be used (in my opinion) to put some non-JavaScript developers on the front-end as fast as possible.
TypeScript is still JavaScript, so understanding JavaScript is important.
The good reasons
TypeScript will help your developers work together on a growing codebase
TypeScript allows developers to focus on exposed API rather than having to know all the code by heart.
I believe that the best point of TypeScript is to encourage developers to develop exposing interfaces (like contracts).
If you’re evolving in architecture with isolated components/service following SRP, then TypeScript allows you to expose your APIs with typed interfaces, keep others developers “in the loop”.
I will add that this “interface oriented development” make easier to work with big teams, especially if those teams are composed of developers of different levels (junior, senior). I insist that a good understanding of JavaScript is crucial, but TypeScript enables a softer on-boarding in big projects and allows developers to focus on exposed API rather than having to know all the code by heart.
And more, TypeScript will avoid inattention errors, like “typos”.
TypeScript tools will save your developers time
Honestly, I always dodged every tooling and IDE, believing it will make me dumb and lazy.
But for TypeScript (and other languages too), the core team made an awesome architectural work for tools.
These are divided into many parts:
- Language Servers Protocol Project Microsoft did not stop this initiative at TypeScript level. The Language Server is a Protocol to develop “tsserver” like services (aka Language Server) for all languages.
The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how tools and servers communicate, so a single Language Server can be re-used in multiple development tools, and tools can support languages with minimal effort.
- Others tools and initiatives By looking at TypeScript architecture, you’ll see that the compiler and utils are “open”. This allows the community to develop a lot of awesome tools like TSLint.
For example, VSCode uses all available features of TypeScript languages and tools to help developers to refactor and write code with ease. This allows me to focus on real problems and let TypeScript cover my back on the things I already know but that I forget sometimes (typos, standard APIs, etc …) This includes all the refactoring precautions, that I’m totally capable of taking but often too lazy to take! ⤵️
I’ll cover some features of VSCode in detail in Chapter 2.
The Microsoft community-effort success story
Historically, like a lot of Front-end developers, I wasn’t a big fan of Microsoft. But, let’s just be honest, Microsoft made an awesome work for the web in recent years.
In my experience, the first “community” to introduce typing to JavaScript was Google with Dart and AngularDart. Later, the Angular teams started a framework called AtScript (JavaScript superset with types and runtime type checking). Finally, the Angular team at Google choose to use TypeScript, and new JavaScript superset language publicly released by Microsoft. At the same time, Facebook released Flow (mainly for React).
3 years later after Angular 2 integration, with the VSCode development and full React integration, TypeScript has a huge active community with many companies using it in production.
Here is a (very) shortlist of the greatest community accomplishments:
- React “integrated” propsTypes “Native” mapping between TypeScript types and React PropTypes.
- DefinitelyTyped @types Almost all popular packages have their TypeScript typings More than 4200+ npm packages “typed” by the community!
- ApolloData GraphQL types generation If you are using a GraphQL API, this is truly a killer-feature! A set of tools developed by Apollo team will generate all TS types for your front application, this makes “types real”. For more details: apollo-codegen
TypeScript gives you a taste of future JavaScript, with typings.
Even if “TypeScript” contains “type”, the language does not force users to use types. Even if I will encourage you to use all the power of types (in chapter 2), TypeScript does a fairly good work on ES-next feature set transpiling. However, it’s not an equivalent of Babel which allows using features from really early TC39 stages.
Summary
Bad
- Test replacement, TypeScript ain’t a test framework
- Runtime safety, TypeScript ain’t a runtime type checker
- I can write object-oriented C# a-like code, TypeScript is typed JavaScript
Good
- Team and code scalability with “Interface oriented development” TypeScript will help you deal with growing teams and large codebase
- Tooling and Community Microsoft made an awesome community effort work.
- ES-next compliance TypeScript give you a taste of future JavaScript, with typing.
I hope this chapter helped you have a good grasp of what TypeScript is and determine if it’s a technology you may benefit from. 👌
