DEV Community: Code X Savage

React Components Aren't Magic—They're Built on a JavaScript Mindset

Code X Savage — Wed, 22 Jul 2026 21:58:04 +0000

Before You Learn React, Master This JavaScript Habit

When I first started learning React, everyone kept talking about components.

Components this.

Components that.

At first, I thought components were something unique to React.

But after spending more time with vanilla JavaScript, I realized something.

The mindset behind React components already exists in JavaScript.

React didn't invent reusability—it simply gave it a better structure.

If you're planning to learn React after JavaScript, there's one habit worth building now:

Write reusable code.

Why Reusability Matters

Imagine you're building a dashboard.

It has five buttons.

Every button shares the same styling and almost the same behavior.

One approach would be to copy and paste the same code five times.

It works...

Until you want to change something.

Now you're editing five different places.

Maybe you decide to change the button color.

Or the padding.

Or add an icon.

Now every copy needs to be updated.

This is where reusable code shines.

Write it once.

Use it everywhere.

Besides saving time, reusable code makes your projects:

Easier to maintain
Easier to debug
Easier to extend
Easier for other developers to understand

JavaScript Already Supports This

When people hear the word component, they immediately think of React.

But JavaScript has supported reusable logic for years through functions.

For example:

function createButton(text) {
  const button = document.createElement("button");

  button.textContent = text;
  button.className = "btn";

  return button;
}

Instead of writing this repeatedly:

const saveBtn = document.createElement("button");
saveBtn.textContent = "Save";

const deleteBtn = document.createElement("button");
deleteBtn.textContent = "Delete";

const cancelBtn = document.createElement("button");
cancelBtn.textContent = "Cancel";

You simply reuse your function:

document.body.append(
  createButton("Save"),
  createButton("Delete"),
  createButton("Cancel")
);

One function.

Multiple buttons.

Same logic.

This Is The Mindset React Builds On

Now look at React.

<Button text="Save" />
<Button text="Delete" />
<Button text="Cancel" />

Different syntax.

Same principle.

React components are simply reusable pieces of UI.

Instead of returning DOM elements directly, React components return JSX.

The idea, however, is exactly the same:

Create something once.

Reuse it whenever you need it.

React Isn't Magic

One thing that slowed me down when learning React was thinking it introduced an entirely new way of programming.

It doesn't.

React is still JavaScript.

It simply encourages you to organize your UI into reusable, self-contained pieces called components.

Once I stopped thinking of components as something magical, React became much easier to understand.

What You Should Practice Before React

If you're currently learning vanilla JavaScript, I think there are a few habits worth developing before moving to React.

Write reusable functions.
Break large problems into smaller ones.
Avoid copying and pasting code.
Keep related logic together.
Think about maintainability instead of just making things work.

These habits transfer directly into React development.

Final Thoughts

Many beginners rush into React because it's popular.

There's nothing wrong with that.

But if you spend time mastering reusable functions in vanilla JavaScript first, React starts to feel much more familiar.

You'll spend less time wondering "What is a component?"

And more time appreciating why components exist.

React didn't invent reusability.

It simply built an entire library around a mindset JavaScript already encourages.

What do you think?

If you've already learned React, did understanding JavaScript functions make components easier to understand?

I'd love to hear your thoughts.

Is Typescript worth it?

Code X Savage — Sat, 18 Jul 2026 01:16:17 +0000

Is TypeScript Really Worth Learning?

When I first started learning TypeScript, I honestly didn't understand the hype.

I thought:

"If I'm the one writing the code, then I already know what type every variable should be... so why do I need TypeScript?"

It just looked like JavaScript with more syntax.

After spending more time with it while building my SaaS, I started to understand why so many developers recommend it.

What Exactly Is TypeScript?

TypeScript isn't a completely new programming language.

It's a superset of JavaScript that adds static typing and better developer tooling while compiling down to plain JavaScript.

If you already know JavaScript, you're already most of the way there.

So What Is Type Safety?

Imagine you have a function that expects a string.

In JavaScript, you could accidentally pass a number.

function greet(name) {
  return "Hello " + name;
}

greet(42);

JavaScript won't complain immediately.

Now look at the same example in TypeScript.

function greet(name: string) {
  return `Hello ${name}`;
}

greet(42);

Your editor immediately highlights the error before you even run the application.

That means you can catch bugs much earlier instead of discovering them later during testing—or worse, in production.

Why I Was Hesitant

I could definitely see the benefits when working in a team.

If everyone follows the same types, it becomes much harder to accidentally pass the wrong data around.

But as someone building solo, I kept asking myself:

"Do I really need all of this?"

I'll admit...

Part of it was just laziness.

Writing types felt like extra work.

Then Came My First Next.js Deployment...

This was probably the moment that changed my opinion.

While deploying my Next.js project, TypeScript started complaining about issues I had ignored during development.

It was frustrating.

At one point I seriously thought:

"Why is this making deployment so much harder?"

But after fixing those issues, I realized something.

TypeScript wasn't creating bugs.

It was forcing me to fix bugs before users ever saw them.

Looking back, that's exactly what I want from my tooling.

The Downsides

TypeScript isn't perfect.

Some of the things I still find annoying are:

Writing extra type definitions.
Spending time fixing compiler errors.
Feeling like there's more boilerplate than plain JavaScript.

If you're building a quick prototype, JavaScript often feels faster.

So... Is It Worth It?

For small personal projects, JavaScript is still an excellent choice.

But for larger applications—or anything you expect to maintain for months or years—I now understand why TypeScript has become the standard for so many teams.

Yes, it slows you down a little at first.

But it can save you hours of debugging later.

For me, the trade-off is worth it.

Final Thoughts

When I started learning TypeScript, I saw it as unnecessary complexity.

Now I see it as an investment.

It catches mistakes early, makes code easier to understand, and gives me more confidence when building larger projects like my SaaS.

I'm still learning it every day, but I'm glad I stuck with it.

What about you?

What's one thing TypeScript changed about the way you write JavaScript?

By the way this is just my personal opinion

I'd love to hear your experience in the comments.

5 JavaScript Features I Wish I Had Learned Earlier

Code X Savage — Thu, 16 Jul 2026 23:16:40 +0000

JavaScript is one of those languages where you can build a lot without knowing every feature. But as I continue building projects, I've come across a few features that make my code cleaner and easier to maintain.

Here are five JavaScript features I wish I had learned much earlier.

1. Optional Chaining (`?.`)

Accessing nested properties used to look like this:

const city = user && user.address && user.address.city;

Now it becomes:

const city = user?.address?.city;

If any property doesn't exist, JavaScript simply returns undefined instead of throwing an error.

2. Nullish Coalescing (`??`)

Many developers use ||, but it can produce unexpected results.

const username = "";
const name = username || "Guest";

console.log(name); // Guest

Sometimes an empty string is a valid value.

Using ?? fixes that:

const username = "";
const name = username ?? "Guest";

console.log(name); // ""

?? only falls back when the value is null or undefined.

3. Destructuring

Instead of writing:

const name = user.name;
const age = user.age;

You can write:

const { name, age } = user;

It's cleaner and scales much better.

4. Spread Operator (`...`)

Creating a copy of an array is incredibly easy.

const numbers = [1, 2, 3];

const copy = [...numbers];

You can also merge arrays:

const merged = [...arrayOne, ...arrayTwo];

The spread operator also works with objects:

const user = {
  name: "Alex",
  role: "Developer",
};

const updatedUser = {
  ...user,
  role: "Senior Developer",
};

5. Array Methods

Instead of traditional loops:

for (let i = 0; i < users.length; i++) {
  console.log(users[i]);
}

Modern JavaScript provides expressive methods:

users.forEach(user => console.log(user));

const activeUsers = users.filter(user => user.active);

const names = users.map(user => user.name);

These methods often make your code easier to read.

Bonus Tip: Template Literals

Instead of concatenating strings:

const greeting = "Hello, " + name + "!";

You can use template literals:

const greeting = `Hello, ${name}!`;

They're cleaner and especially useful for multi-line strings.

Final Thoughts

Learning JavaScript isn't about memorizing every feature.

It's about gradually discovering tools that help you write cleaner, more maintainable code.

The more projects you build, the more these features start to feel like second nature.

Which JavaScript feature do you wish you had learned earlier? Let me know in the comments!

I Spent Hours Debugging better-auth OAuth… Because I Overthought It

Code X Savage — Thu, 02 Jul 2026 19:47:15 +0000

We’ve all been there: you’re building a Next.js app, hit a wall, and spend hours questioning your entire tech stack—only to realize you overthought the whole thing.
Recently, I was setting up Google OAuth using better-auth. I followed the docs, which clearly showed the authClient.signIn.social() method.

*The Next.js Rabbit Hole
*
My brain made an assumption: "If there is a sign-in endpoint, there must be a separate sign-up endpoint for new users." Believing this, I spent hours debugging and pointing fingers at everything:
Is better-auth bugged?
Is react-hook-form failing to pass data?
Is my database schema blocking new users?

*The Fix
*
I completely overthought it. In better-auth, signIn handles both sign-in AND sign-up automatically. If a user doesn't exist, it creates them. There is no separate sign-up endpoint for OAuth. I was just hitting the wrong endpoint.
The Lesson
If the docs only show one method for OAuth, trust it! It does it all.
Save yourself the headache and don't look for a sign-up endpoint that doesn't exist. 😂

DEV Community: Code X Savage

React Components Aren't Magic—They're Built on a JavaScript Mindset

Before You Learn React, Master This JavaScript Habit

Why Reusability Matters

JavaScript Already Supports This

This Is The Mindset React Builds On

React Isn't Magic

What You Should Practice Before React

Final Thoughts

Is Typescript worth it?

Is TypeScript Really Worth Learning?

What Exactly Is TypeScript?

So What Is Type Safety?

Why I Was Hesitant

Then Came My First Next.js Deployment...

The Downsides

So... Is It Worth It?

Final Thoughts

5 JavaScript Features I Wish I Had Learned Earlier

1. Optional Chaining (?.)

2. Nullish Coalescing (??)

3. Destructuring

4. Spread Operator (...)

5. Array Methods

Bonus Tip: Template Literals

Final Thoughts

I Spent Hours Debugging better-auth OAuth… Because I Overthought It

1. Optional Chaining (`?.`)

2. Nullish Coalescing (`??`)

4. Spread Operator (`...`)