My New Learning Philosophy🚀 Web Development Challenge — Day 24

I’m Not Leaving JavaScript Behind — I’m Building on Top of It

Day 24.

I honestly didn’t think I would write this article.

Not because I didn’t want to continue.

But because there was a time when I completely stopped.

For a long time, my web development journey was sitting there unfinished.

Then I decided to start again.

Not from zero.

From where I stopped.

I went back through JavaScript, ES6, problem-solving, functions, objects, arrays, callbacks, closures, and all those concepts that had become rusty during my break.

And now, after 23 days of continuing this journey…

I’ve reached something new.

TypeScript.

But before we start, I want to give you a little challenge.

🧩 Stop! Can You Spot the Problem?

Look at this TypeScript code:

let age: number = "25";

Something isn’t right.

But what?

🤔 Your choices:

A) Nothing is wrong.

B) age should be a string.

C) "25" is a string, but age is declared as a number.

D) TypeScript doesn’t allow variables called age.

Don’t Google it yet.

Keep your answer in your head — or write A, B, C or D somewhere.

I’ll come back to this later.

For now…

Welcome to Day 24.

🛤️ How Did I Get Here?

Before jumping into TypeScript, I needed to ask myself:

“Have I learned enough JavaScript?”

The honest answer is:

No.

And that’s okay.

JavaScript is huge.

There are still many things I need to learn more deeply:

• Promises
• async/await
• Fetch API
• DOM manipulation
• Events
• Modules
• Event loop
• this
• Prototypes
• and much more

So why am I moving to TypeScript?

Because I don’t want to spend another six months trying to “finish” JavaScript before building anything.

I’ve already built a foundation.

Now I want to build on top of that foundation.

So:

I’m not leaving JavaScript behind.

I’m adding TypeScript to my toolbox.

And I’ll continue strengthening JavaScript through practice and projects.

🟦 So… What Is TypeScript?

Before today, I’d heard the word TypeScript many times.

Developers use it.

Companies use it.

Modern web applications use it.

But hearing:

“I use TypeScript.”

doesn’t mean I actually understand it.

The simplest way I’m understanding it right now is:

TypeScript is JavaScript with a powerful type system.

For example, JavaScript:

let age = 25;

TypeScript:

let age: number = 25;

Now I’ve explicitly told TypeScript:

“This variable should contain a number.”

And that brings us back to our first challenge.

🔎 The Answer

Remember?

let age: number = "25";

The answer is:

✅ C

"25" is a string.

But we’ve told TypeScript:

age: number

So TypeScript can identify the mismatch.

That’s one of the first things I started appreciating about TypeScript.

It’s not simply changing JavaScript syntax.

It’s helping me describe what my data should look like.

⚙️ My First Encounter With tsconfig.json

One of the first things I learned was:

tsconfig.json

At first, I thought:

“Okay… another configuration file.” 😅

But it has an important role.

It tells the TypeScript compiler how my project should be handled.

It can control things like:

• compiler options
• JavaScript target
• source files
• output files
• strictness
• module settings

So TypeScript isn’t just about adding types to variables.

There’s a whole project configuration system behind it.

🏷️ Creating My Own Types

Then I learned about type aliases.

This was one of those concepts that immediately clicked.

I can define my own type:

type Student = {
    name: string;
    age: number;
    course: string;
};

Then use it:

const student: Student = {
    name: "Joy",
    age: 25,
    course: "Web Development"
};

Instead of repeatedly describing what a student object should contain, I can create a reusable definition.

Now I’m beginning to understand why TypeScript can become useful when applications get larger.

🧩 Type Alias vs Interface

Then I reached another question:

If I have type, why do I need interface?

For example:

interface Student {
    name: string;
    age: number;
}

And:

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

At first glance, they look almost identical.

And that’s what makes the topic interesting.

They’re both ways of describing structures, but they have differences in how they behave and how developers commonly use them.

I’m still learning the finer details, but I’m starting to understand that TypeScript gives developers multiple tools for designing their data structures.

🧠 Then Came Generics

And then…

Generics.

This was one of those moments where I had to stop and think.

Look at this:

function identity<T>(value: T): T {
    return value;
}

What is that mysterious T?

The basic idea is that T represents a type that can be determined when the function is used.

For example:

identity<string>("Hello");

identity<number>(100);

The same function can work with different types.

So I’m starting to understand generics as:

Reusable code without throwing away type safety.

That’s a pretty powerful idea.

🧠 A Little More Generics

The course also introduced:

• generic constraints
• default types

This is where things started becoming more advanced.

Instead of allowing a generic to accept absolutely anything, we can put restrictions on it.

I’m not going to pretend I’ve mastered advanced generics after one lesson.

I haven’t.

But I’m beginning to understand why they exist.

And that’s my goal right now:

Understand first. Master through practice.

🔢 Enums

Then I learned about Enums.

For example:

enum Status {
    Pending,
    Approved,
    Rejected
}

Instead of passing random values around, I can define a specific set of related values.

Again, I’m seeing a pattern:

TypeScript gives me more ways to make my code predictable.

🧊 And Then I Met as const

This tiny piece of syntax:

as const

was another new concept.

For example:

const roles = ["admin", "user", "guest"] as const;

It tells TypeScript to treat these values more specifically and as readonly literal values.

It’s a small feature.

But it showed me something important:

TypeScript doesn’t only care about what type something is.

It can also care about the exact values and structure.

🏗️ Then Things Got More Interesting: OOP

After the TypeScript fundamentals, I reached an optional advanced section:

Object-Oriented Programming in TypeScript

This wasn’t simply another collection of syntax.

It was a different way of thinking.

Instead of always asking:

“What function should I write?”

I started asking:

“What object am I modelling?”

“What should this object know?”

“What should this object be able to do?”

That’s where OOP starts becoming interesting.

🧱 Classes & Constructors

A class can act as a blueprint.

For example:

class Student {
    name: string;

    constructor(name: string) {
        this.name = name;
    }
}

Then I can create an object:

const student = new Student("Joy");

The class defines the structure.

The object is an actual instance.

It’s a different way of organizing code compared with the simple functions and objects I’ve been using before.

🔐 Encapsulation

Then came:

public

private

protected

These are access modifiers.

They help control what can be accessed from outside a class.

For example:

class BankAccount {
    private balance: number = 0;
}

The balance isn’t freely accessible from outside.

And I learned a bigger idea:

An object doesn’t have to expose everything it contains.

That’s encapsulation.

🎛️ Getters & Setters

Next came getters and setters.

Instead of simply allowing direct access to a property, we can control how a value is read or changed.

This becomes particularly useful when we want validation or rules around our data.

Again, the bigger theme is:

control.

🧬 Inheritance

Then I reached:

Inheritance.

Think about:

Animal
   ↓
  Dog

A Dog can inherit common characteristics and methods from Animal, while still having its own behavior.

This is one of those concepts I’ve heard about before, but seeing it implemented in TypeScript made it much clearer.

🎭 Polymorphism

Then came the word that sounds like it belongs in a university exam:

Polymorphism. 😅

But the basic idea isn’t as frightening.

Different objects can respond to the same method in different ways.

For example:

Animal → makeSound()

Dog → bark
Cat → meow

Same general method.

Different behavior.

That’s polymorphism.

🧩 Abstraction

Finally, I reached:

• abstract classes
• interfaces
• abstraction

The basic idea is to focus on what something should do without exposing every implementation detail.

And interestingly, this connected back to interfaces that I had already learned earlier.

The more I study, the more I notice that programming concepts aren’t isolated islands.

They connect.

🕵️ Challenge 2 — What Do You Think Happens?

Okay, here’s another challenge.

Look at this:

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

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

What do you think happens?

A)

Everything works perfectly.

B)

TypeScript gives a type error.

C)

JavaScript automatically converts "25" into 25.

D)

The computer immediately crashes.

Don’t scroll for the answer.

What do you think?

And more importantly:

Why?

Write your answer in the comments if you want to test yourself.

🔎 The Answer

The answer is:

B — TypeScript gives a type error.

Why?

Because we defined:

age: number

but gave it:

"25"

which is a string.

JavaScript can be flexible with types.

TypeScript is telling us:

“Wait. You said this should be a number.”

And that’s exactly the kind of mistake TypeScript is designed to help us catch.

🧪 Challenge 3 — Teach Me Something

This one isn’t about having a correct answer.

I’m still learning.

Today I encountered:

• Type aliases
• Interfaces
• Generics
• Enums
• as const
• Classes
• Encapsulation
• Inheritance
• Polymorphism
• Abstraction

So if you’ve worked with TypeScript before, I want to ask you something:

What’s ONE TypeScript concept that confused you when you first learned it?

Or:

What’s ONE thing you wish someone had explained to you when you started TypeScript?

Tell me in the comments.

Maybe your answer will help me.

And maybe it will help someone else reading this article too.

🤔 Did I Master TypeScript Today?

Definitely not.

And I’m okay with that.

Today was about opening the door.

I now have a basic understanding of:

✅ TypeScript configuration ✅ Type aliases ✅ Interfaces ✅ Generics ✅ Generic constraints ✅ Enums ✅ as const ✅ Classes ✅ Constructors ✅ Methods ✅ Access modifiers ✅ Encapsulation ✅ Getters and setters ✅ Inheritance ✅ Method overriding ✅ Polymorphism ✅ Abstraction

That’s a lot.

But knowing what something is and being able to build with it confidently are two completely different things.

The next step is practice.

🔄 JavaScript Isn’t Finished

One thing became very clear to me today:

TypeScript doesn’t mean I’m finished with JavaScript.

There is still plenty of JavaScript I need to learn more deeply.

Promises.

async/await.

APIs.

Fetch.

DOM.

Events.

Modules.

The event loop.

this.

Prototypes.

And more.

But I don’t want to fall into the trap of:

“I’ll learn everything before I build anything.”

I’ve done enough starting and stopping.

Now I want to learn, build, make mistakes, fix them, and continue.

🧭 My New Learning Philosophy

I’m starting to see my journey differently.

I don’t need to know everything before moving forward.

I need to know enough to take the next step.

Then the next project will show me what I don’t know.

Then I’ll learn that.

Then I’ll build again.

So my cycle becomes:

Learn → Build → Break → Fix → Understand → Build again.

That’s the approach I want to follow from now on.

💬 One Last Question for You

If you’ve made it this far, thank you.

I’m documenting this journey because I want to see how far I can actually go after that long break.

So I’m curious:

Are you learning web development too?

If yes, where are you right now?

HTML?

CSS?

JavaScript?

TypeScript?

React?

Backend?

Or are you thinking about starting?

Tell me in the comments.

I’d genuinely like to know who’s walking this road with me.

🚀 Day 24 — Complete

Twenty-four days.

After a long break.

After restarting.

After rebuilding my JavaScript foundation.

Today, TypeScript officially entered my journey.

I still have a long way to go.

But something feels different this time.

I’m not trying to become an expert overnight.

I’m trying to become a little better every day.

And maybe that’s enough.

I’m not leaving JavaScript behind.

I’m building on top of it.

Day 24 — complete. 🚀

See you on Day 25.