A place to learn web development beyond the basics. Updated weekly with <3 since 2019
Aug 12, 2020 • ☕️ 6 min read
The debate whether to use TypeScript is over, as library maintainers you should (or even must) support typings, as app developers you can get away in personal projects but often required in enterprises.
Honestly I don’t like TypeScript because its typing system is nothing compare to my previous experience with static strongly-typed languages like Java and Swift.
But I do learn and use TypeScript daily!
I’m not trying to convince you to switch but only here to help people already decided and still early in migration.
This post is a curated list of heads-up for you to migrate to TypeScript smoothly with minimum effort. The point to get the right expectation not to get intimidated by its drawbacks.
If I’m writing applications with a team of people, maintained over many years by different people and I would like some confidence that the code is at least logically sound in terms of the data types being passed around.
Typescript provides typing, latest ECMAScript features and great tooling support with intellisense. All these features together make project self documented and tested in some degree, so that other developers can go through it easily with confidence.
Play with your codebase and try out various approaches before committing to one of them. Sometimes finishing the migration quickly may take priority. Sometimes the code remaining fully functional during the migration may take priority.
While it might feel somewhat overwhelming, the long-term gains become apparent much more quickly.
It’s not unexpected to get error messages after conversion. The important thing is to actually go one by one through these and decide how to deal with the errors
TypeScript comes with certain checks to give you more safety and analysis of your program. Once you’ve converted your codebase to TypeScript, you can start enabling these checks for greater safety
Note that I’m not saying I’m against having 100% type coverage. It’s just that, like unit test coverage, getting that last 10-20% becomes much much harder, and it doesn’t seem like the benefits are necessarily worth the amount of time you have to put in to make it happen.
Don’t feel like you have to use TS for every single thing!
Don’t let “perfect typing” to become the enemy of “good functionality”.
TypeScript works best when all of your project dependencies have typings and that’s obviously not the case currently.
Many libraries don’t ship with typings but having type declarations in
DefinitelyTyped, these work just fine but sometimes type declaration package versions and library package versions get out of sync. Unpopular libraries often left in dust and way behind the original ones.
The worst case is not having typings anywhere, you can fix it by writing your own declarations for it. And I can tell you that you will not like it!
If you had previous experience with typed languages then you will concluded that TypeScript is just a flaw and created a false impression of type safety! Its safety is not completed and it’s not really safe at runtime.
Static typings work best when you consume a libraries shipped with type declarations in a TypeScript project.
But don’t forget that it only guarantees type safety at compile time. You need data validation to achieve safety at runtime.
Do you write tests for every possible combination of input data types to your functions? Or do you assume it’s only called with the “right” inputs? Don’t forget that consumers are not guaranteed to use TypeScript.
I don’t think that TypeScript replaces tests, but it should give you a baseline level of safety and lessen the need for a lot of things you would have written unit tests for otherwise.
Be really careful with
TypeScript does not come with built in polyfills, remember to set in config file.
This is really a big big problem with libraries not originally written in TypeScript, especially those SDKs from giants with hundreds of APIs. This is a nightmare!
Plan your migration carefully before making a move:
Overall, I think that TS should be used in any meaningfully-sized app that will be maintained long-term, or worked on by multiple people. But, at the same time, TypeScript is a tool, with strengths, weaknesses, and tradeoffs. Take time to understand those tradeoffs and whether they are a benefit for you, and use it wisely.
As your application grows, you may find it helpful to include a type system to assist in development. Just choose the right tool for the task at hand, and create something great with it.
Too bad! Same old story! Once you’ve finished building your house you notice you’ve accidentally learned something that you really should have known—before you started. (Friedrich Nietzsche, Beyond Good and Evil)
Bull is the fastest, most reliable, Redis-based queue for Node. I have been using it for years to handle async jobs and schedule messages
An overview of Binaryen as compiler infrastructure and toolchain library for WebAssembly in written C++
Pros and cons of using CSS frameworks like Bootstrap, Foundation, Materialize CSS, Semantic UI, Tailwind, Ant Design
An overview of what WebAssembly (Wasm) is, how it works, and it's current position in the web development stack