When I first started using TypeScript, I thought it was basically JavaScript with types.
The more I used TypeScript in real frontend projects, the more I realized that the difficult part was not learning the syntax. The difficult part was learning how to think about types.
After working with TypeScript for a while, there are quite a few things I wish someone had told me when I was starting.
This is one of the first things I learned: good TypeScript code is not code with the maximum number of type annotations.
TypeScript already understands that user.name is a string and user.age is a number.
No need to repeat information the compiler already knows. any is usually an escape hatch, not a solution
Sometimes you genuinely need it, especially when dealing with old JavaScript code or poorly typed third-party libraries.
I can understand much more about the function before reading its implementation.
This is especially useful when working on a team. Learn type and interface, but do not overthink them
The short answer is: learn both, understand their differences, and then follow the conventions of your project.
There are differences between type and interface, especially around declaration merging and extending types, but you do not need to memorize every detail before building your first application.
This makes your code easier to reason about. TypeScript will not save you from bad logic
TypeScript is a tool that helps you catch certain categories of mistakes. It is not a replacement for testing, code review, debugging, or thinking.
You still need to understand what your application is supposed to do. Learn to read error messages
But over time, I learned that the important part is usually much smaller than the entire error message.
You have a value that might be undefined, but the function expects a guaranteed string.
The compiler is often pointing at a real design question. strict mode is your friend
For example, strict null checking forces you to think about values that might not exist.