DEV Community: Turkan İsayeva

Why You Should Switch from Vanilla JavaScript to React and How React Architecture Works

Turkan İsayeva — Fri, 26 Dec 2025 11:55:24 +0000

Hey everyone, I want to share something that really clicked for me when I started working with React. If you've ever felt frustrated with vanilla JavaScript and wondered why people switch to React, this will make total sense.

Vanilla JS: One Big Chunk

Imagine your UI as one huge chunk of code. In vanilla JavaScript, this is often exactly what happens. You have this big file that handles everything , updating the DOM, managing events, tracking data. And here's the problem: when a tiny change happens, say updating a single text field or a counter, the system doesn't know what exactly changed.
So what does it do? Well… nothing smart. It basically goes through the whole UI and updates everything, whether it needs to or not. And let's be honest that's slow, it's messy, and sometimes it's hard even to find where the change should go.

Enter React: Components, Hooks, and Virtual DOM

Now, React blew my mind because it works completely differently. The first thing I realized is that React thinks of the UI as a collection of components, parent components, child components, and so on. Every small piece of the UI can live in its own little component, and each component remembers its own state using hooks.
Hooks like useState are brilliant because they store values that change over time. And the best part? When a state changes, React doesn't blindly refresh everything; it knows exactly which component needs to update.
But how does React find what changed so quickly? That's where the Virtual DOM comes in. React keeps a lightweight copy of the UI in memory, compares it to the real DOM, and only updates the parts that actually changed. This means: fast, efficient updates, zero overload, and I can finally breathe knowing my tiny changes won't break everything else.

Props: The Communication Network

Another thing that clicked for me is how components talk to each other. In React, data flows through props, like messages traveling through a network. The parent component holds the main state, sends pieces to child components, and children can even trigger updates back to the parent.
This setup reminded me of a mini social network inside my UI: everyone knows what to send, who to update, and nothing gets lost in the chaos.

Why This Matters

React isn't just a library; it's a whole mindset shift. It taught me to:

Break my UI into manageable, reusable components
Track only what really changes
Let React handle the heavy lifting of updates
Focus on building features, not hunting down bugs

Honestly, once you see it in action, it's hard to go back. You start appreciating the elegance of localized updates, the beauty of hooks, and the efficiency of Virtual DOM diffing.

Architectural Pov:

When I started thinking about React from an architectural standpoint, it hit me: React isn't just a library for updating the UI; it's a networking system for components.
Here's what I mean:

In vanilla JavaScript, everything is linear. One big chunk, one way of updating, one chain of events. It's like a single pipe , whatever you push, flows straight through, and everything downstream gets affected.
In React, it's multi-directional. Components are nodes in a network:
Parent components send data to children via props
Children can trigger changes back to parents via callbacks and state updates
Siblings can indirectly communicate through shared context or lifted state
Hooks are like local memory nodes at each component. They store the state and keep track of changes; React monitors these nodes and knows exactly which paths to update.
The Virtual DOM acts like the network manager. It constantly compares the new "state of the network" with the old one and ensures only the affected nodes are updated.

So, React isn't just about rendering UI efficiently; it's about designing a dynamic, self-aware network of components that communicate smartly and only act when necessary.
From this architectural lens, you can see why React scales so well: each component is modular, autonomous, and connected in a way that feels like a smart, reactive ecosystem rather than a monolithic, rigid structure.

Author's note: I mean, it is not easy, but is it worth it.. ? Hell yeah..

AI vs ML vs LLMs - Why We Keep Mixing Them Up (And How to Finally Understand Them)

Turkan İsayeva — Tue, 25 Nov 2025 05:01:32 +0000

Many people hear “AI” and instantly think of ChatGPT.
But the truth is: AI existed long before ChatGPT, and most AI we used for years wasn’t conversational at all.

AI: The Big Umbrella

Let’s start from the top.

Artificial Intelligence is the broadest term.
If a system tries to mimic human intelligence — learning, decision-making, perception — it falls under AI.

AI includes many subfields:
• Machine Learning
• Deep Learning
• Computer Vision
• Natural Language Processing
• Robotics
• Expert systems

ML: The Engine Behind Most “Old AI”

Before ChatGPT, the AI powering our world was mostly Machine Learning.

ML is simply this:

Models learn patterns from data and make predictions — without being explicitly programmed.

For almost 20 years, ML quietly powered:
• Fraud detection
• Credit scoring
• Traffic prediction in maps
• Recommendation engines
• Face recognition
• Spam filters
• Search ranking

And here’s the interesting part:
These models were not “smart” in a conversational way.
They didn’t talk, write, reason, or code.

They were mathematical prediction systems:
• Logistic regression
• Decision trees
• Random forest
• Gradient boosting (XGBoost, LightGBM)
• Early neural networks

This was the AI that shaped the modern internet long before LLMs arrived.

LLMs: The New Evolution of AI This changed everything.

Suddenly, AI could:
• Understand text
• Generate text
• Reason
• Summarize
• Translate
• Write code
• Assist with workflows

This is where LLMs (Large Language Models) came in.

LLMs like ChatGPT, Claude, Gemini, and Llama aren’t just tools, they’re a new category of AI entirely.
They work on language, not just numbers.
They’re trained on massive datasets.
And they’re capable of general-purpose intelligence that older ML models were nowhere near.

In short:

ML predicted.
LLMs communicated.

The Whole Relationship:

AI is the field.
ML is a major branch inside AI.
LLMs are one specific type of ML model focused on language

Design Patterns: The Storytelling of Code

Turkan İsayeva — Sun, 24 Aug 2025 14:52:19 +0000

Content:

What design patterns are
Why they exist
Their categories (creational, structural, behavioral)
Observer & Factory examples
A beautiful analogy with writing/art

When we write code, we’re not just instructing machines; We’re expressing ideas, solving problems, and communicating with other developers. In many ways, programming is like writing a story. Just as writers use alphabets, words, and literary devices, developers use syntax, functions, and design patterns to tell their story in code.

What Are Design Patterns?

Design patterns are proven, reusable solutions to recurring problems in software development. They aren’t new syntax or frameworks, but best practices, like blueprints that show us how to organize our code more clearly, flexibly, and maintainably.

They serve as a shared language among developers. Instead of writing paragraphs to explain, you can simply say “I’ll use the Observer pattern” and everyone understands.

Why Do We Need Them?

Before Patterns

Code was often messy and repetitive.
Changes in one part could break everything else (tight coupling).
Adding new features meant rewriting large chunks of code.

After Patterns

Code becomes clean, flexible, and reusable.
Developers solve problems in standard, battle-tested ways.
Teams can communicate faster using a shared vocabulary.

Types of Design Patterns

Patterns are usually grouped into three families:

Creational – deal with object creation. (e.g., Factory, Singleton)
Structural – deal with how objects are composed. (e.g., Adapter, Decorator)
Behavioral – deal with how objects interact. (e.g., Observer, Strategy, Command)

Observer Pattern (Behavioral)

Problem: How do you make sure that when one object changes, all dependent objects are automatically updated?

Solution: Define a one-to-many relationship between a subject and its observers.

JavaScript Example:

class Subject {
  constructor() {
    this.observers = [];
  }
  subscribe(observer) {
    this.observers.push(observer);
  }
  notify(data) {
    this.observers.forEach(obs => obs.update(data));
  }
}

class Observer {
  constructor(name) {
    this.name = name;
  }
  update(data) {
    console.log(`${this.name} received: ${data}`);
  }
}

const news = new Subject();
const alice = new Observer("Alice");
const bob = new Observer("Bob");

news.subscribe(alice);
news.subscribe(bob);

news.notify("New article published!");

Whenever the subject (news) changes, all observers (subscribers) are notified automatically.

Factory Pattern (Creational)

Problem: How can we centralize object creation so adding new types doesn’t break our code everywhere?

Solution: Use a factory class that decides which object to create.

JavaScript Example:

class Admin {
  constructor(name) { this.role = "Admin"; this.name = name; }
}
class Guest {
  constructor(name) { this.role = "Guest"; this.name = name; }
}

class UserFactory {
  createUser(type, name) {
    switch (type) {
      case "admin": return new Admin(name);
      case "guest": return new Guest(name);
      default: throw new Error("Invalid type");
    }
  }
}

const factory = new UserFactory();
const user1 = factory.createUser("admin", "Alice");
const user2 = factory.createUser("guest", "Bob");

console.log(user1, user2);

Adding a new user type is as simple as editing the factory, not rewriting code everywhere else.

The Artistic Analogy: Code as Storytelling
Your insight was perfect: writing code is like writing a story.

Writing / Art	Coding	Analogy
Alphabet	Syntax (`let`, `class`)	Building blocks
Words	Variables, expressions	Small meaning
Sentences	Functions	Complete thought
Paragraphs / Chapters	Classes, modules	Organized units
Story / Book	Software	Complete system
Literary Devices (metaphor, foreshadowing)	Design Patterns (Observer, Factory)	Elegant, reusable structures
Genres (Romance, Sci-fi)	Frameworks (React, Django)	Guiding structure
Plot	Algorithms	Sequence of events
Editing	Refactoring	Polishing work

Just like writers don’t invent a new alphabet every time, developers don’t invent new syntax. Instead, they use design patterns like literary devices, ways to express ideas more clearly, elegantly, and universally.

So,

Design patterns are not “new code you must write.” They are shared wisdom, best practices that have stood the test of time.

Just as a novelist uses foreshadowing or symbolism, a programmer uses Observer or Factory. Both make the story whether on paper or in code easier to understand, more flexible, and more powerful.

Future Start Here, Join Me!
-Turkan Isayeva

React

Turkan İsayeva — Fri, 08 Aug 2025 17:59:30 +0000

Why React Cares About Immutability: A Deep Dive into Reference, Reconciliation, and Rendering

Turkan İsayeva — Sun, 03 Aug 2025 17:19:02 +0000

Why React Cares About Immutability: A Deep Dive into Reference, Reconciliation, and Rendering.

When you first hear the term “immutability” in React, it might sound like just another fancy concept you’re expected to remember. But this one matters — a lot. Behind the scenes, it’s powering how your UI knows when to update, or when to stay quiet.

Let’s break it down step by step, with clarity and a little curiosity.

The Cycle Behind Every React Update

Whenever a React component updates, it’s because something triggered a change in its state or props. But React doesn’t guess that something has changed, it uses a smart process:

You call setState or pass new props
React compares the current Virtual DOM with the previous one
It finds what changed and updates the real DOM only where needed

This process is called reconciliation, and the way React decides what changed is surprisingly simple:

It checks whether the reference of the new state/props is different from the previous one.

Why Reference?

In JavaScript, reference comparison is fast and cheap.

const a = { name: "Turkan" };
const b = { name: "Turkan" };
console.log(a === b); // false (different references)

Even though the content is the same, these are two separate objects in memory.

React takes advantage of this:

If the reference changes → React re-renders.
If the reference stays the same → React assumes nothing changed.

The Mutation Trap

Here’s where many beginners (and even experienced devs!) fall into a subtle trap:

const [user, setUser] = useState({ name: "Turkan" });

const updateUser = () => {
  user.name = "Daniel";   // ❌ mutated directly
  setUser(user);         // ❌ same reference
};

Even though you changed the value inside user, the reference didn’t change.
React compares old and new state like this:

Object.is(prevState, newState); // true → no update

Result? No re-render. No UI update. Confused developer.

Immutability to the Rescue

Let’s fix it the React way:

const updateUser = () => {
  setUser({ ...user, name: "Daniel" }); // ✅new object, new reference
};

Now React sees:

Object.is(prevState, newState); // false → trigger re-render

This is the heart of immutability in React:

Don’t modify the original, create a new version instead.

It’s Not Just Theory. It’s Performance

Immutability helps React:

Quickly know what changed
Skip unnecessary updates
Keep your UI fast and snappy

It’s not about being “functional” or “fancy”.It’s about making the diffing algorithm efficient.

Finally:

If you’re updating arrays or objects in React, always ask yourself:

Am I mutating the old data, or creating a new version?

Because React doesn’t care what’s inside ; it only cares whether the reference changed.

Summary:

React uses reference checks to detect changes
Immutability ensures new references are created
This powers reconciliation and efficient rendering
Mutating state directly breaks this chain → no updates
Always return new objects or arrays in setState

The Essential Guide to Code Commenting: Best Practices, Types, and Documentation.

Turkan İsayeva — Sat, 02 Aug 2025 16:30:53 +0000

When writing code, communication isn’t just between you and the machine, but it’s also between you and other developers (or your future self!). Clear and effective code commenting plays a vital role in making your code understandable, maintainable, and scalable.

In this guide, we’ll explore:

What code comments are and why they matter
Different types of comments: inline vs. block
The power of JSDoc for inline documentation
How to balance commenting to avoid clutter
Advantages of structured documentation over simple comments

What Are Code Comments?

Code comments are notes written inside your source code to explain what the code does, why certain decisions were made, or how to use a function or module. They don’t affect the program execution but are critical for clarity.

Comments help:

Other developers quickly understand your code
You recall your own logic months later
Tools and IDEs provide better assistance (when using structured comments like JSDoc)

Types of Comments: Inline vs. Block

Inline Comments

Written on a single line, usually beside the code they explain
Start with // in JavaScript
Ideal for brief explanations or notes

Example:

let count = 10;  // number of items to process

Block Comments

Can span multiple lines, enclosed between /* and */
Used for longer explanations, function headers, or multi-line notes

Example:

/*
  Calculates the sum of two numbers.
  This function takes two numeric inputs and returns their sum.
*/
function add(a, b) {
  return a + b;
}

Why Use JSDoc? The Power of Structured Inline Documentation

While simple comments are helpful, JSDoc takes documentation to the next level by providing a structured way to describe functions, parameters, return values, and more — all inline with your code.

Example JSDoc usage:

/**
 * Adds two numbers.
 * @param {number} a - First number
 * @param {number} b - Second number
 * @returns {number} Sum of a and b
 */
function add(a, b) {
  return a + b;
}

Benefits of JSDoc over simple comments:

Provides type information for parameters and return values
Helps IDEs (like VSCode) show helpful hints and autocomplete suggestions
Enables automatic generation of API documentation with tools like jsdoc CLI
Improves readability by enforcing a standard format
Clarifies the intent and usage of functions better than generic comments

Balancing Comments: When and How Much to Comment?

While commenting is crucial, too many comments can clutter code and reduce readability. Here are some tips for a good balance:

Write self-explanatory code first: Use meaningful variable and function names so that the code itself communicates its purpose. This reduces the need for excessive commenting.
Comment the “why,” not the “what”: Explain the reason behind complex logic, not obvious code. For example, avoid comments like // adds two numbers on a simple addition function.
Document public APIs and complex functions: Use JSDoc or block comments to describe how to use functions, especially if they have multiple parameters or tricky behavior.
Avoid redundant comments: Comments that just repeat what the code does add no value and should be removed.

Inline Comment vs. JSDoc: A Quick Comparison

Aspect	Inline Comment (`//`)	JSDoc (`/** ... */`)
Purpose	Brief notes or reminders	Structured documentation of code
Format	Simple, unstructured	Formal tags like `@param`, `@returns`
IDE Support	Basic syntax highlighting	Enhanced support: hints, autocomplete
Documentation Generation	None	Supports automatic API docs

Example: Comparing Inline Comment and JSDoc

Inline Comment

// Adds two numbers and returns the result
function add(a, b) {
  return a + b;
}

JSDoc Comment

/**
 * Adds two numbers.
 * @param {number} a - First number
 * @param {number} b - Second number
 * @returns {number} Sum of a and b
 */
function add(a, b) {
  return a + b;
}

The JSDoc comment provides richer information and better tool support.

Summary:

Good commenting is an art. Writing clear, concise, and meaningful comments, especially using tools like JSDoc — makes your code more understandable and maintainable for everyone, including your future self.

Always strive to:

Write readable code first
Use comments to explain “why” and document usage
Use JSDoc for structured, standardized documentation

This will save time, reduce bugs, and make collaboration much smoother.

Is Everything in JavaScript an Object?

Turkan İsayeva — Sat, 26 Jul 2025 06:11:27 +0000

While this is a well-known phrase among JS developers, it’s not utterly true.

JavaScript has two main categories of data types:

1️⃣. Primitive Types – string, number, boolean, null, undefined, symbol, bigint
2️⃣. Object Types – Object, Array, Function, Date, RegExp, etc.

⁉️ So Why Do We Say “Everything is an Object”?

Even though primitives like strings and numbers are not
objects, they can behave like objects. This is because JavaScript temporarily wraps them in their corresponding object wrapper when you try to access a property or call a method.

let name = "Turkan";
console.log(name.length); // 6

Here, "Turkan" is a primitive string, but JavaScript internally wraps it in a String object, so you can use .length and other methods like .toUpperCase().

‼️ But Remember:
• Primitives are not objects.
• typeof null === "object" is a historical bug in JavaScript. null is not an object.
• Only actual object types can store methods and properties persistently.

🎬 So,

“Everything in JavaScript behaves like an object, but not everything is an object.”

Understanding this distinction helps you write cleaner and more predictable code.