DEV Community: Code X Savage

Editing Text Contents with DOM

Code X Savage — Tue, 28 Jul 2026 14:50:43 +0000

One of the biggest misconceptions I had when learning JavaScript was thinking that the DOM and HTML were the same thing.

They aren't.

When I first started manipulating web pages, I kept hearing things like:

"Use querySelector() to select an element from the DOM."

My first thought was:

"Isn't it just selecting the HTML?"

It turns out there's an important difference, and understanding that difference makes JavaScript much easier to reason about.

Let's break it down.

HTML vs The DOM

HTML is simply a text document.

<body>
    <h1>Hello World</h1>
    <p>Welcome to my website.</p>
</body>

That's all it is.

A text file.

Your browser then reads that file and creates something called the Document Object Model (DOM).

Think of the DOM as a live representation of your HTML that JavaScript can interact with.

Document
│
└── body
    ├── h1
    │   └── "Hello World"
    │
    └── p
        └── "Welcome to my website."

JavaScript never edits your original HTML file.

Instead, it manipulates this DOM tree.

That's why when you inspect a page in your browser, you'll often see changes that don't exist inside your original HTML file.

Selecting Elements

Once the DOM has been created, JavaScript can find elements.

const heading = document.querySelector("h1");

Now you have access to that DOM node.

From here you can:

Change text
Change styles
Add classes
Remove elements
Create new elements
Listen for events

This is what people mean when they say JavaScript manipulates the DOM.

Changing Content

This is where many beginners get confused.

JavaScript gives us multiple ways to change an element's content.

The three you'll encounter the most are:

innerHTML
innerText
textContent

At first glance they seem similar.

They're not.

1. innerHTML

innerHTML reads or writes HTML inside an element.

Example:

<div id="box"></div>

const box = document.getElementById("box");

box.innerHTML = "<h2>Hello</h2>";

The browser creates an actual <h2> element.

Result:

<div id="box">
    <h2>Hello</h2>
</div>

This makes innerHTML incredibly powerful.

Pros

Can create HTML dynamically.
Useful for rendering templates.
Great for inserting multiple elements at once.

Cons

If the content comes from user input, using innerHTML carelessly can introduce security issues, such as executing unwanted HTML or scripts.

It also causes the browser to parse the HTML again, which can be less efficient than simply changing text.

For those reasons, avoid using innerHTML unless you actually need to insert HTML.

2. innerText

innerText only works with visible text.

<p id="text">
    Hello
    <span style="display:none">Hidden</span>
</p>

console.log(text.innerText);

Output:

Hello

Notice the hidden text isn't included.

This is because innerText considers how the page is rendered.

If something isn't visible to the user, it usually won't appear.

Pros

Reflects what users actually see.
Great for reading visible text.
Ignores hidden content.

Cons

Because it considers styling and layout, reading innerText can require extra work from the browser.

For large applications, repeatedly using it can be less efficient than textContent.

3. textContent

textContent retrieves all text inside an element.

Using the same example:

<p id="text">
    Hello
    <span style="display:none">Hidden</span>
</p>

console.log(text.textContent);

Output:

Hello Hidden

Unlike innerText, it doesn't care whether the text is visible.

It simply returns the raw text contained in the node.

Pros

Faster than innerText.
Includes hidden text.
Doesn't interpret HTML.
Safe for inserting plain text.

Cons

It ignores how the page is displayed.

If you only care about what users can actually see, innerText may be the better choice.

Which One Should You Use?

Here's a simple rule I like to follow.

Use	When
`textContent`	When you're working with plain text.
`innerText`	When you specifically need the visible text shown to users.
`innerHTML`	Only when you genuinely need to create or insert HTML.

If you're unsure, start with textContent.

It's safer and usually the better default.

A Common Beginner Mistake

When I first learned JavaScript, I used innerHTML for almost everything.

heading.innerHTML = username;

Later I realised I wasn't inserting HTML.

I was only displaying text.

This is a much better choice:

heading.textContent = username;

It's simpler, safer, and communicates your intention more clearly.

Final Thoughts

Understanding the DOM isn't just about learning methods like querySelector().

It's about understanding what JavaScript is actually manipulating.

The browser converts your HTML into a DOM tree.

JavaScript interacts with that tree.

And choosing the right property—innerHTML, innerText, or textContent—depends on what you're trying to achieve.

The more you understand these differences, the more confident you'll become when building interactive web applications.

What About You?

When you first started learning JavaScript, which one confused you the most?

innerHTML
innerText
textContent

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

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

Editing Text Contents with DOM

HTML vs The DOM

Selecting Elements

Changing Content

1. innerHTML

Pros

Cons

2. innerText

Pros

Cons

3. textContent

Pros

Cons

Which One Should You Use?

A Common Beginner Mistake

Final Thoughts

What About You?

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 (`...`)