DEV Community: Alaa Samy

SSR, CSR, SSG, ISR — I Was Confused Too. Here's What Actually Matters.

Alaa Samy — Fri, 12 Jun 2026 20:48:19 +0000

I had a senior dev ask me "what rendering strategy would you use here?" and I said "...SSR?" with zero confidence. I'd heard the acronyms everywhere but never actually understood the tradeoffs.

This is the explanation I wish someone had given me back then — concrete, with real examples, no hand-waving.

The one question that unifies everything

Every rendering strategy is answering the same question: when and where does your HTML get built?

On your server, fresh for every request? → SSR
In the user's browser after downloading JavaScript? → CSR
Once at build time, before any user ever visits? → SSG
Built at deploy time but refreshed in the background? → ISR

That's it. Every performance, SEO, and cost tradeoff follows from this one decision.

Server-Side Rendering (SSR)

Your server builds the HTML fresh on every single request.

User clicks link
→ Request hits your server
→ Server queries the database
→ HTML is built with fresh data
→ Browser gets a complete page
→ User sees content instantly

This is the OG approach. PHP, Ruby on Rails, Django — all of these work this way by default.

// Next.js SSR
export async function getServerSideProps({ params }) {
  // This runs on the SERVER for every request
  const product = await db.products.findOne(params.id);
  const inventory = await db.inventory.getCurrent(params.id);

  return { props: { product, inventory } };
}

export default function ProductPage({ product, inventory }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p style={{ color: inventory.count === 0 ? 'red' : 'green' }}>
        {inventory.count === 0 ? 'Out of stock' : `${inventory.count} remaining`}
      </p>
    </div>
  );
}

Every page load hits your database. Inventory is always accurate. User always gets the real-time truth.

When SSR is the right call:

Search results (every query is different, can't cache)
User-specific pages ("your orders", account settings)
Real-time data (live auction prices, active game scores)
Anything where stale data causes real problems

The honest tradeoff: If 20,000 people hit the same page at the same time, your server handles 20,000 individual database queries. That's expensive infrastructure to get right, and you feel it in your cloud bill.

Client-Side Rendering (CSR)

Your server serves an almost empty HTML file. The browser downloads JavaScript, runs it, calls APIs, and builds the page itself.

User clicks link
→ Server sends: <div id="app"></div> + bundle.js
→ Browser downloads ~300KB of JavaScript
→ JavaScript parses and executes
→ API calls go out to fetch data
→ React renders the DOM
→ User finally sees something (2-4 seconds later)

This is the default behavior of Create React App. No framework magic, just a browser doing all the work.

// Pure CSR — everything happens in the browser
export default function Dashboard() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/dashboard-stats')
      .then(r => r.json())
      .then(data => {
        setData(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <DashboardSkeleton />;
  return <DashboardGrid data={data} />;
}
// No getServerSideProps. No getStaticProps. Just browser logic.

Server barely breaks a sweat — it just delivers a static file. The user's device does all the rendering work.

When CSR makes sense:

Behind a login (SEO doesn't matter if only authenticated users see it)
Highly interactive tools — Figma, Notion, Gmail-style apps
Real-time collaborative features
Admin dashboards and internal tooling

The honest tradeoff: Google crawls your page and sees <div id="app"></div>. No content. No SEO. That blank white flash while JavaScript loads is also genuinely bad UX on slow connections.

Static Site Generation (SSG)

You build every page once at deploy time. Ship the HTML files to a CDN. Done.

npm run build  (runs once at deploy)
→ Framework reads all your content
→ Generates one complete HTML file per page
→ Files go to CDN edge servers worldwide

User requests any page later
→ CDN returns pre-built HTML in ~50ms
→ No server touched. No database hit.

// Next.js SSG — data fetched at BUILD TIME, not request time
export async function getStaticPaths() {
  const posts = await getAllBlogPosts();
  return {
    paths: posts.map(p => ({ params: { slug: p.slug } })),
    fallback: false
  };
}

export async function getStaticProps({ params }) {
  const post = await getBlogPost(params.slug); // Runs ONCE at build
  return {
    props: { post }
    // No revalidate = frozen until next deploy
  };
}

export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Build once, serve for free, to millions of people. For a blog or documentation site, this is genuinely hard to beat.

When SSG is the right call:

Blogs and personal sites
Documentation sites
Marketing and landing pages
Content that changes weekly at most

The honest tradeoff: Content is frozen in time. Fix a typo? Redeploy. Have 10,000 products with prices that update hourly? You're rebuilding the entire site every hour — a 15-minute deploy cycle just to update a dollar amount. That's where SSG breaks down.

Incremental Static Regeneration (ISR)

This is the one that made me stop and re-read the docs.

ISR gives you SSG's speed (CDN delivery) but lets individual pages regenerate in the background without rebuilding everything. Fast serving AND fresh data.

Normal flow (page is cached):
User request → CDN returns pre-built HTML → ~50ms

When data changes:
Database update
→ Call revalidatePath('/products/123')
→ Server regenerates just that one page (~2 seconds)
→ Next user gets fresh HTML from CDN → still ~50ms

// Next.js ISR — static but refreshable
export async function getStaticProps({ params }) {
  const product = await getProduct(params.id);

  return {
    props: { product },
    revalidate: 3600 // Rebuild every hour OR trigger manually
  };
}

export async function getStaticPaths() {
  // Pre-build your 100 most visited products at deploy time
  const topProducts = await getTopProducts(100);
  return {
    paths: topProducts.map(p => ({ params: { id: p.id } })),
    fallback: 'blocking' // Others: generate on first request, cache after
  };
}

And the on-demand version — this is what makes it genuinely powerful:

// Called from your webhook when inventory changes
async function onInventoryUpdate(productId, newCount) {
  await db.inventory.update(productId, newCount);

  // Tell Next.js to regenerate this specific page only
  await fetch(`${process.env.SITE_URL}/api/revalidate`, {
    method: 'POST',
    body: JSON.stringify({ path: `/products/${productId}` }),
  });
}

// pages/api/revalidate.js
export default async function handler(req, res) {
  await res.revalidate(req.body.path);
  return res.json({ revalidated: true });
}

Inventory changes → webhook fires → that one product page regenerates → next visitor gets accurate stock count, still from CDN in 50ms.

When ISR is the sweet spot:

E-commerce with hundreds or thousands of product pages
News sites where articles get updates but aren't live
Real estate listings, job boards, classified ads
Any content with too many pages for full rebuilds but not so volatile it needs SSR

The honest tradeoff: The first visitor to an uncached page waits like SSR (1-2 seconds). And ISR isn't right if your data changes every few seconds — at that volatility, just use SSR.

Hybrid (What production apps actually do)

Nobody sane uses one strategy for their whole app. The smart move is matching each page to what it actually needs.

Here's a realistic e-commerce breakdown:

Route	Strategy	Why
`/`	SSG	Homepage barely changes
`/products/:id`	ISR	Regenerate when inventory updates
`/search?q=shoes`	SSR	Every query is unique, can't cache
`/blog/:slug`	SSG	Posts don't change after publish
`/account/orders`	SSR	User-specific, must be current
`/cart`	CSR	Client-side state, no server needed

In Next.js, this is just different files using different get*Props functions. One codebase, multiple strategies.

The cost profile ends up roughly:

75% of traffic → CDN (nearly free, instant)
20% → server (search results, auth pages)
5% → browser-rendered (cart, settings, dashboard)

Compared to all-SSR: dramatically cheaper, faster for users, and your server isn't the bottleneck anymore.

How I actually decide

When someone asks which strategy to use for a given page, here's the actual thought process:

Does SEO matter for this page?
No → CSR. Done.

Is the content personalized per user?
Yes → SSR. You can't cache personal data.

How often does the data actually change?
Every second → SSR
Every hour/day → ISR
Every week or less → SSG

How many pages are there?
Under 500 → SSG is easy, builds are fast
Over 500 → ISR, or your builds become a scheduling problem

For most content sites this shakes out to: SSG for marketing and docs, ISR for product and content pages, SSR for search and user-specific pages, CSR for authenticated dashboards.

Closing thought

The thing that finally clicked for me was stopping thinking about this as a framework choice and starting to think about it as a question about data.

When does your data change? Who sees it? How bad is it if a user sees something 10 minutes stale?

Answer those honestly and the right strategy usually picks itself. Next.js, Remix, Astro — they've all made hybrid rendering easy. You're not locked into one approach for your whole codebase.

SSR for things that must be live. SSG for things that never change. ISR for everything in between. CSR for pages behind a login where interactivity matters more than SEO.

Once that mental model is in place, the acronyms stop being confusing jargon and start being genuinely useful tools.

JavaScript Under the Hood: Understanding the Core Mechanics ✨

Alaa Samy — Sun, 09 Mar 2025 20:23:25 +0000

JavaScript is an incredible language that powers the web, yet many of us interact with it daily without understanding what’s happening behind the scenes. Let’s dive into the mechanics of how JavaScript works under the hood and uncover the magic that makes it so dynamic.

The Foundation: Single-Threaded Execution

At its core, JavaScript is a single-threaded, synchronous language, meaning it processes one task at a time, line by line, in a single thread.

Despite being single-threaded, JavaScript has asynchronous capabilities that make it appear multi-threaded.
This is possible through Web APIs provided by browsers (or Node.js in server environments), which allow operations to happen outside the main thread.

JavaScript's Runtime Anatomy:

Every JavaScript runtime consists of three key components that work together:

1- Call Stack:

A data structure that tracks the functions being executed. It follows the LIFO (Last In, First Out) principle—functions added last are removed first.
At the bottom of the stack is the Global Execution Context, the environment for global code, and as the functions are invoked, their execution contexts are stacked on top.

2- Memory Heap:

Stores objects, arrays, and other complex data structures in memory during program execution.
JavaScript uses automatic garbage collection to free memory when objects are no longer referenced.

3- Execution Context:

An execution context is a special environment created to handle the transformation and execution of JavaScript code. It contains the currently running code and everything that aids in its execution.
JavaScript has a Global Execution Context for the main script and Function Execution Contexts for each invoked function.

- Phases of Execution Context:

1- Memory Creation Phase:

Create the global object (window in browsers, global in Node.js).
Bind the this keyword to the global object.
Create the variable environment and process variable declarations:
- For var declarations: allocate memory and initialize with undefined (hoisting)
- For let and const declarations: allocate memory but leave in temporal dead zone (uninitialized)

2- Execution Phase:

Execute the code line by line.
Assign actual values to variables.
Create new execution contexts for function calls.

Asynchronous JavaScript: Event Loop & Queues

JavaScript's asynchronicity is managed through:

Task Queue (Macrotask Queue)

A FIFO (First In, First Out) queue that holds callbacks from asynchronous operations ready to be executed.

Microtask Queue

A higher-priority queue for promises and other microtasks that need to be processed before the next task.

Event Loop

The event loop is what makes asynchronous programming possible in JavaScript:
It continuously checks if the call stack is empty.
If the stack is empty, it looks at the microtask queue first.
After microtasks are processed, it checks the task queue.
It takes the first callback from the queue and pushes it onto the call stack.

Conclusion

Understanding JavaScript's inner workings helps you write more efficient code and debug complex issues. From its single-threaded nature to the event loop, and execution contexts, these fundamental concepts form the backbone of JavaScript's behavior.

By mastering these concepts, you'll gain deeper insights into how your JavaScript code is actually executed and be better equipped to write optimal, high-performance applications.

Happy Coding 😊

Clean Code in JavaScript: A Comprehensive Guide 🚀

Alaa Samy — Sat, 22 Feb 2025 20:03:29 +0000

Writing clean code is an essential skill for any developer. Clean code isn't just about making your code work—it's about making it work elegantly, efficiently, and in a way that other developers (including your future self) can easily understand and maintain. In this comprehensive guide, we'll explore the principles and best practices of writing clean JavaScript code.

What is Clean Code?

Clean code is code that is:

Readable: Easy to understand at a glance
Maintainable: Simple to modify and debug
Reusable: Can be repurposed for different scenarios
Testable: Easy to write unit tests for
Scalable: Can grow without becoming complex

1. Variables: The Building Blocks of Clean Code

- Use Meaningful Variable Names

Your variable names should clearly indicate their purpose and context.

// Bad
const d = new Date();
let u = getUser();
const arr = ['Apple', 'Banana', 'Orange'];

// Good
const currentDate = new Date();
let currentUser = getUser();
const fruitList = ['Apple', 'Banana', 'Orange'];

- Use Constants for Fixed Values

When a value won't change, use const instead of let or var.

// Bad
var API_ENDPOINT = 'https://api.example.com';
var MAX_ITEMS = 100;

// Good
const API_ENDPOINT = 'https://api.example.com';
const MAX_ITEMS = 100;

- Maintain Consistent Naming Convention

Use consistent naming patterns throughout your codebase.

// Bad - Inconsistent naming
getUserInfo()
getClientData()
getCustomerRecord()

// Good - Consistent naming
getUser()
updateUser()
deleteUser()

- Use Searchable Names

Make your variables and constants easily searchable.

// Bad
setTimeout(doSomething, 86400000);

// Good
const MILLISECONDS_IN_A_DAY = 86400000;
setTimeout(doSomething, MILLISECONDS_IN_A_DAY);

2. Objects: Organizing Data Cleanly

- Use Getters and Setters

Encapsulate object properties using getters and setters.

// Bad
class User {
  constructor(name) {
    this.name = name;
  }
}

// Good
class User {
  #name;  // Private field

  constructor(name) {
    this.#name = name;
  }

  getName() {
    return this.#name;
  }

  setName(name) {
    this.#name = name;
  }
}

- Implement Private Members

Use private fields and methods to protect object data.

class BankAccount {
  #balance = 0;  // Private field

  deposit(amount) {
    if (this.#validateAmount(amount)) {
      this.#balance += amount;
    }
  }

  #validateAmount(amount) {  // Private method
    return amount > 0;
  }
}

3. Functions: The Heart of Clean Code

- Keep Functions Small and Focused

Each function should do exactly one thing.

// Bad
function processUserData(user) {
  validateUser(user);
  updateUserInDatabase(user);
  sendWelcomeEmail(user);
  updateUIWithUserData(user);
}

// Good
function processUserData(user) {
  if (validateUser(user)) {
    saveUserData(user);
  }
}

function saveUserData(user) {
  updateUserInDatabase(user)
    .then(sendWelcomeEmail)
    .then(updateUIWithUserData);
}

- Limit Function Parameters

Use objects to pass multiple parameters.

// Bad
function createUser(firstName, lastName, email, age, location) {
  // ...
}

// Good
function createUser(userConfig) {
  const { firstName, lastName, email, age, location } = userConfig;
  // ...
}

- Use Descriptive Function Names

Function names should clearly describe what they do.

// Bad
function proc(data) { /* ... */ }

// Good
function processUserPayment(paymentData) { /* ... */ }

4. Comments: When and How to Use Them

- Write Self-Documenting Code

Your code should be clear enough that it doesn't need extensive comments.

// Bad
// Check if user is adult
if (user.age >= 18) { /* ... */ }

// Good
const isAdult = user.age >= 18;
if (isAdult) { /* ... */ }

- Use Comments for Complex Logic

Comments should explain "why" not "what".

// Bad
// Iterate through users
users.forEach(user => { /* ... */ });

// Good
// Filter inactive users before sending notifications to avoid
// overwhelming users who haven't logged in for 30+ days
const activeUsers = users.filter(user => user.lastLogin > thirtyDaysAgo);

5. Testing: Ensuring Code Quality

- Write Tests First (TDD)

Consider writing tests before implementing features.

// Example test
describe('User Authentication', () => {
  it('should successfully login with valid credentials', () => {
    const user = new User('test@example.com', 'password123');
    expect(user.login()).toBeTruthy();
  });
});

- Test Edge Cases

Always test boundary conditions and error cases.

describe('Array Utility', () => {
  it('should handle empty arrays', () => {
    expect(processArray([])).toEqual([]);
  });

  it('should handle null input', () => {
    expect(() => processArray(null)).toThrow('Invalid input');
  });
});

6. Modern JavaScript Features for Cleaner Code

- Use Optional Chaining

// Bad
const streetName = user && user.address && user.address.street;

// Good
const streetName = user?.address?.street;

- Utilize Destructuring

// Bad
const firstName = user.firstName;
const lastName = user.lastName;

// Good
const { firstName, lastName } = user;

- Implement Default Parameters

// Bad
function greet(name) {
  name = name || 'Guest';
  return `Hello, ${name}!`;
}

// Good
function greet(name = 'Guest') {
  return `Hello, ${name}!`;
}

Conclusion

Writing clean code is an ongoing journey of improvement. It's not just about following rules—it's about developing a mindset that values clarity, simplicity, and maintainability. Remember:

Write code for humans first, computers second
Keep your functions small and focused
Use meaningful names for variables and functions
Test thoroughly
Refactor regularly
Stay consistent with your coding style

By following these principles and continuously refining your approach, you'll write code that's not just functional, but truly professional and maintainable.

References

Understanding AI, Machine Learning, and Deep Learning: A Comprehensive Guide 🚀

Alaa Samy — Fri, 14 Feb 2025 22:36:32 +0000

Artificial Intelligence (AI) and its related fields are transforming industries, but understanding the basics can be overwhelming. Let’s break down key concepts to help you navigate this exciting world!

✔Artificial Intelligence: An Overview

The theory and development of computer systems able to perform tasks normally requiring human intelligence, These tasks include:

Visual perception
Speech recognition
Decision-making
Language translation
Problem-solving

✔Types of AI

1. Artificial narrow intelligence

Also known as Weak AI, it is designed to perform a narrow task (e.g., facial recognition or internet searches)
Examples: Siri, Alexa, chess programs

2. Artificial general intelligence

Also known as Strong AI or AGI (Artificial General Intelligence), it is a type of AI that has the capability to perform any intellectual task that a human can do.
Currently theoretical

3. Artificial super intelligence

This refers to AI that surpasses human intelligence in all aspects, including creativity and problem-solving.
Currently theoretical

✔Machine Learning: Foundation and Concepts

Machine Learning (ML) is a subset of AI that focuses on developing systems that can learn from and improve with experience. It enables computers to learn without explicit programming.

Data --> Training the machine --> Building a model --> Predict outcome

✔Common Parts of Machine Learning:

1. Datasets

Collections of data used for training and testing the machine learning models.

2. Algorithms

The mathematical models that make predictions or decisions based on the input data.

3. Model

The main component of a machine learning process and it's trained by using a machine learning algorithm

4. Features

The individual measurable properties or characteristics of the data used by the algorithms.

5. Labels

The outputs or results that the model is trying to predict or classify

6. Training

The process of teaching the model using a dataset so it can learn to make predictions.

7. Testing

Evaluating the model's performance on a separate dataset to ensure it generalizes well to new data.

✔Machine Learning Process

1. Defining the Objective

Clarify the business problem and goals (e.g., predicting sales, classifying images).
Determine success metrics (e.g., accuracy, speed, cost reduction).

2. Data Gathering

Collect relevant datasets from databases, APIs, or sensors.
Ensure data aligns with the problem (e.g., customer demographics for churn prediction).

3. Preparing Data

Clean data: Handle missing values, duplicates, and errors.
Preprocess: Normalize, encode categories, or split into training/testing sets.

4. Data Exploration (EDA)

Analyze patterns, correlations, and distributions using visualizations (e.g., histograms, heatmaps).
Identify outliers or biases that could skew results.

5. Building the Model

Select algorithms based on the problem (e.g., linear regression for predictions, CNN for images).
Train the model: Feed prepared data to learn patterns (e.g., using gradient descent).

6. Model Evaluation

Test performance on unseen data (test set).
Use metrics like accuracy, precision, recall, or F1-score.
Diagnose issues like overfitting (perfect on training data but fails on new data).

7. Predictions

Deploy the trained model to make real-world predictions (e.g., recommending products).
Monitor performance over time and retrain with new data as needed.

✔Types of Machine Learning

Machine learning can be classified into the following types:

1. Supervised Learning:

The model is trained on a labeled dataset, where the correct output is provided for each input.
Example algorithms include Linear Regression and Support Vector Machines.

2. Unsupervised Learning:

The model is trained on an unlabeled dataset and must find patterns or relationships within the data.
Example algorithms include K-Means Clustering and Principal Component Analysis (PCA).

3. Reinforcement Learning

The model learns by interacting with its environment and receiving feedback in the form of rewards or penalties.
Example algorithms include Q-Learning and Deep Q-Networks.

✔Common Machine Learning Problems and Classifications

1. Regression Problems

Supervised learning.
Predicting a continuous value.
Examples include predicting house prices or stock prices.
Algorithm -> Linear Regression

2. Classification Problems

Supervised learning
Categorizing data into discrete classes.
Examples include spam detection and image recognition.
Algorithm -> Logistic Regression

3. Clustering Problems

Unsupervised learning.
Grouping similar data points together.
Examples include customer segmentation and market research.
Algorithm -> K-means Clustering.

✔Deep Learning: Advanced Machine Learning

Deep Learning is a subset of machine learning that uses neural networks with many layers (hence "deep") to learn from data. It is particularly effective for tasks such as image and speech recognition, natural language processing, and playing complex games.
We use it whenever the data is very large and it has a lot of features and a lot of predictor variables.

✔Key Components of Deep Learning:

1. Neural Networks:

Composed of layers of interconnected neurons that process data.

2. Activation Functions:

Functions that determine the output of a neuron based on its input. Examples include ReLU (Rectified Linear Unit) and Sigmoid.

3. Training with Backpropagation:

A process of adjusting the weights of the network to minimize the error in predictions.

4. Convolutional Neural Networks (CNNs):

Specialized neural networks for processing grid-like data, such as images.

5. Recurrent Neural Networks (RNNs):

Specialized neural networks for sequential data, such as time series or text.

Conclusion ✨

The field of AI, particularly machine learning and deep learning, continues to evolve rapidly. Understanding these concepts and their relationships is crucial for anyone interested in artificial intelligence. Each component plays a vital role in developing intelligent systems that can learn from data and make informed decisions.

🛠️ SOLID Principles in JavaScript: Write Better Code with Examples

Alaa Samy — Sat, 08 Feb 2025 00:51:10 +0000

SOLID principles are a set of design guidelines that help you create maintainable, flexible, and scalable code.

Let’s break them down with JavaScript examples:

1. Single Responsibility Principle (SRP)

A class/function should have only one reason to change.

❌ Bad:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  saveToDatabase() {
    // Database logic here
  }

  sendEmail() {
    // Email logic here
  }
}

Problem: The User class handles both data management and email logic.

✅Good:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserRepository {
  saveToDatabase(user) { /* DB logic */ }
}

class EmailService {
  sendEmail(user) { /* Email logic */ }
}

Benefit: Each class has a single responsibility.

2. Open/Closed Principle (OCP)

Entities should be open for extension but closed for modification.

❌ Bad:

class Logger {
  logToConsole(message) {
    console.log(message);
  }

  logToFile(message) {
    // Write to file
  }
}

// To add a new logger (e.g., HTTP), you must modify the Logger class.

✅ Good:

// Use a strategy pattern to extend behavior
class Logger {
  log(message, loggerStrategy) {
    loggerStrategy(message);
  }
}

// Define strategies (extensions)
const consoleStrategy = (msg) => console.log(msg);
const fileStrategy = (msg) => writeToFile(msg);
const httpStrategy = (msg) => fetch('/log', { body: msg }); // New logger added without changing Logger class

// Usage:
const logger = new Logger();
logger.log("Error!", httpStrategy); // No need to modify Logger

Benefit: Extend functionality without altering existing code.

3. Liskov Substitution Principle (LSP)

Subclasses should replace their parent class without breaking functionality.

❌ Bad:

class Rectangle {
  setWidth(w) { this.width = w }
  setHeight(h) { this.height = h }
}

class Square extends Rectangle {
  setSize(size) { // Violates LSP
    this.width = size;
    this.height = size;
  }
}

function resizeShape(shape) {
  shape.setWidth(10);
  shape.setHeight(5); // Breaks for Square
}

✅ Good:

class Shape {
  area() { /* Abstract */ }
}

class Rectangle extends Shape { /* Implement area */ }
class Square extends Shape { /* Implement area */ }

Benefit: Subclasses don’t break parent class behavior.

4. Interface Segregation Principle (ISP)

Clients shouldn’t depend on interfaces they don’t use.

❌ Bad:

class Worker {
  work() { /* ... */ }
  eat() { /* ... */ }
}

// Robot forced to implement eat()
class Robot extends Worker {
  eat() { throw Error("Robots don't eat!"); }
}

✅ Good:

class Workable {
  work() { /* Interface */ }
}

class Eatable {
  eat() { /* Interface */ }
}

class Human implements Workable, Eatable { /* ... */ }
class Robot implements Workable { /* ... */ }

Benefit: Avoid bloated interfaces.

5. Dependency Inversion Principle (DIP)

Depend on abstractions (interfaces), not concretions (specific implementations).

❌ Bad:

class MySQLDatabase {
  save(data) { /* MySQL-specific */ }
}

class UserService {
  constructor() {
    this.db = new MySQLDatabase(); // Tight coupling
  }
}

✅ Good:

class Database {
  save(data) { /* Abstract */ }
}

class MySQLDatabase extends Database { /* ... */ }
class MongoDB extends Database { /* ... */ }

class UserService {
  constructor(database) {
    this.db = database; // Injected dependency
  }
}

Benefit: Decoupled, testable code.

Why SOLID Matters in JavaScript 🚀

Easier Maintenance: Changes affect fewer components.
Better Testability: Isolated logic is easier to test.
Flexible Architecture: Adapt to new requirements without rewrites.
Reusability: Components can be reused across projects.

Understanding Event Propagation in JavaScript 🌐

Alaa Samy — Wed, 29 Jan 2025 16:31:17 +0000

Event propagation describes how events travel through the DOM tree. Mastering it helps you control event behavior and write efficient code. Let’s dive in!

The 3 Phases of Event Propagation:

When an event (e.g., a click) occurs, it goes through three phases:

1. Capturing Phase:

The event travels down from the root (window → document → parent elements) to the target.

2. Target Phase:

The event reaches the element that triggered it (e.g., a clicked button).

3. Bubbling Phase:

The event bubbles up from the target back to the root (default behavior).

Example: Visualizing Propagation Phases:

HTML (nested elements):

<div id="grandparent">
  Grandparent
  <div id="parent">
    Parent
    <div id="child">Child</div>
  </div>
</div>

JavaScript:

const grandparent = document.getElementById('grandparent');
const parent = document.getElementById('parent');
const child = document.getElementById('child');

// Listen during the CAPTURING phase (third argument = true)
grandparent.addEventListener('click', () => {
  console.log('Capturing: Grandparent');
}, true);

parent.addEventListener('click', () => {
  console.log('Capturing: Parent');
}, true);

// Listen during the BUBBLING phase (default)
grandparent.addEventListener('click', () => {
  console.log('Bubbling: Grandparent');
});

parent.addEventListener('click', () => {
  console.log('Bubbling: Parent');
});

child.addEventListener('click', () => {
  console.log('Target: Child');
});

Output when clicking the child div:

Capturing: Grandparent  
Capturing: Parent  
Target: Child  
Bubbling: Parent  
Bubbling: Grandparent

Controlling Propagation

1. Stop Bubbling

Use event.stopPropagation() to halt the event’s upward travel:

child.addEventListener('click', (e) => {
  console.log('Child clicked!');
  e.stopPropagation(); // Stops the event from bubbling further
});

Result: Only Capturing: Grandparent, Capturing: Parent, and Target: Child will log.

2. Stop Immediate Actions

Use event.stopImmediatePropagation() to prevent other listeners on the same element from firing:

child.addEventListener('click', (e) => {
  console.log('First listener');
  e.stopImmediatePropagation();
});

child.addEventListener('click', () => {
  console.log('Second listener (never runs)');
});

Key Takeaways

Bubbling is the default phase (events propagate upward).
Capturing is rarely used but can be enabled with addEventListener(..., true).
Use event delegation to optimize performance for dynamic content.
Control propagation with stopPropagation() and stopImmediatePropagation().

Understanding event propagation unlocks precise control over user interactions! 🚀

Happy Coding 😀😀

Did you find this helpful? Follow me for more web development tips and tutorials!

Elevate Your JavaScript: A Deep Dive into Object-Oriented Programming✨

Alaa Samy — Mon, 26 Aug 2024 20:49:43 +0000

Object-Oriented Programming (OOP) is a powerful paradigm that has revolutionized the way we structure and organize code.

While JavaScript began as a prototype-based language, it has evolved to embrace OOP principles, particularly with the introduction of ES6 and subsequent updates.

This post delves into the core concepts of OOP in JavaScript, exploring how they can be implemented to create more robust, maintainable, and scalable applications.

We'll journey through the four pillars of OOP - Inheritance, Abstraction, Encapsulation and Polymorphism - demonstrating how each principle can be applied in JavaScript. Along the way, we'll examine real-world examples and discuss the pros and cons of each concept.

Whether you're a seasoned developer looking to refine your OOP skills in JavaScript or a newcomer eager to grasp these fundamental concepts, this guide will provide valuable insights into harnessing the power of OOP in your JavaScript projects.

1. Inheritance:

Inheritance allows a class to inherit properties and methods from another class. It promotes code reusability and establishes a relationship between a parent class and a child class.

class Vehicle {
  constructor(make, model) {
    this.make = make;
    this.model = model;
  }

  getInfo() {
    return `${this.make} ${this.model}`;
  }

  start() {
    return "The vehicle is starting...";
  }
}

class Car extends Vehicle {
  constructor(make, model, doors) {
    super(make, model);
    this.doors = doors;
  }

  getCarInfo() {
    return `${this.getInfo()} with ${this.doors} doors`;
  }
}

const myCar = new Car("Toyota", "Corolla", 4);
console.log(myCar.getCarInfo()); // Output: Toyota Corolla with 4 doors
console.log(myCar.start()); // Output: The vehicle is starting...

In this example, Car inherits from Vehicle, gaining access to its properties and methods.

Pros:

Code reusability: Child classes inherit properties and methods from parent classes.
Establishes a clear hierarchy between objects.
Allows for method overriding and extension.

Cons:

Can lead to tight coupling between parent and child classes.
Deep inheritance hierarchies can become complex and hard to maintain.

2. Abstraction

Abstraction involves hiding complex implementation details and showing only the necessary features of an object. In JavaScript, we can achieve abstraction using abstract classes (though not natively supported) and interfaces.

class Shape {
  constructor() {
    if (new.target === Shape) {
      throw new TypeError("Cannot instantiate abstract class");
    }
  }

  calculateArea() {
    throw new Error("Method 'calculateArea()' must be implemented.");
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  calculateArea() {
    return Math.PI * this.radius ** 2;
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  calculateArea() {
    return this.width * this.height;
  }
}

// const shape = new Shape(); // Throws TypeError
const circle = new Circle(5);
const rectangle = new Rectangle(4, 6);

console.log(circle.calculateArea()); // Output: 78.53981633974483
console.log(rectangle.calculateArea()); // Output: 24

In this example, Shape acts as an abstract class that can't be instantiated directly. It defines a common interface calculateArea that all subclasses must implement. This abstraction allows us to work with different shapes through a common interface without worrying about their specific implementations.

Pros:

Simplifies complex systems by hiding unnecessary details.
Improves code maintainability and reduces duplication.
Allows focusing on what an object does rather than how it does it.

Cons:

Can lead to over-simplification if not designed carefully.
Might introduce performance overhead in some cases.

3. Encapsulation

Encapsulation is the bundling of data and the methods that operate on that data within a single unit (object). In JavaScript, we can use closures and symbols to create private properties and methods.

class BankAccount {
  #balance = 0;  // Private field

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

  deposit(amount) {
    if (amount > 0) {
      this.#balance += amount;
      return true;
    }
    return false;
  }

  withdraw(amount) {
    if (amount > 0 && this.#balance >= amount) {
      this.#balance -= amount;
      return true;
    }
    return false;
  }

  getBalance() {
    return this.#balance;
  }
}

const account = new BankAccount('John Doe');
account.deposit(1000);
console.log(account.getBalance()); // Output: 1000
console.log(account.#balance); // SyntaxError: Private field '#balance' must be declared in an enclosing class

In this example, #balance is a private field that can't be accessed directly from outside the class.

Pros:

Data protection: Prevents unauthorized access to internal data.
Modularity: Bundles related functionality together.
Easier maintenance: Changes to internal implementation don't affect external code.

Cons:

Can be complex to implement in JavaScript due to lack of true private members.
Might lead to verbose code when creating getters and setters.

4. Polymorphism

Polymorphism allows objects of different classes to be treated as objects of a common superclass. In JavaScript, this can be achieved through method overriding.

class Animal {
  speak() {
    return "The animal makes a sound";
  }
}

class Dog extends Animal {
  speak() {
    return "The dog barks";
  }
}

class Cat extends Animal {
  speak() {
    return "The cat meows";
  }
}

const animals = [new Animal(), new Dog(), new Cat()];

animals.forEach(animal => {
  console.log(animal.speak());
});

// Output:
// The animal makes a sound
// The dog barks
// The cat meows

In this example, each class implements the speak method differently, demonstrating polymorphism.

Pros:

Flexibility: Objects of different types can be treated uniformly.
Extensibility: New classes can be added without changing existing code.
Simplifies code by allowing use of a single interface for different types.

Cons:

Can make code harder to debug if overused.
Might lead to performance overhead in some languages (less so in JavaScript).

As we've explored, Object-Oriented Programming in JavaScript offers a robust toolkit for creating structured, maintainable, and scalable code. The four pillars of OOP - Inheritance, Abstraction, Encapsulation and Polymorphism - each bring unique strengths to the table, allowing developers to model complex systems, protect data integrity, promote code reuse, and create flexible, extensible applications.

While implementing these principles in JavaScript may sometimes require creative approaches due to the language's unique characteristics, the benefits are clear. OOP can lead to more organized codebases, easier collaboration among team members, and increased adaptability to changing requirements.

However, it's important to remember that OOP is not a one-size-fits-all solution. Each project may require a different balance of these principles, and in some cases, other paradigms might be more suitable. The key is to understand these concepts thoroughly and apply them judiciously, always keeping in mind the specific needs of your project and team.

Happy Coding 😄

Mastering Jest in Next.js: A Complete Guide for App Router and TypeScript 🚀

Alaa Samy — Fri, 23 Aug 2024 19:50:59 +0000

Dive into the world of modern web testing with this comprehensive guide on integrating Jest into your Next.js project, and learn how to set up a robust testing environment for your App Router-based application using TypeScript.
We'll walk you through installing essential dependencies, configuring Jest for Next.js, and writing your first test.

Perfect for developers looking to enhance their Next.js applications with reliable, type-safe testing practices. Boost your code quality and confidence with Jest and React Testing Library in your Next.js TypeScript projects.

To start working with Jest in a Next.js project you need to follow these steps:

1. Install dependencies:

npm install --save-dev jest @types/jest @testing-library/react @testing-library/jest-dom jest-environment-jsdom

Let's break down this npm installation command and explain each package:

--save-dev: This flag saves these packages as development dependencies in your package.json. It means these packages are only needed for development and testing, not for production.
jest: This is the core Jest library, a popular JavaScript testing framework developed by Facebook. It provides the test runner and assertion library.
@types/jest: This package provides TypeScript type definitions for Jest. It enables better autocomplete and type-checking when writing tests in TypeScript.
@testing-library/react: This is a set of helpers that allow you to test React components without relying on their implementation details, it encourages better testing practices.
@testing-library/jest-dom: This package extends Jest with custom matchers for asserting on DOM nodes, making it easier to test the state of the DOM in your tests.
jest-environment-jsdom: This package provides a simulated DOM environment for Jest tests. It's necessary when testing React components that interact with the DOM, as Next.js components often do.

2. Create a Jest configuration file (jest.config.js) in your project root:

const nextJest = require('next/jest')

const createJestConfig = nextJest({
  dir: './',
})

const customJestConfig = {
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jest-environment-jsdom',
}

module.exports = createJestConfig(customJestConfig)

This code configures Jest to work with Next.js. Let's break it down line by line:

const nextJest = require('next/jest'): This imports the Next.js Jest configuration function. Next.js provides this to help set up Jest in a way that's compatible with Next.js projects.
const createJestConfig = nextJest({ dir: './', }): This creates a Jest configuration function specific to your Next.js project, and dir: './' option tells Next.js that the root directory of your project is the current directory.
const customJestConfig = { ... }: This object contains custom Jest configuration options.
setupFilesAfterEnv: ['<rootDir>/jest.setup.js']: This specifies files to run after the Jest environment is set up but before tests are run, and it points to jest.setup.js file in your root directory, where you can add global setup code for your tests.
testEnvironment: 'jest-environment-jsdom': This sets the test environment to jsdom, which simulates a DOM environment in Node.js, and it's necessary for testing React components that interact with the DOM.
module.exports = createJestConfig(customJestConfig): This exports the final Jest configuration, it calls createJestConfig with your custom config, which merges your settings with Next.js's default Jest settings.

3. Create a jest.setup.js file in your project root:

import '@testing-library/jest-dom'

4. Update your package.json to include Jest scripts:

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch"
}

These scripts provide two different ways to run your tests:

The test script is for running all tests once, which is ideal for CI/CD or before committing changes.
The test:watch script is for development, allowing you to see test results update in real-time as you code.

5. Create a __tests__ folder in your project root or alongside your components

6. Write your first test (e.g., Home.test.tsx):

import '@testing-library/jest-dom'
import { render, screen } from '@testing-library/react'
import Home from '../app/page'

describe('Home', () => {
    it('renders a heading', () => {
        render(<Home />)
        const heading = screen.getAllByRole('heading', { level: 2 })
        expect(heading).toHaveLength(4);
    })
})

7. Run your tests:

npm test

This setup should get you started on using Jest in a Next.js project.

Incorporating Jest into your Next.js project with TypeScript marks a significant step towards robust, maintainable code. By following this guide, you've laid the groundwork for a comprehensive testing strategy that will serve you well as your application grows.

By prioritizing testing in your development workflow, you're not just catching bugs early—you're also documenting your code's behavior and making it easier for your team to collaborate and refactor with confidence.

Happy testing 😀😀

What is JavaScript?

Alaa Samy — Fri, 15 Mar 2024 12:18:45 +0000

Javascript is a programming language that can help to create dynamic pages and make it more interactive.
Javascript is described as prototype-based, high-level, multiparadigm, single-threaded, dynamic typing, and garbage-collected.

✔JavaScript is prototype-based

It means that JavaScript can create objects without defining its class

function Car (){
  this.color = 'red',
  this.wheels = 4
}

const firstCar = new Car();

✔JavaScript is high-level

JavaScript is a high-level language because it's easy to understand, and it doesn't have to manage resources at all or deal with hardware and operating system.

✔JavaScript is multiparadigm

JavaScript is very dynamic and it supports various types of programming styles such as:

1. Imperative programming paradigm

It's a paradigm that focuses on how the program should perform, through a set of instructions to follow, and the computer does what you want like:

Object-oriented programming
Procedural code

const arr = [1, 2, 3, 4, 5]
const result = []

for (let i=0; i < arr.length; i++){
   result.push(arr[i] * 3)
}

console.log(result)
// [3, 6, 9, 12, 15]

2. Declarative programming paradigm

It's a paradigm that focuses on what the program should accomplish without specifying the instructions on how to solve the problem like:

Logic language
Functional programming
Domain-specific language

const arr= [1, 2, 3, 4, 5]
const result = arr.map(num => num * 3)

console.log(result) 
// [3, 6, 9, 12, 15]

✔JavaScript is single-threaded

It means that javascript can only execute one task, and each task must done and completed before the other task starts

function First() {
  console.log('First function');
}
function Second() {
  console.log('Second function');
}

First();
Second();
// First function
// Second function

✔JavaScript is dynamic typing

JavaScript interpreter assigns a type to a variable at a run time based on the value assigned to that variable

✔JavaScript is garbage-collected

The Garbage collector is an algorithm inside javascript engines, it automatically frees up memory by removing unused objects, which can help to prevent memory leaks.

I hope you find something useful in this article

😊Happy coding!

JavaScript Design Patterns

Alaa Samy — Wed, 13 Mar 2024 19:35:03 +0000

Design patterns are advanced object-oriented solutions, used to recurring problems in software design.

Design patterns have many categorizations, but the most popular one is:

⚡- Creational Design Patterns:

It deals with object or class creation mechanisms, and it solves design problems when creating objects.
1- Factory Methods
2- Builder
3- Abstract Factory
4- Prototype
5- Singleton

⚡- Structural Design Patterns:

It assembles objects and classes into a larger structure, making sure that this structure is flexible and efficient, and that if change happens to part of a system it doesn’t affect the system entirely.
1- Adapter
2- Composite
3- Decorator
4- Bridge
5- Flyweight
6- Facade
7- Proxy

⚡- Behavioral Design Patterns:

It’s responsible for improving the communication between disparate objects and classes in a system.
1- Command
2- Interpreter
3- Iterator
4- Memento
5- Observer
6- Template Method
7- Chain of Responsibility
8- Meditor
9- State
10- Strategy
11- Visitor