Things I Wish I Knew When Starting TypeScript

When I first started using TypeScript, I thought it was basically JavaScript with types.

Add a few string and number annotations, fix some red errors, and you are done.

Well... not exactly.

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.

So here they are.

1. You do not need to type everything

One of my first mistakes was trying to add types everywhere.

I would write things like:

const name: string = "John";
const age: number = 25;
const isLoggedIn: boolean = true;

There is nothing wrong with this, but TypeScript already knows these types.

You can simply write:

const name = "John";
const age = 25;
const isLoggedIn = true;

TypeScript can infer the types automatically.

This is one of the first things I learned: good TypeScript code is not code with the maximum number of type annotations.

It is code where the types provide useful information.

For example:

const user = {
  name: "John",
  age: 25,
};

TypeScript already understands that user.name is a string and user.age is a number.

No need to repeat information the compiler already knows.

2. any is usually an escape hatch, not a solution

When TypeScript complains, it is tempting to write:

const user: any = data;

And suddenly the error disappears.

Problem solved, right?

Not really.

any basically tells TypeScript:

Trust me. I know what I'm doing.

Sometimes you genuinely need it, especially when dealing with old JavaScript code or poorly typed third-party libraries.

But if you use any everywhere, you lose many of the benefits of TypeScript.

Instead of:

function getUser(data: any) {
  return data.name;
}

try to describe what you actually expect:

type User = {
  name: string;
  age: number;
};

function getUser(user: User) {
  return user.name;
}

Now TypeScript can help you.

And that is really the point.

3. Types are documentation

This was a big mindset change for me.

A good type can explain code without requiring a comment.

Compare this:

function updateUser(user: any, options: any) {
  // ...
}

with:

type User = {
  id: string;
  name: string;
  email: string;
};

type UpdateUserOptions = {
  name?: string;
  email?: string;
};

function updateUser(user: User, options: UpdateUserOptions) {
  // ...
}

I can understand much more about the function before reading its implementation.

Types become part of the API of your code.

This is especially useful when working on a team.

4. Learn type and interface, but do not overthink them

When I started TypeScript, I spent way too much time wondering:

Should I use type or interface?

The short answer is: learn both, understand their differences, and then follow the conventions of your project.

For many frontend use cases, either works perfectly well.

For example:

type User = {
  id: string;
  name: string;
};

And:

interface User {
  id: string;
  name: string;
}

Both describe an object with the same shape.

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.

Start writing code.

You will learn where the differences matter.

5. Unions are incredibly useful

One of my favorite TypeScript features is the union type.

For example:

type Status = "loading" | "success" | "error";

Now this is allowed:

const status: Status = "loading";

But this is not:

const status: Status = "finished";

This becomes particularly useful in frontend applications.

For example:

type RequestState =
  | { status: "loading" }
  | { status: "success"; data: User[] }
  | { status: "error"; message: string };

Now your application has an explicit model for its different states.

You cannot accidentally access data while the request is still loading.

This makes your code easier to reason about.

6. TypeScript will not save you from bad logic

This is another important lesson.

TypeScript checks your types.

It does not check whether your business logic makes sense.

This code can be perfectly valid TypeScript:

function calculateDiscount(price: number, discount: number) {
  return price + discount;
}

The types are correct.

The logic might still be completely wrong.

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.

7. Learn to read error messages

At first, TypeScript errors can look terrifying.

You might see a huge wall of red text and immediately start searching Google.

I definitely did.

But over time, I learned that the important part is usually much smaller than the entire error message.

For example:

Type 'string | undefined' is not assignable to type 'string'.

The important part is:

string | undefined

You have a value that might be undefined, but the function expects a guaranteed string.

Instead of fighting the compiler, ask:

Why can this value be undefined?

Maybe the correct solution is:

if (!name) {
  return;
}

sendName(name);

Or perhaps the function should accept undefined.

The compiler is often pointing at a real design question.

8. strict mode is your friend

If you are starting a new TypeScript project, you will probably encounter this:

{
  "compilerOptions": {
    "strict": true
  }
}

At first, strict mode can feel annoying.

You will get more errors.

But those errors are often useful.

For example, strict null checking forces you to think about values that might not exist.

Instead of assuming:

user.name.toUpperCase();

you might need to consider:

if (user.name) {
  user.name.toUpperCase();
}

This might feel like extra work.

In a real application, though, handling these cases can prevent actual runtime bugs.

9. Do not fight TypeScript just to make an error disappear

This is probably one of the biggest lessons I learned.

When TypeScript gives you an error, there are several ways to make it disappear.

Some are good.

Some are just hiding the problem.

For example:

const value = something as string;

Type assertions can be useful, but they do not magically change the value at runtime.

You are telling TypeScript:

I know more about this value than you do.

That might be true.

But if you are using as everywhere, it is worth asking whether your types are modeling the application correctly.

10. TypeScript makes refactoring much nicer

This is one of the reasons I ended up really liking TypeScript.

Imagine you have a property:

type User = {
  username: string;
};

Then your application grows and you decide that username should become displayName.

In a large JavaScript project, finding every place that uses username can be painful.

With TypeScript and a good editor, you can rename the property and let the compiler show you where things need to change.

That is incredibly useful.

For me, TypeScript became more valuable as projects became larger.

11. You do not need to understand everything before using it

This is probably the most important thing I wish I knew.

You do not need to understand:

• advanced generics
• conditional types
• mapped types
• template literal types
• complicated utility types
• every compiler option

before building a TypeScript application.

Start with the basics:

string
number
boolean
array
object
type
interface
union
optional properties
function types
generics

Then learn advanced features when you actually encounter a problem that requires them.

You will remember them much better that way.

12. TypeScript is a tool, not the goal

It is easy to fall into the TypeScript rabbit hole.

You start with:

How do I type this React component?

Two hours later, you are reading about conditional types and wondering what happened to your afternoon.

I have been there.

Remember why you are using TypeScript in the first place.

The goal is not to create the most impressive type definitions.

The goal is to build software that is easier to understand, maintain, refactor, and change.

Sometimes a simple type is the best type.

A simple TypeScript learning path

If I were starting TypeScript again today, I would learn it roughly like this:

1. Basic types
2. Type inference
3. Objects and arrays
4. Functions
5. type and interface
6. Union and intersection types
7. Optional properties
8. Generics
9. Utility types
10. Narrowing and type guards
11. Advanced types when needed

And most importantly, I would build something while learning.

A small React application with a few API calls will teach you more than reading TypeScript documentation for days without writing code.

A few TypeScript habits I wish I had earlier

Here are the rules I try to follow now:

• Let TypeScript infer obvious types.
• Avoid any unless there is a good reason.
• Use types to describe real application concepts.
• Keep types close to the code that uses them when that makes sense.
• Do not use complicated types just to show off.
• Read compiler errors instead of immediately disabling them.
• Use strict mode for serious projects.
• Model different application states explicitly.
• Use your editor's TypeScript features. They are extremely useful.
• Learn advanced TypeScript when you actually need them.

If you are learning TypeScript for your next frontend job

There is another reason TypeScript is worth learning: it is a common part of modern frontend development.

But when you are applying for jobs, simply writing "I know TypeScript" on your resume is not very interesting.

It is better to talk about how you used it.

For example:

Built a React application with TypeScript, using typed API responses, reusable component props, union types, and strict type checking to reduce runtime errors.

That tells a much better story.

Cover letter prompt for a frontend developer

If you are using AI to help write a cover letter, you can start with this prompt:

Write a friendly and natural cover letter for a frontend developer applying for a TypeScript/React position.

My experience includes:
- [X years of frontend development]
- React
- TypeScript
- JavaScript
- [Other technologies]
- [Relevant project or achievement]

Make the letter sound like a real developer wrote it. Keep it concise, confident, and conversational. Avoid generic phrases, exaggerated claims, and corporate buzzwords. Focus on how I build maintainable user interfaces, work with other developers, and solve practical problems.

Do not invent experience or skills that I have not mentioned.

A prompt for improving your existing cover letter

Rewrite my cover letter for a frontend developer position.

Keep my original experience and facts exactly the same. Make the English sound natural and confident, like a real frontend developer wrote it.

Remove generic corporate language and unnecessary buzzwords. Make the letter concise and specific. Highlight my experience with React, TypeScript, frontend architecture, debugging, and building user-facing features where relevant.

Do not invent experience, projects, or skills.

Here is my cover letter:

[PASTE YOUR COVER LETTER]

Final thoughts

I used to think becoming good at TypeScript meant knowing more TypeScript features.

Now I think it is more about knowing when to use them.

The best TypeScript code I have worked with is usually not the most complicated code. It is code where the types make the application easier to understand.

If you are just starting, do not worry about mastering everything.

Write some code.

Break things.

Read the errors.

Fix them.

Repeat.

Eventually, TypeScript stops feeling like something that is getting in your way and starts feeling like another tool sitting next to your editor, browser, and Git.

And that is probably the point where you start enjoying it.