Forem: Selasie Sepenu

How JavaScript Executes Code: Understanding Execution Context and the Call Stack

Selasie Sepenu — Sun, 11 May 2025 21:54:37 +0000

JavaScript is a single-threaded, synchronous programming language at its core, but it handles asynchronous operations through clever mechanisms like the event loop. To truly understand how JavaScript works under the hood, you need to grasp two fundamental concepts: execution context and the call stack.

The JavaScript Execution Context

An execution context is an abstract concept that holds information about the environment where JavaScript code is executed. There are three types of execution contexts in JavaScript:

Global Execution Context: Created when the JavaScript engine first starts executing your code
Function Execution Context: Created whenever a function is invoked
Eval Execution Context: Created inside an eval function (rarely used)

Each execution context has two phases:

Creation phase
Execution phase

Creation Phase

During the creation phase, the JavaScript engine:

Creates the Variable Object (VO) which contains:
- Function arguments (for function contexts)
- Inner variable declarations (but not their assignments)
- Function declarations
Creates the scope chain
Determines the value of this

This explains hoisting - why you can use functions before they're declared in your code, but variables will be undefined until their actual assignment.

Execution Phase

During the execution phase:

The code is executed line by line
Variables are assigned values
Functions are executed when called

The Call Stack

The call stack is a data structure that keeps track of function calls in your program. It works on the LIFO principle (Last In, First Out).

Here's how it works:

When the JavaScript engine starts executing your script, it creates a global execution context and pushes it onto the call stack
When a function is called, a new execution context for that function is created and pushed onto the stack
When a function returns, its execution context is popped off the stack
The engine continues executing the current context (now the one below in the stack)

function first() {
  console.log("Inside first function");
  second();
  console.log("Back to first function");
}

function second() {
  console.log("Inside second function");
  third();
  console.log("Back to second function");
}

function third() {
  console.log("Inside third function");
}

first();
console.log("Global execution");

The call stack for this code would look like:

third() is pushed when called from second()
second() is pushed when called from first()
first() is pushed when called from global
Global execution context is always at the bottom

When third() completes, it's popped off, then second(), then first(), and finally the global context remains until the program ends.

Visualizing the Process

Let's examine a concrete example:

var a = 2;

function square(num) {
  var result = num * num;
  return result;
}

var squareOfTwo = square(a);
console.log(squareOfTwo);

Execution steps:

Global Execution Context Creation:
- Creates variable object with:
  - a: undefined
  - square: <function>
  - squareOfTwo: undefined
- Sets up scope chain
- Determines this (window in browsers)
Global Execution:
- Assigns a = 2
- Reaches square(a) call:
  - Creates new execution context for square
  - Creation phase for square:
  - num: 2 (from argument)
  - result: undefined
  - Execution phase for square:
  - Calculates result = 2 * 2
  - Returns 4
  - square context is popped from call stack
- Assigns return value to squareOfTwo = 4
- Calls console.log(4)
  - Creates context for console.log
  - Executes it
  - Pops it from stack
Program completes, global context is popped

Handling Asynchronous Code

While the call stack handles synchronous operations, asynchronous operations (like setTimeout, promises, or AJAX calls) are handled by the browser APIs and the event queue. The event loop constantly checks if the call stack is empty, and if so, pushes the next callback from the queue to the stack.

This separation is why JavaScript can handle asynchronous operations despite being single-threaded.

Key Takeaways

JavaScript executes code by creating and managing execution contexts
Each context has creation and execution phases
The call stack tracks the execution order of functions
Understanding these concepts explains hoisting, scope, and closure behaviors
Asynchronous operations are handled outside the main call stack

I believe this has been both helpful and insightful to all Javascript developers.Until some other time, happy coding🎉🎉

How Engineering Saved My Friend’s Blog $15 a Month—And Why It Matters

Selasie Sepenu — Sun, 16 Mar 2025 23:48:58 +0000

In the world of software development, there’s a saying: “Why buy when you can build?” While this isn’t always the best advice (sometimes reinventing the wheel is a waste of time), there are moments when rolling up your sleeves and building a custom solution can lead to significant savings, better control, and a deeper understanding of your system. This is the story of how I helped my friend save $15 a month by engineering a feature for their blog—and why it’s a win worth celebrating.

The Problem: Real-Time Comments on a Budget

Having built out the basic functionality for my friend's blog, she wanted to include a comments section where readers could engage with their content. Since we had already used Sanity.io to this point, we initially considered using it again for this feature. However, Sanity offers a real-time comments feature, but it comes at a cost: $15 per month. While $15 might not seem like much, over time, it adds up. For a small blog, every dollar counts, and we wanted to avoid recurring costs wherever possible.

But the real question was: Could we build this feature ourselves? And if so, would it be worth the effort?

The Solution: Building a Custom Real-Time Comments System

Instead of paying for Sanity’s real-time comments feature, I decided to engineer a custom solution using Supabase, an open-source alternative to Firebase. Here’s how I did it:

Database Setup:
- I created a comments table in Supabase to store all comments. Each comment included fields like name, email, comment, post_id, and created_at.
Real-Time Updates:
- Supabase’s real-time functionality allowed me to listen for new comments and update the UI dynamically. This meant readers could see new comments appear instantly without refreshing the page.
Custom API:
- I built a simple API endpoint to handle comment submissions. When a reader submits a comment, it’s saved to the Supabase database, and the real-time subscription updates the UI.
Cost Savings:
- Supabase’s free tier was more than enough for our needs, meaning we paid $0 for this feature. Over time, this saves my friend $180 per year—and potentially thousands over the lifetime of the blog.

The Engineering Advantage

Building this feature wasn’t just about saving money. It was about flexibility, control, and learning. Here’s why engineering this solution was worth it:

Total Control:
- By building the feature ourselves, we had complete control over how it worked. We could customize the UI, add new features (like comment moderation), and optimize performance.
No Vendor Lock-In:
- Relying on a third-party service like Sanity’s real-time comments feature would have tied us to their platform. By using Supabase, we retained the freedom to switch databases or even build our own backend in the future.
Learning Opportunity:
- Building this feature from scratch gave me a deeper understanding of real-time systems, database design, and API integration. These skills are invaluable and can be applied to future projects.
Cost Efficiency:
- While $15 a month might seem trivial, it’s a recurring cost that adds up over time. By building the feature ourselves, we saved $180 per year—money that can now be invested in other areas of the blog.

The Bigger Picture: Why This Matters

This isn’t just a story about saving $15 a month. It’s a story about empowerment through engineering. In a world where SaaS solutions are often the default choice, it’s easy to forget the value of building things yourself. Here’s why this approach matters:

Sustainability:
- Recurring costs can quickly add up, especially for small projects or startups. By building custom solutions, we can keep expenses low and reinvest savings into growth.
Customization:
- Off-the-shelf solutions often come with limitations. Building our own feature allows us to tailor it to our exact needs.
Skill Development:
- Every project is an opportunity to learn. By building this feature, I gained valuable experience that will benefit me in future endeavors.
Independence:
- Relying on third-party services can be risky. By building our own solutions, we reduce dependency on external providers and gain more control over our product.

The Takeaway: Build vs. Buy

So, should we always build instead of buy? Not necessarily. There are times when using a third-party service makes sense—especially when time is limited or the feature is highly complex. But for small, manageable features like a comments section, building our own solution can be a smart move.

In this case, engineering the real-time comments feature saved my friend $15 a month, but more importantly, it gave us control, flexibility, and confidence in our ability to solve problems. And that’s worth far more than $15.

Final Thoughts

In the end, this project was a reminder that engineering is about more than just writing code. It’s about solving problems, making smart decisions, and creating value. By building our own real-time comments system, we not only saved money but also gained a deeper appreciation for the power of engineering.

So, the next time we’re faced with a decision to build or buy, we’ll ask ourselves: Can we engineer a solution that’s better, cheaper, and more aligned with our goals? If the answer is yes, we’ll roll up our sleeves and start building. The rewards—both financial and personal—are well worth it.

What do you think? Have you ever built a custom solution to save money or gain more control? Share your story in the comments below! (And yes, the comments are real-time, thanks to our custom-built system. 😉)

Hey everyone. Please do well to check out my latest post.

Selasie Sepenu — Tue, 11 Mar 2025 14:15:45 +0000

Building a Global Modal System in Next.js: A Deep Dive into Client-Side State Management

Selasie Sepenu ・ Mar 11

#programming #webdev #typescript #nextjs

Building a Global Modal System in Next.js: A Deep Dive into Client-Side State Management

Selasie Sepenu — Tue, 11 Mar 2025 14:14:54 +0000

Creating a seamless and reusable modal system is a common requirement in modern web development. Modals are used for everything from user authentication to notifications, and they need to be accessible, performant, and easy to manage across an application. However, implementing a global modal system in a framework like Next.js—especially with the introduction of Server Components—can be tricky. In this article, I’ll walk you through my experience building a global modal system using Zustand for state management, React Portals for rendering, and the challenges I faced along the way.

The Problem: A Global Modal System

The goal was simple: create a modal that could be triggered from anywhere in the application and would render consistently across all pages. The modal needed to:

Be Global: Accessible from any component or page.
Be Performant: Avoid unnecessary re-renders.
Work with Server Components: Next.js 13+ utilizes Server Components, which complicated things because React hooks (like Zustand’s useStore) can only be used in Client Components.

At first glance, this seemed straightforward. However, as I dove deeper, I encountered several challenges that required creative solutions.

The Initial Approach: Wrapping the Application

My first thought was to wrap the entire application in a ClientWrapper component that would handle the modal logic. This wrapper would use Zustand to manage the modal’s state and conditionally render the modal based on that state.

The Code

Here’s what the initial implementation looked like:

"use client";
import { useModalStore } from "@/store/store";
import WaitlistModal from "@/components/ui/Modal";
import { ReactNode } from "react";

interface ClientWrapperProps {
  children: ReactNode;
}

export default function ClientWrapper({ children }: ClientWrapperProps) {
  const { isModalOpen, closeModal } = useModalStore();

  return (
    <>
      {children}
      <WaitlistModal isOpen={isModalOpen} onClose={closeModal} />
    </>
  );
}

The Problem

While this approach worked in theory, it introduced a critical issue: unreachable code. When the children were rendered first, the WaitlistModal became unreachable, and vice versa. This was due to the way React handles component rendering and the order of operations.

The Solution: React Portals

To solve the unreachable code issue, I turned to React Portals. Portals allow you to render a component outside its parent DOM hierarchy, which is perfect for modals that need to appear above all other content.

What Are Portals?

Portals are a feature in React that let you render a component into a DOM node outside its parent component. This is particularly useful for modals, tooltips, and other overlay components that need to break out of their container.

Implementing Portals

I created a Portal component to handle the rendering logic:

"use client";
import { useEffect, useState } from "react";
import { createPortal } from "react-dom";

interface PortalProps {
  children: React.ReactNode;
}

export default function Portal({ children }: PortalProps) {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
    return () => setMounted(false);
  }, []);

  if (!mounted) return null;

  return createPortal(children, document.body);
}

Updating the Modal Component

Next, I wrapped the WaitlistModal component with the Portal component:

"use client";
import { motion } from "framer-motion";
import Portal from "./Portal";

interface WaitlistModalProps {
  isOpen: boolean;
  onClose: () => void;
}

const WaitlistModal = ({ isOpen, onClose }: WaitlistModalProps) => {
  if (!isOpen) return null;

  return (
    <Portal>
      <motion.div
        initial={{ opacity: 0 }}
        animate={{ opacity: 1 }}
        exit={{ opacity: 0 }}
        className="fixed inset-0 bg-black bg-opacity-50 flex justify-center items-center z-50"
        onClick={onClose}
      >
        <motion.div
          initial={{ y: -50, opacity: 0 }}
          animate={{ y: 0, opacity: 1 }}
          exit={{ y: -50, opacity: 0 }}
          className="bg-white rounded-lg p-8 w-full max-w-md relative z-60"
          onClick={(e) => e.stopPropagation()}
        >
          {/* Modal content */}
        </motion.div>
      </motion.div>
    </Portal>
  );
};

export default WaitlistModal;

Why Portals Work

Portals solved the unreachable code issue by rendering the modal outside the main component tree. This ensured that the modal would always appear above other content, regardless of where it was triggered.

The Next Challenge: Server Components

With the modal working as expected, I encountered a new challenge: Server Components. Next.js 13+ utilizes Server Components, which are rendered on the server and cannot use React hooks like useState or useStore.

The Error

When I tried to use useModalStore in the app/layout.tsx file, I got the following error:

Error: useSyncExternalStore only works in Client Components. Add the "use client" directive at the top of the file to use it.

The Solution: A Modal Provider

To resolve this, I created a ModalProvider component that would handle the modal logic and render the WaitlistModal. This component would be a Client Component, ensuring that useModalStore could be used without issues.

ModalProvider.tsx

"use client";
import { useModalStore } from "@/store/store";
import WaitlistModal from "@/components/ui/Modal";

export default function ModalProvider() {
  const { isModalOpen, closeModal } = useModalStore();

  return <WaitlistModal isOpen={isModalOpen} onClose={closeModal} />;
}

Updating the Layout

I then included the ModalProvider in the app/layout.tsx file:

import { Inter } from "next/font/google";
import "./globals.css";
import ModalProvider from "@/components/ModalProvider";

const inter = Inter({ subsets: ["latin"] });

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body className={inter.className}>
        {children}
        <ModalProvider />
      </body>
    </html>
  );
}

The Final Result

With these changes, the global modal system was fully functional:

Global Access: The modal could be triggered from any component using the useModalStore hook.
Performant: The modal was rendered only when needed, avoiding unnecessary re-renders.
Server-Safe: The modal logic was handled in a Client Component, ensuring compatibility with Server Components.

Key Takeaways

Portals Are Powerful: React Portals are an excellent tool for rendering components outside their parent hierarchy, making them ideal for modals and overlays.
Separate Client and Server Logic: When working with Next.js Server Components, it’s essential to separate client-side logic into dedicated Client Components.
State Management Matters: Zustand provided a simple and effective way to manage global state, but it’s crucial to use it correctly in a Server Components architecture.

Conclusion

Building a global modal system in Next.js was a challenging but rewarding experience. By leveraging React Portals, Zustand, and a clear separation of client and server logic, I was able to create a performant and reusable solution. If you’re working on a similar project, I hope this article provides valuable insights and helps you avoid common pitfalls.

Happy coding! 🚀

Demystifying Big O Notation: A Guide For Software Engineers

Selasie Sepenu — Fri, 26 Jul 2024 15:21:08 +0000

As engineers,we constantly strive to write efficient code.But how do we measure and communicate efficiency in our algorithms? This is where the Big O notation comes in. Big O notation is a mathematical concept used to describe the performance of an algorithm in terms of time and space complexity. In this article, we will break down Big O notation, make it accessible and understandable for engineers of all levels.

What is Big O Notation?

Big O notation provides a high-level understanding of the efficiency of an algorithm. It describes the upper bound of the algorithms running time or space requirement in the worstcase scenario. This allows us to compare different algorithms and determine which one is more efficient as the input size grows.

Why is Big O notation important?

Understanding Big O notation crucial for several reasons:
1)Performance Optimization: It allows developers to choose the most efficient algorithm for a given problem.
2)Scalability: It ensures that the chosen algorithm can handle larger inputs without degrading performance significantly.
3)Algorithm Comparison: It allows developers to choose the most efficient algorithm for a given problem.

Common Big O Notations

O(1)-Constant Time: The algorithms performance remains constant, regardless of input size.
Example: Accessing an array by index.

O(logn): The algorithm's performance increases logarithmically with the input size.
Example: Binary Search

O(n)-Linear Time: The algorithm's performance increases linearlty with input size.
Example: Iterating through an array.

O(nlogn)-Linearithmic Time: The algorithms performance increases linearly and logarithmically with the input size.
Example: Merge Sort

O(n^2)-Quadratic Time: The algorithm's performance increases quadratically with input size.
Exmaple: Bubble Sort

0(2^n) - Exponential Time: The algortithm's performance doubles with each addtional input.
Example: Recursive Fibonacci Calculation

0(n!) -Factorial Time: The algorithm's performance increases with the input size.
Example: Solving the travelling salesman problem using brute force.

Big O notation is an essential tool for engineers to evaluate and optimize the efficiency of their algorithms.By understanding types of Big O notations and their implications, you can write more efficient code and make the better algorithmic choices. In the next article, we'll dive deeper into pratical examples and explore the how to analyze the Big O notation of real-world examples.