DEV Community: HARSHITH GADDAM

TypeScript Basics, Jest Mocking, and Git Etiquette

HARSHITH GADDAM — Thu, 27 Aug 2026 14:26:29 +0000

From Types to Testing: TypeScript Basics, Jest Mocking, and Git Etiquette

When learning modern full-stack development, knowing a programming language is not enough. We also need to write clean code, test our code, and work properly with Git.

In this post, we will look at some important basics of TypeScript, Jest testing, Git workflows, and code review etiquette.

1. TypeScript Basics: Types, Interfaces & Generics

TypeScript is JavaScript with static typing.

It helps us find many errors before running our code.

Basic Types

We can specify the type of a variable:

const developerName: string = "Harshith";
const experienceYears: number = 2;
const isDeveloper: boolean = true;

Here:

string → text
number → numbers
boolean → true or false

Interfaces

An interface defines the structure of an object.

interface User {
  readonly id: number;
  name: string;
  email: string;
  role?: string;
}

Now we can create a User object:

const currentUser: User = {
  id: 101,
  name: "Harshith",
  email: "harshith@example.com",
};

Important Interface Features

readonly

readonly id: number;

The value cannot be changed after the object is created.

Optional property

role?: string;

The role property is optional.

So this is also valid:

const user: User = {
  id: 102,
  name: "Rahul",
  email: "rahul@example.com",
};

2. Why TypeScript Is Useful

JavaScript allows this:

let age = 20;
age = "twenty";

TypeScript can prevent this mistake:

let age: number = 20;

// Error
age = "twenty";

This makes large applications easier to maintain and debug.

3. Jest Testing Basics

Jest is a JavaScript testing framework.

It allows us to check whether our functions are working correctly.

For example:

function add(a, b) {
  return a + b;
}

We can test it using Jest:

test("adds two numbers", () => {
  expect(add(2, 3)).toBe(5);
});

Here:

test() defines a test.
expect() checks the result.
toBe() compares the actual value with the expected value.

Testing helps us find bugs before they reach production.

4. Jest Mocking

Sometimes our function depends on another function or service.

Instead of calling the real service during a test, we can use a mock.

For example:

const getUser = jest.fn();

getUser.mockReturnValue({
  name: "Harshith"
});

Now getUser() returns our test data instead of calling a real database or API.

Mocking is useful because tests become:

Faster
More predictable
Independent of external services

5. Git Feature Branches

When working on a project, we should avoid making every change directly on the main branch.

Instead, we can create a feature branch:

git checkout -b feature/typescript-basics

Then make our changes and commit them:

git add .
git commit -m "feat: add TypeScript basics"

Finally, push the branch:

git push origin feature/typescript-basics

We can then create a Pull Request and ask other developers to review our changes.

6. Code Review Etiquette

Code reviews are not about finding mistakes in someone's code to criticize them.

The main goal is to improve the code together.

Instead of saying:

"This code is bad."

We can say:

"Could we simplify this function to make it easier to maintain?"

Good code review comments should be:

Clear
Respectful
Specific
Helpful

We should also explain why we are suggesting a change.

Conclusion

Today I learned that modern development involves more than just writing JavaScript.

TypeScript helps us write safer code with types and interfaces.

Jest helps us test our code and find problems early.

Git branches help us work safely without directly changing the main branch.

Code review etiquette helps teams communicate and improve code together.

Learning these concepts will help me write cleaner code and work more effectively in a professional development environment.

My Javascript Learning Journey:Async,Await,iterators & Generators

HARSHITH GADDAM — Sat, 15 Aug 2026 13:03:36 +0000

Today I learned several important JavaScript concepts related to asynchronous programming and iteration. Instead of only learning how these features work, I focused on understanding why they were introduced, the problems they solve, and where they are used in real-world applications.

Async/Await – Syntax Sugar over Promises

One of the biggest things I learned today is that async/await does not replace Promises. It is simply a cleaner and more readable way to work with them.

When we write:

async function getUser() {
    const user = await fetchUser();
    return user;
}

JavaScript is still using Promises internally. The await keyword pauses the execution of the async function until the Promise settles, making asynchronous code look very similar to synchronous code.

Without async/await, the same logic would require multiple .then() calls, making complex asynchronous code harder to read and maintain.

Handling Async Errors with try...catch

When using Promises directly, errors are usually handled with .catch().

fetchUser()
    .then(user => console.log(user))
    .catch(err => console.error(err));

With async/await, the same error handling becomes much cleaner using try...catch.

async function loadUser() {
    try {
        const user = await fetchUser();
        console.log(user);
    } catch (err) {
        console.error(err);
    }
}

I learned that try...catch only works with await inside an async function. If the awaited Promise rejects, JavaScript throws that rejection as an exception, which is then caught by the catch block.

This makes asynchronous error handling look just like normal synchronous error handling.

Promise.all()

Promise.all() is used when multiple asynchronous tasks need to finish before continuing.

For example, imagine a dashboard that needs to load:

User Profile
Orders
Shopping Cart
Recommendations

All these requests can start at the same time, but the dashboard should only be shown after every request is completed.

await Promise.all([
    fetchProfile(),
    fetchOrders(),
    fetchCart(),
    fetchRecommendations()
]);

I also learned that Promise.all() does not start the promises. The promises begin executing when they are created (or when the function calls are evaluated). Promise.all() simply waits for all of them to settle successfully.

Can We Display Data One by One?

Yes!

Instead of waiting for every request, each section of a webpage can be displayed as soon as its data arrives.

For example:

Show the profile first.
Then show the orders.
Then display the cart.
Finally load the recommendations.

Many websites like YouTube and Amazon use this approach to improve the user experience.

Promise.allSettled()

Sometimes we don't want the whole operation to fail just because one task fails.

For example, while uploading five files:

File 1 ✔️
File 2 ❌
File 3 ✔️
File 4 ✔️
File 5 ❌

Using Promise.all(), the first failure rejects the entire operation.

Using Promise.allSettled(), JavaScript waits for every promise to finish and tells us which ones succeeded and which ones failed.

This is useful for:

File uploads
Data synchronization
Background jobs
Health checks

Promise.race()

Promise.race() returns the result of the first promise that settles.

A common example is implementing request timeouts.

Promise.race([
    fetch("/user"),
    timeoutPromise
]);

If the server responds first, we use the response.

If the timeout finishes first, we stop waiting.

Promise.any()

Promise.any() returns the first successful promise.

Rejected promises are ignored unless every promise fails.

This is useful when working with:

Multiple mirror servers
Backup APIs
CDN replicas

The application simply uses the first successful response.

Promise Combinators Summary

Method	Purpose
Promise.all()	Wait for every promise to fulfill
Promise.allSettled()	Wait for every promise to settle, whether fulfilled or rejected
Promise.race()	Use the first promise that settles
Promise.any()	Use the first successful promise

Iterators

I learned that JavaScript needed a common way to loop through different types of collections like arrays, strings, maps, and sets.

An iterator is simply an object with a next() method.

Each call to next() returns:

{
    value,
    done
}

for...of internally uses iterators to retrieve values one by one.

Generators

Writing iterators manually requires managing state and keeping track of the current position.

Generators make this much easier.

A generator is declared using:

function* numbers() {
    yield 1;
    yield 2;
    yield 3;
}

The yield keyword pauses execution and remembers the current state.

Each call to next() resumes execution from where it previously stopped.

Generators automatically create iterators, making iteration much simpler.

Async Iterators

Normal iterators work only with values that are immediately available.

But what if the next value comes from:

A server
A database
A file
A WebSocket

In these situations, JavaScript introduced async iterators.

Unlike normal iterators, next() returns a Promise that eventually resolves to:

{
    value,
    done
}

This allows JavaScript to wait until the next value becomes available.

Async Generators

Just as generators simplify iterators, async generators simplify async iterators.

They are declared like this:

async function* stream() {
    yield "First";
    yield "Second";
    yield "Third";
}

They can be consumed using:

for await (const item of stream()) {
    console.log(item);
}

This makes working with asynchronous streams much easier.

Where Async Iterators Are Used

Some real-world examples include:

Streaming large files
Reading database records in batches
Live chat messages
WebSocket communication
AI response streaming (like ChatGPT)
Video or audio streaming

Instead of loading everything into memory, data is processed one piece at a time.

My Biggest Takeaways

async/await is syntax sugar over Promises and makes asynchronous code easier to read.
try...catch provides clean error handling for asynchronous code written with async/await.
Promise.all() waits for every promise and fails if any one fails.
Promise.allSettled() gives the result of every promise, whether it succeeds or fails.
Promise.race() returns whichever promise settles first.
Promise.any() returns the first successful promise.
Promises begin running when they are created; Promise.all() only waits for them.
A webpage doesn't always need to wait for every API before showing content—independent sections can be rendered progressively.
Iterators provide a standard way to access values one by one.
Generators automatically create iterators and use yield to pause and resume execution.
Async iterators return promises from next(), allowing values to arrive over time.
Async generators combine async and yield, making asynchronous data streams much easier to work with.

My JavaScript Learning Journey: CommonJS vs ESM,Design Patterns

HARSHITH GADDAM — Fri, 14 Aug 2026 10:24:42 +0000

JavaScript Architecture, Design Patterns, Memory Mechanics.

Today I learned about core JavaScript architecture, modules, design patterns, memory mechanics.

Understanding how JavaScript handles files, memory, and software design makes it much easier to write clean, scalable, and maintainable applications.

1. CommonJS (CJS) vs. ES Modules (ESM)

JavaScript uses modules to split code across multiple files and avoid polluting the global scope.

CommonJS (CJS)

CommonJS is the traditional module system used heavily in Node.js.

It uses:

require() for importing
module.exports for exporting

// greet.js
module.exports = function greet(name) {
    return `Hello, ${name}`;
};

Importing it:

const greet = require("./greet.js");

console.log(greet("Harshith"));

CommonJS module loading is generally synchronous.

ES Modules (ESM)

ES Modules are the modern JavaScript module standard and are supported by both browsers and modern Node.js.

They use:

export
export default
import

// greet.js
export function greet(name) {
    return `Hello, ${name}`;
}

Importing:

import { greet } from "./greet.js";

console.log(greet("Harshith"));

ESM uses static module declarations, allowing JavaScript engines and tooling to analyze module dependencies before execution.

Named Export vs. Default Export

Feature	Named Export	Default Export
Number per file	Multiple	One
Import syntax	`{}` required	No `{}`
Import name	Must match exported name	Can be any name
Example	`import { add } from "./math.js"`	`import

Calculator from "./Calculator.js"` |

For example:

// Named exports
export function add(a, b) {
    return a + b;
}

export function subtract(a, b) {
    return a - b;
}

Importing:

import { add, subtract } from "./math.js";

A default export:

export default function User() {
    // ...
}

can be imported as:

import User from "./User.js";

Important: Named imports use curly braces because they refer to specific named exports. They are not simply the same thing as ordinary object destructuring.

2. Garbage Collection, Closures, and Memory Leaks

JavaScript automatically manages memory using garbage collection.

Garbage Collection

A common model used by JavaScript engines is Mark-and-Sweep.

The engine starts from reachable roots, such as global references, and follows references to determine which objects are still reachable.

Objects that are no longer reachable can eventually be removed from memory.

let user = {
    name: "Harshith"
};

user = null;

After assigning null, the object previously referenced by user may become unreachable and eligible for garbage collection, assuming nothing else references it.

Closures

A closure occurs when an inner function retains access to variables from its outer lexical scope even after the outer function has finished executing.

function createCounter() {
    let count = 0;

    return function () {
        count++;
        return count;
    };
}

const counter = createCounter();

console.log(counter()); // 1
console.log(counter()); // 2

Even though createCounter() has finished executing, the returned function still has access to count.

Memory Leaks

A memory leak occurs when data that is no longer logically needed remains reachable, preventing garbage collection.

Common causes include:

Uncleared timers
Event listeners that are never removed
Long-lived references to large objects
Closures that unintentionally retain large data

For example:

function setupListener() {
    const heavyData = new Array(1000000).fill("📦");

    document.getElementById("btn").addEventListener("click", () => {
        console.log("Clicked!");
    });
}

The important lesson is that closures themselves are not memory leaks. A closure becomes a problem when it keeps references alive longer than necessary.

3. Four Essential Design Patterns

Design patterns are reusable approaches for solving common software design problems.

A. Module Pattern

The Module Pattern encapsulates internal state and exposes only the functionality that should be public.

A closure can be used to create private state:

const BankModule = (function () {

    let balance = 1000;

    return {
        withdraw(amount) {
            balance -= amount;
            return balance;
        }
    };

})();

Here, balance cannot be accessed directly from outside the module.

Analogy: An ATM hides the internal banking system while exposing only operations such as withdraw and check balance.

B. Singleton Pattern

The Singleton Pattern ensures that only one instance of a particular object is used.

class DatabaseConnection {

    constructor() {

        if (DatabaseConnection.instance) {
            return DatabaseConnection.instance;
        }

        this.connectionString = "mongodb://localhost:27017";

        DatabaseConnection.instance = this;
    }
}

const db1 = new DatabaseConnection();
const db2 = new DatabaseConnection();

console.log(db1 === db2); // true

Both variables refer to the same instance.

Analogy: Think of a single shared resource that the application should coordinate through one instance.

C. Factory Pattern

The Factory Pattern centralizes object creation.

Instead of spreading object-creation logic throughout the application, a factory decides which object to create.

class UserFactory {

    static createUser(type, name) {

        if (type === "admin") {
            return new User(name, ["READ", "WRITE"]);
        }

        if (type === "guest") {
            return new User(name, ["READ"]);
        }
    }
}

const admin = UserFactory.createUser("admin", "Sarah");

The caller doesn't need to know all the details required to create each type of user.

Analogy: A fast-food kitchen receives your order and handles the details of assembling the meal.

D. Observer Pattern

The Observer Pattern creates a one-to-many relationship where subscribers are notified when an event occurs.

class EventEmitter {

    constructor() {
        this.events = {};
    }

    on(event, listener) {

        if (!this.events[event]) {
            this.events[event] = [];
        }

        this.events[event].push(listener);
    }

    emit(event, data) {

        if (this.events[event]) {
            this.events[event].forEach(fn => fn(data));
        }
    }
}

Multiple listeners can subscribe to an event:

Event occurs
     ↓
EventEmitter
     ↓
 ┌───┼───┐
 ↓   ↓   ↓
L1  L2  L3

This helps create loosely coupled systems.

4. Functional Strategy Pattern

The Strategy Pattern allows us to choose between different algorithms without changing the main logic that uses them.

In functional JavaScript, strategies can simply be functions.

const fedexStrategy = (pkg) => {
    return pkg.weight * 1.5 + 5;
};

const uspsStrategy = (pkg) => {
    return pkg.weight * 0.9 + 3;
};

We can create a function that accepts a strategy:

const createShippingCalculator = (strategy) => (pkg) => {
    return strategy(pkg);
};

Then create a pre-configured calculator:

const calculateFedex =
    createShippingCalculator(fedexStrategy);

console.log(
    calculateFedex({ weight: 10 })
);

The important idea is:

Shipping Calculator
       ↓
   Strategy
   ↙     ↘
FedEx    USPS

We can change the strategy without changing the calculator itself.

Understanding `(strategy) => (pkg) => ...`

This syntax means that the outer function returns another function.

const createShippingCalculator = (strategy) => (pkg) => {
    return strategy(pkg);
};

Conceptually:

const createShippingCalculator = (strategy) => {

    return (pkg) => {
        return strategy(pkg);
    };

};

The returned function remembers strategy through a closure.

5. The SOLID Principles

SOLID is a collection of five principles that help us design maintainable and extensible software.

S — Single Responsibility Principle (SRP)

A class or function should have one clear responsibility and one main reason to change.

Instead of:

class User {
    saveToDatabase() {}
    sendEmail() {}
    generateReport() {}
}

we can separate responsibilities:

class UserRepository {

    save(user) {
        // Save user
    }
}

class EmailService {

    sendWelcomeEmail(email) {
        // Send email
    }
}

Each class focuses on a specific responsibility.

O — Open/Closed Principle (OCP)

Software should be open for extension but closed for modification.

For example:

class CreditCardPayment {

    pay(amount) {
        console.log(`Paid $${amount} with Credit Card`);
    }
}

class PayPalPayment {

    pay(amount) {
        console.log(`Paid $${amount} with PayPal`);
    }
}

class PaymentProcessor {

    process(amount, paymentStrategy) {
        paymentStrategy.pay(amount);
    }
}

We can add another payment strategy without modifying PaymentProcessor.

PaymentProcessor
       ↓
   Strategy
   ↙  ↓  ↘
Card PayPal UPI

L — Liskov Substitution Principle (LSP)

A subclass should be usable wherever its parent type is expected without breaking the application's behavior.

A problematic design would be:

class Bird {
    fly() {}
}

class Ostrich extends Bird {
    fly() {
        throw new Error("Cannot fly");
    }
}

The parent class promises that birds can fly, but Ostrich cannot satisfy that expectation.

A better hierarchy is:

class Bird {}

class FlyingBird extends Bird {

    fly() {
        return "Flying";
    }
}

class Duck extends FlyingBird {}

class Ostrich extends Bird {}

Now Ostrich doesn't inherit behavior it cannot support.

I — Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they don't need.

The general idea is:

Prefer small, focused interfaces or contracts rather than one large interface containing everything.

JavaScript doesn't have traditional interfaces like some languages, but the principle still applies when designing classes, objects, and APIs.

D — Dependency Inversion Principle (DIP)

High-level modules should not be tightly coupled to specific low-level implementations.

Instead, dependencies can be provided from outside.

class OrderProcessor {

    constructor(database) {
        this.db = database;
    }

    process(order) {
        this.db.save(order);
    }
}

Here, OrderProcessor doesn't create the database itself.

The dependency is injected:

const database = new Database();

const processor = new OrderProcessor(database);

This makes the code easier to test and replace with another implementation.

javascript #webdevelopment #programming #softwareengineering #designpatterns #solidprinciples #nodejs #learninginpublic

My JavaScript Learning Journey: Call Back Hell & Promises

HARSHITH GADDAM — Tue, 04 Aug 2026 11:54:33 +0000

Today I learned one of the most important concepts in JavaScript—asynchronous programming with Promises. Initially, Promises seemed confusing, but after understanding how they work internally, the concept became much clearer.

1. What is Callback Hell?

A callback is a function passed to another function that executes after an asynchronous operation completes.

When multiple asynchronous operations depend on each other, callbacks become deeply nested.

getUser(userId, function(user) {
    getOrders(user.id, function(orders) {
        getOrderDetails(orders[0].id, function(details) {
            processOrder(details, function(result) {
                console.log(result);
            });
        });
    });
});

This deeply nested structure is called Callback Hell or the Pyramid of Doom.

Problems with Callback Hell

Difficult to read
Hard to debug
Difficult to maintain
Error handling becomes complicated

To solve these problems, JavaScript introduced Promises.

2. What is a Promise?

A Promise is an object that represents the eventual result of an asynchronous operation.

It promises that it will either:

Complete successfully
Fail with an error

A Promise starts in the Pending state and eventually becomes either Fulfilled or Rejected.

3. Promise States

Every Promise has three possible states.

Pending

The asynchronous operation is still running.

Fulfilled

The operation completed successfully.

Rejected

The operation failed.

A Promise can change its state only once.

Pending
   |
   | resolve()
   ▼
Fulfilled

OR

Pending
   |
   | reject()
   ▼
Rejected

4. Creating a Promise

A Promise is created using the Promise constructor.

const promise = new Promise((resolve, reject) => {

});

One important thing I learned today is that I do not create resolve and reject myself.

JavaScript automatically provides these two functions to the Promise executor.

Conceptually, it works like this:

new Promise((resolve, reject) => {

});

Here,

resolve() is used when the operation succeeds.
reject() is used when the operation fails.

5. Using resolve() and reject()

Example:

const promise = new Promise((resolve, reject) => {

    const marks = 80;

    if (marks >= 35)
        resolve("Pass");
    else
        reject("Fail");

});

If the condition is true, the Promise becomes Fulfilled.

Otherwise, it becomes Rejected.

6. Handling Promises

then()

.then() executes only when the Promise is fulfilled.

promise.then(result => {
    console.log(result);
});

catch()

.catch() executes only when the Promise is rejected.

promise.catch(error => {
    console.log(error);
});

finally()

.finally() executes whether the Promise succeeds or fails.

It is useful for cleanup operations like hiding loading indicators or closing connections.

promise.finally(() => {
    console.log("Finished");
});

7. Promise Chaining

Every .then(), .catch(), and .finally() returns another Promise.

This allows us to chain multiple asynchronous operations.

Promise.resolve(10)
    .then(value => value * 2)
    .then(value => value + 5)
    .then(value => console.log(value));

Output:

Each .then() receives the value returned by the previous .then().

8. Error Propagation

One of the most interesting concepts I learned today is Error Propagation.

If an error occurs inside any .then() callback, JavaScript automatically skips all remaining .then() callbacks and jumps directly to the nearest .catch().

Promise.resolve(10)
    .then(value => {
        throw new Error("Something went wrong");
    })
    .then(() => {
        console.log("This will never execute");
    })
    .catch(error => {
        console.log(error.message);
    });

Output:

Something went wrong

This makes error handling much simpler because a single .catch() can handle errors from multiple Promise operations.

9. Practical Promise Example

function login(username, password) {

    return new Promise((resolve, reject) => {

        setTimeout(() => {

            if (username === "harshith" && password === "1234") {
                resolve("Login Successful");
            } else {
                reject("Invalid Username or Password");
            }

        }, 2000);

    });

}

login("harshith", "1234")
    .then(message => console.log(message))
    .catch(error => console.log(error));

This example helped me understand when to call resolve() and reject() based on a condition.

10. Key Takeaways

Callback Hell makes asynchronous code difficult to read and maintain.
Promises solve Callback Hell by making asynchronous code cleaner.
Every Promise has three states: Pending, Fulfilled, and Rejected.
JavaScript automatically provides the resolve() and reject() functions when creating a Promise.
resolve() changes a Promise to Fulfilled.
reject() changes a Promise to Rejected.
.then() handles successful results.
.catch() handles errors and rejected Promises.
.finally() executes regardless of success or failure.
Promise chaining makes complex asynchronous operations easier to manage.
Errors automatically propagate through the Promise chain until they are handled by the nearest .catch().

Conclusion

Today's learning helped me understand how JavaScript manages asynchronous operations using Promises.I learned why callback hell occurs, how Promises improve code readability, how Promise states work, how resolve() and reject() are provided by JavaScript, and how .then(), .catch(), .finally(), Promise chaining, and error propagation make asynchronous programming much cleaner and easier to maintain.

Understanding these concepts has also given me a much stronger foundation for learning async/await, since it is built on top of Promises.

My JavaScript Learning Journey:Object-Oriented Programming (OOP) in JavaScript

HARSHITH GADDAM — Mon, 27 Jul 2026 17:08:59 +0000

JavaScript supports Object-Oriented Programming (OOP) through objects, prototypes, and classes. ES6 introduced a cleaner class syntax, making OOP easier to understand and write. In this blog, I'll explain the four pillars of OOP and some useful class features in JavaScript.

1. Inheritance

Inheritance allows one class to reuse the properties and methods of another class.

Example:

class Animal {
eat() {
console.log("Eating");
}
}

class Dog extends Animal {}

const dog = new Dog();

dog.eat();

Since Dog extends Animal, it inherits the eat() method.

This helps us avoid writing the same code again.

2. Polymorphism

Polymorphism means one method can behave differently depending on the object that calls it.

In JavaScript, this is usually achieved by overriding a parent class method in a child class.

Example

class Animal {
speak() {
console.log("Animal makes a sound");
}
}

class Dog extends Animal {
speak() {
console.log("Dog barks");
}
}

class Cat extends Animal {
speak() {
console.log("Cat meows");
}
}

const dog = new Dog();
const cat = new Cat();

dog.speak();
cat.speak();

Output:

Dog barks
Cat meows

Here, all classes have the same speak() method, but each class provides its own implementation. This is called polymorphism.

3. Abstraction

Abstraction means showing only the necessary functionality and hiding the internal implementation.

For example, when we start a car, we only press the start button. We don't need to know how the engine, fuel system, and battery work internally.

JavaScript allows us to achieve abstraction using classes and private methods or private fields.

Example

class Car {
start() {
this.#checkFuel();
console.log("Car Started");
}

#checkFuel() {
    console.log("Checking Fuel...");
}

}

const car = new Car();

car.start();

Output:

Checking Fuel...
Car Started

The user only calls start(). The internal method #checkFuel() remains hidden from outside the class. This makes the code easier to use and protects the internal implementation.

4. Static Members

Normally, we create an object before calling a method.

const obj = new Person();

But some methods belong to the class itself, not to its objects.

These are called static methods.

Example:

class MathUtil {
static add(a, b) {
return a + b;
}
}

console.log(MathUtil.add(5, 3));

Notice that we didn't create an object.

5. Getters and Setters

Getters and setters allow us to control how properties are read and updated.

Example:

class Person {
constructor(name) {
this._name = name;
}
get name() {
return this._name;
}

set name(value) {
    if (value.length >= 3) {
        this._name = value;
    }
}

}

This helps us validate data before updating it.

6. Encapsulation Using Closures

Encapsulation means bundling data and methods into a single unit.And Closure means accessing the outer methods variables inside inner methods after outer function(method) has completed its execution.

Example:

function BankAccount() {
let balance = 1000;
return {
deposit(amount) {
balance += amount;
},

    getBalance() {
        return balance;
    }
};

}
const account = BankAccount();
account.deposit(500);
console.log(account.getBalance());
//console.log(account.balance); will throw an error

The variable balance cannot be accessed directly from outside the function.

In the above Example you can see balance,deposit(),getBalance() are bundled together.

7. Private Fields (`#field`)

Modern JavaScript provides another way to hide data using private fields.

Example:

class BankAccount {
#balance = 1000;
deposit(amount) {
this.#balance += amount;
}
getBalance() {
return this.#balance;
}
}
const account = new BankAccount();
account.deposit(500);
console.log(account.getBalance());
Trying to access:
account.#balance;

will cause an error because private fields can only be accessed inside the class.

Conclusion

Now I know that JavaScript's OOP system is built on prototypes, and classes simply make the syntax cleaner and easier to read. Understanding these concepts gives a strong foundation for writing better JavaScript code.

My JavaScript Learning Journey:Prototypes

HARSHITH GADDAM — Mon, 27 Jul 2026 12:17:05 +0000

JavaScript is different from many other programming languages when it comes to Object-Oriented Programming (OOP) because it is prototype-based. Instead of using classes as its foundation, JavaScript uses prototypes.

In this blog, I'll explain the topics I learned today.

1. What is a Prototype?

A prototype is a shared object that stores common methods and properties.

Instead of creating a separate copy of the same method for every object, JavaScript stores it once in the prototype, and all objects created from the same constructor or class share it.

Example

function Person(name) {
this.name = name;
}

Person.prototype.greet = function () {
console.log(Hello, I'm ${this.name});
};

const p1 = new Person("Harshith");
const p2 = new Person("Rahul");

p1.greet();
p2.greet();

Here, both p1 and p2 use the same greet() method from Person.prototype.

This saves memory because JavaScript doesn't create multiple copies of the same function.

2. Prototype vs `proto`

This topic confused me at first, but here's the difference.

`prototype`

Exists on functions.
Used when creating new objects with the new keyword.
Stores shared methods.

Example:

function Person(name) {
this.name = name;
}

Person.prototype.greet = function () {};
const p1 = new Person("Harshith");
p1 will have a property called "proto" there it stores the prototype of Person
p1.proto=Person.prototype;

`proto`

Exists on objects.
Points to the object's prototype.
JavaScript follows this link while searching for properties.

Example:

const person = new Person("Harshith");

console.log(person.proto === Person.prototype);

A simple way to remember:

prototype belongs to functions.
__proto__ belongs to objects.

3. Prototype Chain

When JavaScript cannot find a property inside an object, it searches its prototype.

If it is still not found, it continues searching through the next prototype until it reaches null.

Example:

const animal = {
eat() {
console.log("Eating");
}
};

const dog = Object.create(animal);

dog.eat();

JavaScript searches like this:

dog

↓

animal.prototype

↓

null

This searching process is called the Prototype Chain.

4. Object.create()

Object.create() creates a new object whose prototype is another object.

Example:

const animal = {
eat() {
console.log("Eating");
}
};

const dog = Object.create(animal);

dog.eat();

The dog object doesn't have its own eat() method.

It inherits it from animal.

5. Classes are Syntactic Sugar

Before ES6, constructor functions were used to create objects.

function Person(name) {
this.name = name;
}
Person.prototype.greet=function (){
console.log(this.name);
}

Now we can write:

class Person {
constructor(name) {
this.name = name;
}

greet() {
    console.log(this.name);
}

}

Both work almost the same internally.

A class is simply a cleaner and easier syntax built on top of JavaScript's prototype system.

conclusion

At first, JavaScript prototypes can feel confusing because there are terms like prototype, __proto__, constructor functions, and classes. But once I understood that objects inherit methods through prototypes, everything started making sense.

My JavaScript Learning Journey:Understanding the JavaScript Event Loop and Concurrency Model

HARSHITH GADDAM — Tue, 21 Jul 2026 13:31:11 +0000

Today, I learned one of the most important concepts in JavaScript: the Event Loop and the Concurrency Model.

JavaScript is Single-Threaded

JavaScript is a single-threaded language. This means it can execute only one piece of JavaScript code at a time.

For example:

console.log("A");
console.log("B");
console.log("C");

Output:

A
B
C

JavaScript executes these statements one after another.

What is the Call Stack?

The Call Stack is where JavaScript executes functions. Whenever a function is called, it is added to the stack. After the function finishes executing, it is removed from the stack.

Example:

function one() {
two();
}

function two() {
console.log("Hello");
}

one();

Execution order:

one()
↓
two()
↓
console.log()
↓
Stack becomes empty

The Call Stack follows the Last In, First Out (LIFO) principle.

What are Web APIs and Node APIs?

Some operations take time, such as:

Waiting for a timer
Making an API request
Reading a file
Listening for button clicks

JavaScript itself cannot perform these operations.

Instead, it asks the runtime to handle them.

In Browsers

The browser provides Web APIs such as:

setTimeout()
setInterval()
fetch()
addEventListener()
DOM APIs
localStorage

In Node.js

Node.js provides Node APIs such as:

fs.readFile()
fs.writeFile()
path
os
http

These APIs perform asynchronous work outside the JavaScript engine.

Callback (Macrotask) Queue

When an asynchronous operation like setTimeout() finishes, its callback does not execute immediately.

Instead, it is placed into the Callback Queue, also called the Macrotask Queue.

Example:

setTimeout(() => {
console.log("Timer");
}, 1000);

After one second Call back function added to Callback Queue.
It waits there until the Event Loop moves it to the Call Stack.

Microtask Queue

The Microtask Queue has a higher priority than the Callback Queue.

The following callbacks are added to the Microtask Queue:

Promise.then()
Promise.catch()
Promise.finally()
await
queueMicrotask()

Example:

Promise.resolve().then(() => {
console.log("Promise");
});

The callback is placed in the Microtask Queue.

Event Loop

The Event Loop is responsible for checking whether the Call Stack is empty.

When the Call Stack becomes empty, it:

Executes all Microtasks
Executes one Callback (Macrotask)
Again checks call stack is empty or not and does 1&2.

It does not execute code itself. It simply moves callbacks from the queues to the Call Stack.

Why do Promises execute before setTimeout()?

Consider this example:

console.log("Start");

setTimeout(() => {
console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
console.log("Promise");
});

console.log("End");

Output:
Start
End
Promise
Timeout

Why?

Promise.then() goes to the Microtask Queue.
setTimeout() goes to the Callback (Macrotask) Queue.
The Event Loop always executes all Microtasks first before executing Macrotasks.

Does setTimeout() execute exactly on time?

A common misunderstanding is that:

setTimeout(callback, 1000);

means the callback will execute exactly after one second.

This is not true.

It means:

Execute the callback after at least one second.

If the Call Stack is busy with synchronous code, the callback has to wait.

Example:

setTimeout(() => {
console.log("Done");
}, 1000);

// Imagine this loop takes 3 seconds
for (let i = 0; i < 1e10; i++) {}

console.log("Finished");

Output:
Finished
Done

Even though the timer finished after one second, the callback waited until the Call Stack became empty.

What is the JavaScript Concurrency Model?

JavaScript can execute only one line of code at a time, but it can still handle many asynchronous operations.

For example:

A timer can be counting.
A network request can be downloading.
The browser can listen for button clicks.

All these operations are handled by the browser or Node.js while JavaScript continues executing other code.

When these operations finish, their callbacks are added to the appropriate queue.

This ability to make multiple operations progress during the same period of time is called the Concurrency Model.

Cooperative Concurrency vs True Parallelism

These two terms are often confused.

Cooperative Concurrency

Only one JavaScript task runs at a time.

Tasks take turns executing.

Example:

One chef starts cooking rice, then makes tea while the rice cooks.

The chef is not doing both tasks at the exact same moment, but both tasks are progressing.

JavaScript works like this.

True Parallelism

Multiple tasks execute at the exact same time using different CPU cores or threads.

Example:

Chef 1 cooks rice.
Chef 2 makes tea.
Chef 3 cuts vegetables.

All three are working simultaneously.

Conclusion

Learning the Event Loop and the Concurrency Model helped me understand how JavaScript performs asynchronous operations without blocking the main thread. These concepts explain why Promise callbacks execute before setTimeout(), why timers are not always exact, and how browsers and Node.js work together with JavaScript to build responsive applications.

Understanding these fundamentals is essential for writing efficient JavaScript code.
Thank you for reading! If you're also learning JavaScript, I hope this summary helps you understand these concepts more clearly. Happy coding!

My JavaScript Learning Journey: Understanding How JavaScript Really Works

HARSHITH GADDAM — Tue, 21 Jul 2026 11:32:29 +0000

During this learning session, I focused on JavaScript's internal working, including Execution Context, Variables, Scope, Closures, Hoisting, this binding, Call Stack, and Clean Code Principles like DRY and KISS.

JavaScript Execution Context

The first topic I learned was Execution Context.

An Execution Context is the environment in which JavaScript executes code. Whenever JavaScript runs a script or calls a function, it creates an execution context.

Each execution context has two phases:

i)Memory Creation Phase
Before executing the code, JavaScript scans it and allocates memory.

During this phase:

var variables are initialized with undefined.
let and const are allocated memory but remain uninitialized (Temporal Dead Zone).
Function declarations are stored completely in memory.

Example:

console.log(a);
var a = 10;
Output:
undefined

Because var is initialized with undefined during the memory phase.

ii)Code Execution Phase

After memory allocation, JavaScript starts executing the code line by line.

Example:
var a = 10;
console.log(a);
Output:
10

Variables in JavaScript

I learned the differences between var, let, and const.

a)var
-Function scoped
-Can be redeclared
-Can be reassigned
-Hoisted with undefined

b)let
Block scoped
Cannot be redeclared in the same scope
Can be reassigned
Exists in the Temporal Dead Zone before initialization

c)const
Block scoped
Cannot be redeclared
Cannot be reassigned
Must be initialized during declaration

Lexical Scope

One important concept I learned is Lexical Scope.

Lexical Scope means a function can access variables from the scope where it was created.

Example:

let name = "Harshith";

function greet() {
console.log(name);
}

greet();

The function accesses name because it was created inside the same scope.

Closures

A Closure is created when a function remembers variables from its outer scope even after the outer function has finished executing.

Example:

function counter() {

let count = 0;

return function () {
    count++;
    console.log(count);
};

}

const increment = counter();

increment();
increment();
increment();

Output:
1
2
3

The variable count remains available because of the closure.

Closures are commonly used to create private variables and implement the module pattern.

Hoisting

Hoisting is JavaScript's behavior of moving declarations to the top of their scope before execution.

Example:

console.log(a);
var a = 10;

Output:
undefined

For let and const:

console.log(a);
let a = 10;

Output:
ReferenceError

because the variable is inside the Temporal Dead Zone until it is initialized.

Understanding this Binding

One of the most interesting topics I learned was how JavaScript decides the value of this.

a)Default Binding
function greet() {
console.log(this);
}

greet();

In non-strict mode, this refers to the global object.

b)Implicit Binding
const person = {
name: "Harshith",

greet() {
    console.log(this.name);
}

};

person.greet();

Here, this refers to person.

c)Explicit Binding

JavaScript allows us to manually set this using call(), apply(), and bind().

function greet(city) {
console.log(this.name, city);
}

const person = {
name: "Harshith"
};

greet.call(person, "Hyderabad");

d)new Binding

When a function is called using the new keyword, JavaScript creates a new object and binds this to it.

function Person(name) {
this.name = name;
}

const p = new Person("Harsh");

Writing Better Code with DRY and KISS

Besides JavaScript internals, I also learned two important software engineering principles.

a)DRY (Don't Repeat Yourself)

Instead of repeating the same logic multiple times, create reusable functions.

This makes code easier to maintain.

b)KISS (Keep It Simple, Stupid)

Write simple, readable code instead of overly complex solutions.

Simple code is easier to understand, debug, and maintain.

Thank you for reading! If you're also learning JavaScript, I hope this summary helps you understand these core concepts more clearly. Happy coding!

DEV Community: HARSHITH GADDAM

TypeScript Basics, Jest Mocking, and Git Etiquette

From Types to Testing: TypeScript Basics, Jest Mocking, and Git Etiquette

1. TypeScript Basics: Types, Interfaces & Generics

Basic Types

Interfaces

Important Interface Features

2. Why TypeScript Is Useful

3. Jest Testing Basics

4. Jest Mocking

5. Git Feature Branches

6. Code Review Etiquette

Conclusion

My Javascript Learning Journey:Async,Await,iterators & Generators

Async/Await – Syntax Sugar over Promises

Handling Async Errors with try...catch

Promise.all()

Can We Display Data One by One?

Promise.allSettled()

Promise.race()

Promise.any()

Promise Combinators Summary

Iterators

Generators

Async Iterators

Async Generators

Where Async Iterators Are Used

My Biggest Takeaways

My JavaScript Learning Journey: CommonJS vs ESM,Design Patterns

JavaScript Architecture, Design Patterns, Memory Mechanics.

1. CommonJS (CJS) vs. ES Modules (ESM)

CommonJS (CJS)

ES Modules (ESM)

Named Export vs. Default Export

2. Garbage Collection, Closures, and Memory Leaks

Garbage Collection

Closures

Memory Leaks

3. Four Essential Design Patterns

A. Module Pattern

B. Singleton Pattern

C. Factory Pattern

D. Observer Pattern

4. Functional Strategy Pattern

Understanding (strategy) => (pkg) => ...

5. The SOLID Principles

S — Single Responsibility Principle (SRP)

O — Open/Closed Principle (OCP)

L — Liskov Substitution Principle (LSP)

I — Interface Segregation Principle (ISP)

D — Dependency Inversion Principle (DIP)

javascript #webdevelopment #programming #softwareengineering #designpatterns #solidprinciples #nodejs #learninginpublic

My JavaScript Learning Journey: Call Back Hell & Promises

1. What is Callback Hell?

Problems with Callback Hell

2. What is a Promise?

3. Promise States

Pending

Fulfilled

Rejected

4. Creating a Promise

5. Using resolve() and reject()

6. Handling Promises

then()

catch()

finally()

7. Promise Chaining

8. Error Propagation

9. Practical Promise Example

10. Key Takeaways

Conclusion

My JavaScript Learning Journey:Object-Oriented Programming (OOP) in JavaScript

1. Inheritance

2. Polymorphism

Example

3. Abstraction

Example

4. Static Members

5. Getters and Setters

6. Encapsulation Using Closures

Understanding `(strategy) => (pkg) => ...`

7. Private Fields (`#field`)

2. Prototype vs `proto`

`prototype`

`proto`