Popcorn Movies and TV

Synchronous vs Asynchronous JavaScript

Pratham — Sun, 10 May 2026 10:53:26 +0000

Why JavaScript doesn't just wait around — and how that changes everything about how you write code.

Let me tell you about the moment asynchronous JavaScript broke my brain.

I wrote this code, fully expecting it to print in order:

console.log("First");
setTimeout(() => console.log("Second"), 0);
console.log("Third");

I expected: First → Second → Third.

I got: First → Third → Second.

Zero milliseconds of delay, and "Second" still printed last. I stared at my screen thinking JavaScript was broken. It wasn't. I just didn't understand how JavaScript handles time.

This is the story of synchronous vs asynchronous code, and once you get it, a massive amount of JavaScript behavior suddenly makes sense. Let me walk you through it the way it finally clicked for me in the ChaiCode Web Dev Cohort 2026.

What Does Synchronous Code Mean?

Synchronous means "one thing at a time, in order." Each line waits for the previous line to finish before it starts.

Think of it like a single-lane road. Only one car can pass at a time. If the car in front stops, everyone behind it waits.

console.log("Step 1: Wake up");
console.log("Step 2: Brush teeth");
console.log("Step 3: Make coffee");
console.log("Step 4: Start coding");

Output:

Step 1: Wake up
Step 2: Brush teeth
Step 3: Make coffee
Step 4: Start coding

Each line runs, finishes, and then the next one starts. Predictable. Linear. No surprises.

Synchronous Execution Timeline

Time →
─────────────────────────────────────────────────

  Step 1       Step 2       Step 3       Step 4
  ┌─────┐     ┌─────┐     ┌─────┐     ┌─────┐
  │Wake │ ──→ │Brush│ ──→ │Make │ ──→ │Code │
  │ up  │     │teeth│     │coffee│    │     │
  └─────┘     └─────┘     └─────┘     └─────┘

Each task COMPLETES before the next one STARTS.
Nothing runs in parallel.

This is how JavaScript works by default. It's a single-threaded language — it has one call stack, one thread, and it processes one operation at a time.

The Problem: Blocking Code

Synchronous execution works perfectly until you hit a task that takes time. Not a millisecond — real time. Seconds. Maybe longer.

Real-World Example: Waiting for Data

Imagine you're building a web app. You need to:

Show a loading message
Fetch user data from an API (takes 2–3 seconds)
Display the user data
Show other page content

If everything is synchronous:

Time →
─────────────────────────────────────────────────

  Show        Fetch data       Display      Show
  loading     (waiting...)     user data    content
  ┌─────┐    ┌────────────────┐ ┌─────┐    ┌─────┐
  │     │ ──→│  2-3 SECONDS   │→│     │ ──→│     │
  │     │    │  EVERYTHING    │ │     │    │     │
  │     │    │  IS FROZEN     │ │     │    │     │
  └─────┘    └────────────────┘ └─────┘    └─────┘
                     ↑
              BLOCKING! 🚫
              Nothing else can run while waiting.

The entire page freezes. The user can't scroll, can't click, can't do anything. The UI is unresponsive for 2–3 seconds. That's a terrible user experience.

This is called blocking — one slow task blocks everything else from running.

Code Example of Blocking

console.log("Page is loading...");

// Simulating a blocking operation (DON'T do this in real code)
const start = Date.now();
while (Date.now() - start < 3000) {
  // Busy-wait for 3 seconds — blocks EVERYTHING
}

console.log("Data loaded!");
console.log("Showing rest of the page");

During those 3 seconds, JavaScript can't do anything else. No animations, no button clicks, no rendering. The browser might even show the "page unresponsive" dialog.

What Does Asynchronous Code Mean?

Asynchronous means "start a task, move on, and come back to it when it's done." You don't wait — you continue doing other things.

Think of it like ordering food at a restaurant. You place your order and then continue your conversation while the kitchen prepares the food. When the food is ready, the waiter brings it to you. You didn't freeze in silence staring at the kitchen door for 20 minutes.

SYNCHRONOUS (blocking):
  You order → you STARE at the kitchen → food arrives → you eat → you talk

ASYNCHRONOUS (non-blocking):
  You order → you TALK while kitchen cooks → food arrives → you eat
  (you didn't waste time waiting)

In JavaScript, asynchronous code lets you say: "Start this task. I'll keep running other code. Call me when you're done."

Why JavaScript Needs Asynchronous Behavior

JavaScript runs in the browser. Browsers need to do a lot at the same time:

Respond to user clicks
Render animations smoothly (60 fps)
Fetch data from APIs
Run your JavaScript code
Update the DOM

If JavaScript blocked on every slow operation, the browser would freeze constantly. That's unacceptable for a web environment. So JavaScript uses an asynchronous model to handle time-consuming tasks without freezing the main thread.

The slow tasks get offloaded. While they're being processed elsewhere (by the browser, the network, the filesystem), JavaScript keeps running the rest of your code. When the slow task finishes, a callback is queued up and JavaScript processes it when it's free.

Asynchronous Examples: Timers and API Calls

`setTimeout` — The Simplest Async Example

console.log("Start");

setTimeout(() => {
  console.log("This runs after 2 seconds");
}, 2000);

console.log("End");

Output:

Start
End
This runs after 2 seconds

Wait — "End" printed before the timeout message, even though the timeout line comes first in the code! Here's why:

console.log("Start") runs immediately.
setTimeout registers the callback and says "run this after 2 seconds." JavaScript doesn't wait — it moves on.
console.log("End") runs immediately.
After 2 seconds, the callback fires: console.log("This runs after 2 seconds").

The Zero-Delay Mystery (Explained!)

Remember my opening example?

console.log("First");
setTimeout(() => console.log("Second"), 0);
console.log("Third");

Output: First → Third → Second.

Even with 0 milliseconds delay, the callback doesn't run immediately. It gets placed in the task queue and only executes after all synchronous code has finished. JavaScript always finishes what's on its plate before checking the queue.

`setInterval` — Repeat at Intervals

let count = 0;

const timer = setInterval(() => {
  count++;
  console.log(`Tick ${count}`);

  if (count === 3) {
    clearInterval(timer);
    console.log("Timer stopped.");
  }
}, 1000);

console.log("Timer started — code continues running...");

Output:

Timer started — code continues running...
Tick 1       (after 1 second)
Tick 2       (after 2 seconds)
Tick 3       (after 3 seconds)
Timer stopped.

The code after setInterval runs immediately. The ticks happen in the background.

API Calls with `fetch` (Preview)

console.log("Fetching user data...");

fetch("https://jsonplaceholder.typicode.com/users/1")
  .then((response) => response.json())
  .then((user) => {
    console.log(`User: ${user.name}`);
  });

console.log("This runs while fetch is working...");

Output:

Fetching user data...
This runs while fetch is working...
User: Leanne Graham       (arrives later)

fetch doesn't block. It fires the request, and JavaScript keeps going. When the response comes back, the .then() callback handles it.

The Asynchronous Task Queue Concept

Here's the mental model that ties everything together:

┌──────────────────────────────────────────────────────┐
│                   Call Stack                          │
│           (synchronous code runs here)               │
│                                                      │
│   console.log("Start")  ← runs immediately           │
│   setTimeout(cb, 2000)  ← registers callback, moves on│
│   console.log("End")    ← runs immediately           │
│                                                      │
└──────────────────────────┬───────────────────────────┘
                           │
              "Is the call stack empty?"
                           │
                    YES ↓  NO → keep running
                           │
┌──────────────────────────┴───────────────────────────┐
│                   Task Queue                          │
│        (async callbacks wait here)                   │
│                                                      │
│   [callback from setTimeout]  ← waiting...           │
│                                                      │
│   When call stack is empty, this moves up ↑           │
└──────────────────────────────────────────────────────┘

The EVENT LOOP continuously checks:
  "Is the call stack empty? If yes, take the next task
   from the queue and put it on the stack."

Step-by-Step Trace

Code: console.log("A");
      setTimeout(() => console.log("B"), 0);
      console.log("C");

Step 1:  Call Stack: [console.log("A")]     → prints "A"
Step 2:  Call Stack: [setTimeout(cb, 0)]    → registers cb, removed
         Task Queue: [cb]
Step 3:  Call Stack: [console.log("C")]     → prints "C"
Step 4:  Call Stack: EMPTY
         Event Loop: "Stack empty? Yes → move cb from queue to stack"
Step 5:  Call Stack: [console.log("B")]     → prints "B"

Output: A, C, B

This is why "B" prints last even with a 0ms delay. The callback always waits for all synchronous code to finish before it can run.

Synchronous vs Asynchronous — Side by Side

Feature	Synchronous	Asynchronous
Execution	One at a time, in order	Start task, move on, handle result later
Blocking?	✅ Yes — waits for each task	❌ No — moves on immediately
UI impact	Can freeze the page	Keeps the page responsive
Use case	Simple calculations, variable assignment	API calls, timers, file reads, user events
Code complexity	Simple, linear	Requires callbacks, promises, or async/await
Example	`let x = 1 + 2;`	`fetch(url).then(...)`

Everyday Analogy

SYNCHRONOUS — doing laundry the blocking way:
  1. Put clothes in washer → WAIT 45 min → done
  2. Move to dryer → WAIT 60 min → done
  3. Fold clothes → done
  Total: You did NOTHING else for 2 hours.

ASYNCHRONOUS — doing laundry the smart way:
  1. Put clothes in washer → go cook dinner
  2. Washer beeps → move to dryer → go read a book
  3. Dryer beeps → fold clothes
  Total: You cooked dinner AND read a book while waiting.

Problems That Occur with Blocking Code

1. Frozen UI

If JavaScript is busy with a synchronous task, the browser can't update the screen, respond to clicks, or animate anything. Users see a frozen, unresponsive page.

2. Poor User Experience

Nobody wants to wait 3 seconds staring at a blank screen while data loads. Async code lets you show loading spinners, skeleton screens, or partial content while data arrives.

3. Timeouts and Failures

Synchronous network requests (which are deprecated for good reason) would freeze the browser until the server responds — or until the request times out, leaving the user stuck.

4. Wasted Resources

A single-threaded language that blocks means the CPU is idle during I/O waits. Async code lets the CPU do useful work while waiting for slow operations to complete.

Let's Practice: Hands-On Assignment

Part 1: Predict the Output

console.log("1");
setTimeout(() => console.log("2"), 1000);
console.log("3");
setTimeout(() => console.log("4"), 0);
console.log("5");

Answer: 1, 3, 5, 4, 2

1, 3, 5 are synchronous — they run immediately in order.
4 has 0ms delay but still waits for synchronous code to finish.
2 has 1000ms delay — runs last.

Part 2: Simulate Async Data Loading

console.log("📡 Fetching user data...");

setTimeout(() => {
  const user = { name: "Pratham", role: "developer" };
  console.log(`✅ User loaded: ${user.name} (${user.role})`);
}, 2000);

console.log("⏳ Meanwhile, showing the rest of the page...");
console.log("📰 News section loaded.");
console.log("📊 Dashboard widgets loaded.");

Output:

📡 Fetching user data...
⏳ Meanwhile, showing the rest of the page...
📰 News section loaded.
📊 Dashboard widgets loaded.
✅ User loaded: Pratham (developer)   ← arrives 2 seconds later

Part 3: Experience Blocking vs Non-Blocking

// ❌ Blocking version — freezes everything for 3 seconds
console.log("Start (blocking)");
const start = Date.now();
while (Date.now() - start < 3000) {} // busy wait
console.log("End (blocking)"); // prints after 3 seconds of freezing

// ✅ Non-blocking version — doesn't freeze anything
console.log("Start (non-blocking)");
setTimeout(() => {
  console.log("End (non-blocking)"); // prints after 3 seconds, but nothing froze
}, 3000);
console.log("Still running other code!"); // prints immediately

Key Takeaways

Synchronous code runs one line at a time, in order. Each line waits for the previous one to finish. Simple but potentially blocking.
Asynchronous code starts a task and moves on. The result is handled later via callbacks, promises, or async/await. Non-blocking.
JavaScript is single-threaded but uses an event loop and task queue to handle async operations without blocking the main thread.
Blocking code freezes the UI, wastes CPU time, and creates terrible user experiences. Async code keeps everything responsive.
setTimeout, fetch, event listeners, and file I/O are all asynchronous — they register callbacks that execute after all synchronous code finishes.

Wrapping Up

Understanding the difference between synchronous and asynchronous JavaScript is one of the most important mental shifts you'll make as a developer. Once you see that JavaScript doesn't "wait" for slow tasks — it moves on and comes back later — a huge amount of confusing behavior starts making sense. The order of console.log outputs, how fetch works, why your data is undefined before the API responds — it all clicks.

I'm working through all of this in the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. This article is the foundation — next comes promises, async/await, and the full event loop picture. But understanding sync vs async first makes everything that follows much easier.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles coming as the journey continues.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Coding Cat Oran S2 Ep1 — The Excel Republic

SysLayer — Sun, 10 May 2026 10:51:45 +0000

A story about trial production, three departments, and three versions of the truth.

It's 7am on the production floor.

Three people are standing around a whiteboard.
One is from QA. One is from Engineering. One is from Manufacturing.
They are arguing about a number.

The number is the yield rate for Product A, Batch 7, last Tuesday.

QA says: 87%.
Engineering says: 91%.
Manufacturing says: "Depends on which shift."

All three are holding laptops.
All three are looking at Excel files.
All three are right.

Oran is an orange cat. No CS degree.
He learned to code at night, online, on his own time,
with AI tools and courses he bought on sale.

He got hired anyway. It's that kind of year.

His job title is IT. His actual job is: whatever nobody else wants to do.

This week, his job is to reconcile the production data.

He sits down. He opens all three Excel files.

The columns have different names.
The formulas have different logic.
The defect definitions are different.
QA counts a scratch as a defect. Manufacturing counts it as cosmetic. Engineering doesn't count it at all unless it affects function.

Same scratch. Three categories. Three numbers.

Oran closes his laptop.
He stares at the ceiling for a long time.

Here is what Oran understands, sitting in that chair:

The data problem is not a data problem.

It's a political problem dressed as a data problem.

Each department's Excel file is their scoreboard.
Their evidence. Their alibi.
If QA's numbers are the official numbers, QA controls the narrative.
If Engineering's numbers are official, Engineering does.
If they merge into one system, someone's score gets worse.

Nobody built these spreadsheets to hide information.
They built them to protect themselves.
That's different. And it's harder to fix.

Oran opens a blank document.

He doesn't start with a database schema.
He doesn't start with a system architecture.
He starts with a question:

What would it mean for all three of these numbers to be correct at the same time?

He writes:

Inspection timing is different. QA measures at end-of-line. Engineering measures at each station. Manufacturing measures at shipment.
Defect scope is different. Three departments, three definitions, never written down anywhere.
The data is collected by different people, at different times, with different tools, for different audiences.

One batch. One production run. Six data points that look like contradictions but are actually just context.

The problem isn't that the data is wrong.
The problem is that there's no single place that holds all of it together.

That evening, Oran writes the first three lines of what will eventually become a database schema.

He doesn't know that yet.
He thinks he's just taking notes.

-- What actually happened
-- Who was there
-- When

He looks at the three Excel files one more time.

Then he writes a fourth line:

-- And what "defect" means in this context

There were three versions of the truth.
Everyone was lying. No one was wrong.
The database didn't exist yet.
But the problem did.

Learning Xahau: Debunking Common Myths About Xahau

Ekiserrepe — Sun, 10 May 2026 10:50:31 +0000

If you spend enough time reading discussions about Xahau, you’ll quickly notice that many people talk about the blockchain and its capabilities without fully understanding how it actually works.

The rise of AI-generated content, combined with the lack of deep technical research in many online discussions, has created an environment where misinformation spreads extremely fast. Over the last few months, I’ve repeatedly seen the same myths, misunderstandings, and inaccurate comparisons appear across social media.

So I decided to write this article to help clarify some of the most common misconceptions surrounding Xahau.

If you want to learn more about Xahau, I also recommend checking out the rest of the Learning Xahau series, where I share information about the ecosystem, automation concepts, development ideas, and practical use cases for builders interested in working with Xahau.

Today, however, we’re going to focus on breaking down some of the most common myths I’ve encountered online.

1. “Xahau Is an XRP Ledger Sidechain”

This is probably the most repeated myth.

XRP Ledger and Xahau share technological origins, but Xahau is not a native sidechain connected to the XRP Ledger.

Xahau is an independent Layer 1 blockchain built from a fork of XRPL code that evolved in a completely different direction.

That means:

Xahau has its own validators
Xahau has its own native asset: XAH
Xahau has its own governance and technical evolution
XRPL amendments do not automatically appear on Xahau

Both networks may occasionally adopt ideas from one another, but they evolve independently.

There are features available on XRP Ledger that do not exist on Xahau, and there are features on Xahau that do not exist on XRP Ledger.

Part of the sidechain confusion comes from the early history of the project.

In the beginning, Xahau was actually described as a sidechain, including in early versions of its whitepaper. At that time, there was a mechanism where XRP could be burned on the XRP Ledger and converted into XAH on the Xahau blockchain. However, that process was eventually closed. Once that bridge mechanism disappeared, the term “sidechain” no longer made technical sense.

Today, Xahau operates as an independent Layer 1 blockchain, even though it still shares part of its original codebase heritage with XRP Ledger.

2. “Projects Built on Xahau Don’t Actually Use XAH”

This is another claim I’ve seen online that honestly surprised me.

In many blockchain ecosystems, “adoption” often refers to companies using private versions of the technology, centralized services, or additional enterprise services offered by blockchain companies, while still presenting it publicly as if they were directly using the public blockchain itself. In some cases, the public chain or its native asset barely participates in the actual operation behind the scenes. Xahau works differently.

To interact with the network, you need XAH. Because XAH is the native asset required for network operation. XAH is a gas token.

XAH is used for:

Account/Object reserves
Transaction execution
Hook interactions

There is no artificial separation between “the technology” and “the public blockchain.” Xahau only makes sense if the blockchain itself is actively used.

3. “Hooks Are Just Ethereum Smart Contracts”

No. While both systems enable automation, the philosophy behind them is completely different.

In Ethereum, smart contracts are typically full decentralized applications deployed directly on-chain. In Xahau, Hooks are lightweight pieces of logic attached directly to accounts that react to specific ledger events.

This creates a very different model:

Compact logic
Deterministic behavior
Native account integration
Direct financial automation

Hooks were never designed to replicate the EVM.

4. “The XAH You See on XRPL Is Native XAH”

No.

When you see XAH traded on the XRP Ledger DEX, you are usually seeing an IOU representation of XAH, not native XAH itself.

Even worse, multiple fake IOUs using the name “XAH” have appeared over time, created by scammers attempting to mislead users.

At the moment, the main legitimate XAH IOU on XRPL is issued by Gatehub:

Currency Code: XAH
Issuer: rswh1fvyLqHizBS2awu1vs6QcmwTBd9qiv

Native XAH only exists directly on the Xahau blockchain. This is similar to how wrapped versions of BTC or ETH exist on other blockchains without being the native assets themselves.

And this distinction matters because certain features only exist directly on Xahau, such as Balance Adjustment, which currently provides around 4%.

5. “Xahau Is Just XRP Ledger With Smart Contracts”

That explanation is far too simplistic.

Yes, Hooks are one of the biggest innovations introduced by Xahau. But Xahau also introduces new programmable dynamics and a different philosophy around financial automation.

The goal is not simply to “add smart contracts.”

The goal is to allow users to integrate custom business logic directly into the ledger itself. That fundamentally changes how financial systems can be automated.

6. “Hooks Are Dangerous Because They Can Do Anything”

Actually, Hooks were specifically designed with limitations in mind. Strict execution limits and deterministic behavior exist precisely to avoid many of the problems seen in more open smart contract environments. Those limitations are not weaknesses. They are part of the design philosophy.

Instead of allowing infinite complexity, Hooks prioritize:

Predictability
Efficiency
Security
Low operational costs
Native integration

7. “Xahau Depends on Ripple”

Ripple does not own or control Xahau.

Xahau emerged after years of research and development surrounding Hooks technology. Originally, Hooks were expected to become part of XRP Ledger itself. However, after significant pushback, the developers behind the Hooks project decided not to abandon years of work and instead launched an independent blockchain where Hooks could exist natively: Xahau.

Like XRPL, Xahau is built using open-source technology and independent validators. Ripple has no governance control or any type of control over Xahau.

Interestingly, it was later announced that a certain level of programmability would be introduced to the XRP Ledger, beginning with features such as Smart Escrows, expected around late 2025. As of May 2026, those features have still not arrived in production.

8. “Xahau Is Trying to Compete With Every Other Blockchain”

The blockchain industry often frames everything as a constant war between ecosystems:

One chain vs another
One token vs another
One community attacking another

But Xahau does not necessarily need to operate under that mentality. Financial institutions are free to use whatever technologies they consider useful. And in reality, most companies rarely depend on a single infrastructure provider.

An organization may simultaneously use:

Multiple blockchains
Traditional banking systems
Private infrastructure
Internal automation tools

Xahau does not need to “win” a blockchain war to be useful.

There’s also an uncomfortable reality within this industry:

Many blockchain companies directly or indirectly pay for institutional pilots and demonstrations through:

PoCs
Pilot programs
Corporate demos
Marketing partnerships

And in many cases, those institutions never end up using the public blockchain or native token at all. Yet the announcements are still heavily promoted to generate speculation and marketing narratives. That creates enormous confusion within crypto communities.

Xahau is attempting to follow a different philosophy. The goal is not to manufacture headlines. The goal is to build tools that can actually function in real regulatory and financial environments. And if institutions choose to combine Xahau with other technologies, they can. Because the objective is not to “win a competition.” The objective is to build useful technology.

Final Thoughts

Understanding Xahau requires looking beyond the usual blockchain narratives. Too often, people try to categorize every project using the same labels: Ethereum competitor, XRPL sidechain, smart contract platform, or DeFi chain. But Xahau was not designed to fit neatly into those categories. Its philosophy is different.

Instead of chasing maximum complexity, Xahau focuses on making financial automation more integrated, predictable, and usable directly at the ledger level.

Whether Xahau succeeds long term will ultimately depend on real adoption, real builders, and real utility, not marketing narratives or social media speculation.

And that is probably the most important thing to understand about Xahau: the goal is not to imitate what already exists, but to explore a different way of building programmable financial systems.

Why Your RAG Chatbot Looks Great in Week 1 and Hallucinates by Month 2

Akshay Kumar BM — Sun, 10 May 2026 10:43:34 +0000

💡 Week 1 demo → "this is amazing."

Month 2 production → "why is it hallucinating?"

I've seen this pattern more times than I can count. The team builds a RAG chatbot. It works beautifully on the 20 questions they tested it with. They ship it. Real users show up with real questions. The cracks appear.

The model is almost never the problem.

The system around it is.

After shipping 10+ production RAG systems — handling everything from 100 queries a day to 1,000+ a week at 95% accuracy — I've narrowed it down to four things that consistently separate the ones that keep working from the ones that quietly get abandoned.

Here's what I follow on every build now.

🔍 Why RAG Fails in Production (It's Not the Model)

Most teams build RAG like this:

→ Grab the documents
→ Chunk and embed them
→ Add a retriever
→ Write a prompt
→ Ship it

It works in the demo because the demo is a controlled environment. You know the questions. You've tested on a small, clean set of docs. The model looks smart.

Production breaks this in three ways.

Real users ask questions the team never anticipated. The retriever pulls the wrong chunks. The model doesn't know it retrieved the wrong chunks. It answers anyway.

The knowledge base is messier than it looked. Confluence pages that conflict with each other. Slack threads that reference decisions never written down. Google Docs with five versions. The model retrieves all of it and synthesizes a "confident average" — which is a hallucination with citations.

There's no feedback loop. Nobody knows which answers are wrong until a user complains, by which point the damage is done.

Research confirms this isn't a fringe problem: 40–60% of RAG implementations never make it to production at all. Of the ones that do, naive RAG — embed, retrieve top-k, prompt — consistently plateaus at 70–80% retrieval precision without additional structure around it.

The fix isn't a better model. It's building the system properly.

🧠 Rule 1: Evals Before Prompts

This is the highest-leverage thing I do on every RAG project, and it's the thing most teams skip.

Before writing a single prompt, build a test set of 30–40 real questions with expected answers. Run every prompt change — every chunk size tweak, every retriever adjustment — against the full set.

Without this, you're optimizing blind. You fix one question and break three others without knowing it.

# eval_set.py — structure for a minimal RAG eval set

eval_set = [
    {
        "question": "What is our refund policy for enterprise customers?",
        "expected_answer": "Enterprise customers get a 30-day money-back guarantee.",
        "source_doc": "enterprise-policy-v3.md",
        "category": "policy"
    },
    {
        "question": "Who do I contact for billing issues?",
        "expected_answer": "billing@company.com or the #billing Slack channel.",
        "source_doc": "support-contacts.md",
        "category": "contacts"
    },
    # ... 30-40 total, covering every major topic area
]

def run_eval(rag_chain, eval_set):
    results = []
    for item in eval_set:
        response = rag_chain.invoke(item["question"])
        results.append({
            "question": item["question"],
            "expected": item["expected_answer"],
            "actual": response["answer"],
            "sources_retrieved": response["source_documents"],
        })
    return results

📌 Pro tip: Pull the questions from real user queries where possible. If you have a Slack channel where employees ask the kind of questions the bot will answer, mine it for the first 30 questions. Real questions are always harder than invented ones.

The eval set also tells you when you're done. "Good enough" stops being subjective — either it passes 90%+ of cases or it doesn't ship.

Worth noting: in 2026, 60% of RAG deployments include systematic evaluation from day one, up from under 30% in early 2025. The teams that skipped it are the ones rebuilding their systems now.

🛠 Rule 2: One Source of Truth

Most RAG failures I've traced start here — not in the model.

The knowledge is scattered. Confluence has the official policy. Someone updated it in a Google Doc but didn't update Confluence. There's a Slack thread where a manager made a call that contradicts both. The RAG system indexes all three.

The model retrieves two conflicting chunks. It can't tell which is authoritative. It synthesizes a confident-sounding answer that blends both — and matches neither.

No retriever in the world solves this. It's a data problem, not a model problem.

Step 1 of every RAG project I touch is not building the bot. It's forcing a canonical source:

→ Pick one system as ground truth per knowledge domain (Confluence for policy, Notion for specs, etc.)
→ Archive or redirect any conflicting copies — if it's not in the canonical source, it doesn't exist for the bot
→ Set an update SLA: if a policy changes, the canonical page gets updated within 24 hours

graph TD
    A[User Query] --> B[Retriever]
    B --> C{Single canonical source?}
    C -->|Yes| D[Clean, consistent chunks]
    C -->|No| E[Conflicting chunks from 3 systems]
    D --> F[Faithful, accurate answer]
    E --> G[Confident hallucination]

This sounds like busywork. It's actually the most important infrastructure decision in the project.

Research backs it up: 60% of enterprise RAG projects fail not because of poor retrieval, but because they can't maintain data freshness at scale. One study found that when given unvetted baseline data, models fabricated responses for 52% of out-of-scope questions — not because the model was bad, but because it had no way to know what it didn't know.

🎯 Rule 3: Fallback Over Hallucination

A system that says "I don't know" is more valuable than one that guesses wrong.

This sounds obvious. It's almost never implemented.

The failure mode: the retriever pulls chunks that are loosely related but not actually relevant. The model generates a plausible-sounding answer from them. The user reads it. They have no way to know it's wrong. They act on it.

Trust is built one answer at a time. It's destroyed the same way.

Here's the pattern I use — a confidence-based router that sends uncertain answers to a human instead of letting the model guess:

# confidence_router.py

CONFIDENCE_THRESHOLD = 0.75

def route_with_fallback(query, rag_chain, retriever):
    docs = retriever.get_relevant_documents(query)

    # No docs or low retrieval confidence → route to human
    top_score = docs[0].metadata.get("score", 0) if docs else 0

    if top_score < CONFIDENCE_THRESHOLD or not docs:
        return {
            "answer": (
                "I'm not confident I have accurate information on this. "
                "Let me tag someone who can help — @support-team"
            ),
            "routed_to_human": True,
            "query": query,
        }

    response = rag_chain.invoke(query)
    return {
        "answer": response["answer"],
        "routed_to_human": False,
        "sources": response["source_documents"],
    }

📌 Pro tip: Log every query that gets routed to a human. These are your highest-value training questions. Add them to the eval set with the correct answer documented. Over time, the system learns its own blind spots.

The fallback message matters too. "I don't know — here's who does" is not a failure. Users who get honest fallbacks trust the system more than users who get confidently wrong answers twice.

💡 Rule 4: Observability from Day One

The eval set is your pre-deployment safety net. Observability is your production safety net.

Log every conversation. Not just the query and the answer — log the retrieved chunks, the retrieval scores, the prompt constructed, and the final response.

# logger.py — minimal production RAG logging

import json
from datetime import datetime

def log_rag_event(query, retrieved_docs, response, routed_to_human, metadata={}):
    event = {
        "timestamp": datetime.utcnow().isoformat(),
        "query": query,
        "retrieved_chunks": [
            {
                "content": doc.page_content[:200],
                "score": doc.metadata.get("score"),
                "source": doc.metadata.get("source"),
            }
            for doc in retrieved_docs
        ],
        "response": response,
        "routed_to_human": routed_to_human,
        **metadata,
    }
    # Write to your logging backend — CloudWatch, Datadog, a flat file
    print(json.dumps(event))
    return event

Then build the review loop:

→ Flag every answer that gets a thumbs-down or triggers a human escalation
→ Review flagged answers weekly (30 minutes, not hours)
→ Add wrong answers to the eval set with the correct answer documented
→ Re-run evals before the next deployment

This loop is what makes the system improve over time instead of silently degrade.

The eval set starts at 30–40 questions. Six months in, it's 150 questions covering every edge case real users found. The system that was 80% accurate in week 1 is genuinely 95% accurate by month 6 — not because the model changed, but because the system around it got tighter.

Tools I've used for this: LangSmith for tracing and full conversation logging, RAGAS for automated eval scoring, and a simple shared spreadsheet for the human review loop. You don't need an elaborate stack. You need the habit.

Key Takeaways

✅ Write 30–40 eval questions before a single prompt — this is the line between a demo and a system you can maintain
✅ Fix the data before building the bot — no retriever fixes conflicting or fragmented knowledge sources
✅ A system that says "I don't know" is more valuable than one that confidently hallucinates

The pattern I keep seeing: teams spend time optimizing the part that's already good (the model) and skip the parts that actually break in production (evals, data quality, fallbacks, observability). The boring infrastructure is what makes the intelligent part work.

If you're building or inheriting a RAG system that performs well in testing but keeps surfacing wrong answers in production — these four things are almost always where it breaks.

👋 Let's Connect

If you found this useful or want to talk through a similar problem:

🔗 LinkedIn | 💻 Portfolio | 📧 akshaykumarbedre.bm@gmail.com

I Built Graphode — An AI-Powered GitHub Repository Visualizer

Harsh Kalia — Sun, 10 May 2026 10:39:56 +0000

I Built Graphode — An AI-Powered GitHub Repository Visualizer

Ever spent hours trying to understand a new codebase? I did too. So I built Graphode to solve that problem.

What is Graphode?

An AI-powered GitHub repository visualizer that helps you understand any codebase in minutes, not hours.

Just upload a GitHub repo → Get instant insights on architecture, dependencies & code flow → Understand what you're looking at.

Watch it in action:

Features

✓ AI-Powered Analysis — Uses Google Gemini AI to analyze your code
✓ Visual Architecture — See dependencies & code flow instantly
✓ Real-Time Collaboration — Analyze together with your team
✓ Instant Insights — No more hours wasted on code exploration

Perfect For

Code reviews
Onboarding new team members
Diving into unfamiliar projects
Understanding legacy codebases

Try it free

https://graphode.tech/

Would love your feedback! Let me know what you think in the comments 🙌

Building Echovault During a 130,000 Person Hackathon

Ugo Nwune — Sun, 10 May 2026 10:37:09 +0000

A few months ago I entered the world’s largest hackathon with over 130,000 competitors.

My original project idea had nothing to do with AI memory preservation.

I started by building a social commerce platform called OAK where people could upload clothing designs and have them printed onto real garments and shipped. Halfway through the competition I realized I wasn’t emotionally connected to the idea, and honestly it didn’t feel differentiated enough to compete at that scale.

One of the hackathon sponsors was Tavus.

Around that time I remembered a voice note my uncle sent me before he was killed in Nigeria.

For years I replayed that recording during difficult periods of my life. Hearing his voice still carried emotional weight long after he was gone. But eventually I kept thinking about something unsettling:

the voice note was static.

I could replay it forever, but I could never ask a new question.
I could never hear a new story.
The memory was frozen in time.

That realization became the foundation for Echovault.

I pivoted completely and spent the next 9 days building an AI digital legacy platform designed to preserve a person’s memories, personality, stories, and voice for future generations.

The Stack

The project started on Bolt.new since the hackathon required it, then eventually moved into Cursor for faster iteration.

The stack ended up looking like this:

React frontend
Supabase backend
Gemini for NLP and embeddings
Tavus for conversational video
ElevenLabs for voice synthesis

Mostly written in typescript and deployed on vercel. The core idea behind Echovault was building an “Echo,” an AI representation of a person trained on their memories, personality traits, and life experiences through guided conversations.

The Disaster Moment

At one point during development, an AI assistant accidentally triggered a database reset during a prompt chain.

I blindly approved it.

The entire database disappeared instantly.

That mistake cost nearly two full days of recovery work. I had to rebuild from an old schema.sql file inside the workspace, recreate missing tables manually, and rewrite parts of the RLS policies to secure the database properly again.

The recovered database was never quite the same afterward, but the project survived.

The Result

Echovault ended up winning the “Most Inspirational Story” award at the hackathon.

Part of me secretly hoped to win something more technical because I was proud of how ambitious the architecture became under such a short timeline, but the award still meant a lot because the story behind the product was deeply personal.

The experience completely changed how I think about software creation.

Long term, my goal is to make Echovault a legitimate way for people to digitally preserve themselves for the far future.

https://echovault.me

Why We Render Everything in the Browser

Vivian Voss — Sun, 10 May 2026 10:35:52 +0000

On Second Thought — Episode 07

Open any modern site. The utility provider's login, the restaurant booking, the parcel tracker. The laptop fan spins up to render text. The median page in 2025 ships 697 KB of JavaScript before a single character of content is visible. The browser, meanwhile, is asked to do the work that a server in 1996 already did, and to do it on a battery, on a metered connection, on a chassis warm enough to taste.

This is the post about that.

The Axiom

The reflex is universal. Every new web project begins with a frontend framework, a build pipeline, a bundler, a hydration strategy. The server, where the data already lives, has been reduced to a JSON tap. Rendering is the browser's problem now. Nobody quite remembers when this was decided.

It was not decided in any single meeting, or with any single argument. It compounded. Each project chose the framework because the previous project had; each developer learned the framework because that was the job posting. By the time anyone thought to question the assumption, the assumption had become the architecture, the curriculum, the conference circuit, the hiring funnel. Reaching for a server-rendered page in 2026 feels, to many engineers, like reaching for COBOL: technically defensible, professionally suspect.

That feeling is the topic.

The Origin

AJAX, 2005. Jesse James Garrett gave the pattern its name in his now-famous essay, describing how Gmail and Google Maps used asynchronous XMLHttpRequest to update parts of a page without a full reload. The technique was real, the gain was real, the use cases were narrow: applications in which a user lived for hours and interacted hundreds of times per session.

Backbone arrived in 2010 (Jeremy Ashkenas), Angular the same year (Misko Hevery, Adam Abrons), Ember in 2011, React in 2013 (Jordan Walke at Facebook). Each was a sincere response to a real problem: the desktop-application-in-a-browser, an experience that genuinely required client-side state management, view diffing, and offline tolerance. Gmail, Google Maps, Figma. Real applications, real argument.

The pattern then spread to every site that was not Gmail. Marketing pages, brochure sites, restaurant menus, government forms, regional rail booking, doctor's-surgery appointments. The argument that justified Gmail's architecture was never re-examined for the brochure, because re-examining the argument required a different skill set than building the brochure had required. By 2018, the SPA was treated as the default architecture of the web. By 2020, "I'll just spin up a Next.js project" was the unexamined first move for static content.

The shift was not theoretical; it was a hiring problem. A generation of frontend developers learned React in a bootcamp, then a job, then another job, and never learned a server language. The job market rewarded React on the CV; nobody was hiring for "knows what a session cookie is". TypeScript arrived as the local repair: a build-time wrapper meant to compensate for the deficiencies of the language the team had chosen because it was the only one anyone knew. The fix was added before the question was asked.

Episode 02 of this series left this question open: what happens when a profession trains on tools instead of foundations? This is its first practical consequence. The architecture follows the curriculum. The web becomes a thing that requires a 700 KB bundle to display a heading because the people who build it cannot, professionally, build it any other way.

The Cost

Median page weight in 2025, per the HTTP Archive Web Almanac: 697 KB of JavaScript on home pages, 632 KB on inner pages. The 90th percentile: 1,979 KB on home pages. The 10th percentile: 87 KB. The lower bound is, demonstrably, achievable. Most teams are nowhere near it.

The first cost is paid downstream, on the device, in electricity. On a mid-range Android over 4G, those numbers translate into eight seconds to Time to Interactive on a representative page, and more on a slow connection. Mobile data, in EU roaming, is not free. The cost that is harder to name on an invoice is the wattage. Each page load now drives the client CPU and GPU as if it were running a workload, not displaying text. Frameworks parse, hydrate, diff, reconcile, and re-render; the silicon spins; the fan, on a quiet office, becomes audible. Battery sensors register the drain in measurable single-digit percentages per twenty minutes of casual reading. The user is, in literal terms, paying for the rendering with their own battery and their own data plan, on hardware they bought, for content the server already had. There is no return on the spending, because the page was a printed leaflet at heart.

Multiplied across a billion daily web sessions, the unnecessary draw climbs into terawatt-hours per year, a figure documented in the Sustainable Web Manifesto's reference dataset and the W3C Web Sustainability Guidelines. The electricity is only the easiest column to count. Beneath it sits the hardware that consumed it: the lithium for the laptop battery that drains faster, the rare earths in the radio that keeps the data flowing, the cobalt in the datacentre's storage, the copper in the racks, the cooling water that the racks then warm. Megatons of natural resources, quietly enlisted on the side of a marketing page that did not need any of them. There is, here, an inconvenient observation. The same conferences that run sustainability tracks ship frameworks of half a megabyte per visit; the same engineer who publishes a sustainability-conscious LinkedIn post will, on Monday morning, push a pull request that adds 200 KB of JavaScript to a marketing page. The contradiction holds itself politely apart, and is, on close inspection, untenable. One cannot ship the bundle and lecture on pollution in the same conversation.

Accessibility collapses without JavaScript. Screen readers must wait for the framework to construct the DOM before they can announce anything; if the JavaScript fails to load, the page is empty. Crawlers must execute the JavaScript to index the content, which means search-engine indexing has become a secondary industry of headless browsers, and the cost of that industry is borne by datacentres no one sees on the invoice.

The browser tab is now the heaviest process on the average laptop. Most of what it computes is layout for content that the server already had, in a format the server could already serve. The Senior Engineer's day, when she debugs why the search bar takes eight hundred milliseconds to respond, walks through a stack of seven layers between the user and the database, finds at the bottom a query that wants for an index, and notes that the layer above it could have been a single server-rendered HTML response. The HTML response would have been forty kilobytes. The current implementation is six hundred and ninety-seven.

Then, having pacified the client, the same language was asked to manage the server. Node.js, originally an event-driven runtime for I/O-bound real-time workloads (which it does competently), was deployed in whole cohorts of new projects to do work that PHP, Ruby, Python and Go had been doing efficiently for decades. The reason was not technical. Node.js is not faster than Go (it is not), not smaller than Rust (it is not), not safer than Python (it is not). It was deployed because the team knew only the one language and could not, professionally, choose another. The build pipeline that wraps the language to compensate for its deficiencies on the client was duplicated on the server. Every architectural decision compounds. The bill is paid twice: once at the client, once at the rack. The rack pays in CPU cycles and in megawatt-hours; the client pays in milliseconds and in power. Neither user signed up for either.

Around all of it, the dependency cloud, and a quietly inconvenient truth at the bottom of it. JavaScript was shipped, in 1995, without a standard library worthy of the name; npm appeared in 2010 to fill the vacuum, and the vacuum filled, in turn, with hundreds of transitive packages from strangers, then thousands. It is, by some distance, the public software repository most reliably compromised in routine use. The 2024 Sonatype State of the Software Supply Chain report counted more than half a million malicious packages across public registries; npm carried the bulk of them. left-pad in 2016, event-stream in 2018, ua-parser-js in 2021, and the September 2025 incident in which eighteen packages with 2.6 billion weekly downloads were compromised in a single coordinated attack, are the headlines a Senior Engineer can name. The thousand smaller incidents are the ones nobody tracks.

The maintenance of the dependency cloud is then outsourced to a second cloud, the supervisory cloud: Dependabot, Snyk, Renovate, GitHub Advanced Security, the long tail of supply-chain-monitoring SaaS. Each one runs on servers, consumes electricity, opens pull requests for other servers to review, sends Slack notifications for engineers to triage, and produces dashboards for managers to look at. The supervisory cloud has, in turn, its own dependencies, its own build pipelines, its own pricing tiers. The wrappers wrap the wrappers. One does, at some point, lose count of the clouds.

The question that closes this section is the obvious one, and the one that the industry has spent fifteen years pretending not to ask. If the answer to a security failure in your dependencies is to add another vendor, another runtime, another monitoring service, and another bill, you have not solved the problem. You have rented a louder version of it. None of this would exist in a language whose standard library could carry the weight of a real application. Rust, Go, Python, Ruby, even PHP all ship with first-party batteries that npm has spent a decade and a half badly approximating, with the supply chain to match. The vacuum was self-inflicted, in the choice of the language at the bottom of the stack.

The Question

The proofs are not theoretical. They are in production, and they have been for years.

Wikipedia: 60 million articles, MediaWiki on PHP 8.3 with MySQL/MariaDB and an aggressive caching layer, server-rendered, faster on a budget Android over a coffee-shop wireless than most marketing single-page applications. The Wikimedia infrastructure handles hundreds of thousands of views per second, and it does so by caching server-rendered HTML, not by shipping a runtime to the client.

GOV.UK: 67 million citizens, designed by the Government Digital Service from 2012 onward, with progressive enhancement mandated by the GOV.UK service manual for every government service. HTML first, CSS second, JavaScript only as enhancement. The principle is documented, the policy is enforced, the result is a public-sector portal that opens on a Nokia from 2007 and an iPhone from 2024 alike. It is not glamorous. It is, demonstrably, robust.

Hacker News: server-rendered, written in Arc (a Common Lisp dialect) by Paul Graham and Robert Morris from 2007, opens before the loading spinner of any modern dashboard. The site is famously austere, deliberately so. It is also, after eighteen years, still online and still fast.

HEY and Basecamp, the products of 37signals: server-rendered with Hotwire (a Ruby on Rails extension that DHH and his team published in 2020), fully interactive, no client-side framework. The interactive elements arrive over the wire as HTML fragments, swapped into place by a tiny client-side library. The model is older than the SPA, applied to a modern email client, and it works.

HTMX, by Carson Gross at Big Sky Software (2020): 14 KB minified, around 5 KB gzipped, doing what JavaScript frameworks an order of magnitude larger claim to do. Carson Gross's argument is the simplest version of the case in this post: most of what we want a SPA for can be done with attributes on plain HTML, and the rest can wait.

Netflix's logged-out homepage, 2017: the team removed client-side React entirely from the landing page and rebuilt the language switcher in fewer than 300 lines of vanilla JavaScript. Time to Interactive improved by more than 50%, and Jake Archibald's writeup of the change remains one of the canonical case studies for the cost of unnecessary client-side rendering. Netflix did not abandon React; it kept it server-side, where the value is, and removed it from the client, where the cost is.

Cloudflare Pingora, 2022: Cloudflare published a blog post describing how their nginx-and-Lua proxy, after years of scaling, had hit the limits of its architecture, and was replaced with a Rust-based proxy of their own design. The new proxy serves over a trillion requests per day, with about 70% less CPU and 67% less memory than the old one. The lesson is not "Rust beats Lua" in any tribal sense; it is "a small, focused, efficient server kernel beats a tower of accreted layers, and the savings show up on the electricity bill the same week".

A word on the standard objection, before it appears. The reflexive defence of the SPA is "but we need reactivity". Reactivity has not been an obstacle to server-rendered architectures for at least a decade. Hotwire's Turbo Streams, HTMX's hx-swap and hx-trigger attributes, Phoenix LiveView's WebSocket-driven HTML diffs, Laravel Livewire, ASP.NET Blazor Server: all of them deliver partial updates, optimistic UI, two-way binding, even real-time collaborative behaviour, by sending small HTML fragments over the wire instead of shipping a runtime to interpret JSON. The total client-side weight, in every one of these patterns, is in single-digit kilobytes. Reactivity is a solved problem. The framework industry sells it back as if it were not.

Each of these stacks chose a different server language: PHP for MediaWiki, Ruby for Rails and Hotwire, Common Lisp for Hacker News, Python for Django sites in the same family, Go for many modern static-content tools, Rust for Pingora and the modern wave. On a FreeBSD server, any of these is a single pkg install away, with one service manager and one configuration tree. The language is the smaller question; what matters is that the rendering happens on the server, where the data and the session already live, in a runtime that does not have to be re-shipped to every visitor.

Rust is, for the modern build, particularly hard to argue against. The combination of a single static binary, no garbage collector, native concurrency, and the kind of compile-time safety that removes whole classes of runtime error is, today, the easiest case to make. But the case is not "use Rust". The case is "render where the data is".

The larger question is this. What if rendering happened where the data already lived, and the data did not need to be guarded from a thousand strangers we never invited into the project? Most of the cost of the modern web, paid in milliseconds, in power, in megabytes, in accessibility, in indexability, in carbon, in security incidents, in supervisory SaaS, would simply not exist. The fastest bundle is the one that is never shipped. The safest dependency is the one that was never installed.

Read the full article on vivianvoss.net →

By Vivian Voss — System Architect & Software Developer. Follow me on LinkedIn for daily technical writing.

The Most Common Bug in Liters to Gallons Converters

md nurul islam — Sun, 10 May 2026 10:31:45 +0000

A liters-to-gallons converter looks easy.

You take a liter value, multiply it by a conversion factor, and show the answer.

For US liquid gallons, the formula is:

const gallons = liters * 0.264172052358;

Simple.

But there is one common mistake that can make the entire converter wrong:

not specifying which gallon you mean.

A US liquid gallon and an imperial gallon are not the same.

That means a converter can have clean code, good formatting, and a nice UI, but still give the wrong answer if it uses the wrong gallon standard.

I worked through this while building a browser-based liters to gallons converter. The biggest lesson was simple: the formula is not enough. The unit definition matters.

1. Be clear: US gallons or imperial gallons?

This is the first decision.

For US liquid gallons:

const US_GALLONS_PER_LITER = 0.264172052358;

So the function becomes:

function litersToUSGallons(liters) {
  return liters * US_GALLONS_PER_LITER;
}

For imperial gallons, the factor is different:

const IMPERIAL_GALLONS_PER_LITER = 0.2199692483;

So this would be:

function litersToImperialGallons(liters) {
  return liters * IMPERIAL_GALLONS_PER_LITER;
}

That difference matters.

For example:

console.log(litersToUSGallons(10));
// 2.64172052358

console.log(litersToImperialGallons(10));
// 2.199692483

Same 10 liters.

Different answer.

That is why your UI should not just say:

Gallons

It should say:

US gallons

or:

Imperial gallons

Users should never have to guess.

2. Use readable constants

This is not great:

function convert(value) {
  return value * 0.264172052358;
}

It works, but the number has no context.

This is better:

const US_GALLONS_PER_LITER = 0.264172052358;

function litersToUSGallons(liters) {
  return liters * US_GALLONS_PER_LITER;
}

Now the code explains itself.

Anyone reading it can see:

the input is liters
the output is US gallons
the factor is gallons per liter

Readable code matters more than saving one line.

3. Format the result before showing it

Raw decimal output can feel messy.

For example:

const gallons = litersToUSGallons(3);

console.log(gallons);
// 0.792516157074

That is technically fine, but it may be too much for most users.

A normal user probably expects:

3 L = 0.792516 gal

So format the number:

function formatNumber(value, maxDecimals = 6) {
  return new Intl.NumberFormat("en-US", {
    maximumFractionDigits: maxDecimals,
  }).format(value);
}

Then:

const gallons = litersToUSGallons(3);

console.log(formatNumber(gallons));
// 0.792516

Cleaner. Easier to scan. Still accurate enough for normal use.

4. Use smart precision

Not every value needs the same number of decimal places.

Small values need more precision:

0.1 L = 0.026417 gal

Large values can be shorter:

100 L = 26.42 gal

A simple formatter can handle this:

function formatGallons(value) {
  if (Math.abs(value) < 1) {
    return formatNumber(value, 6);
  }

  if (Math.abs(value) < 100) {
    return formatNumber(value, 4);
  }

  return formatNumber(value, 2);
}

This keeps the output useful instead of noisy.

Example:

console.log(formatGallons(litersToUSGallons(0.5)));
// 0.132086

console.log(formatGallons(litersToUSGallons(5)));
// 1.3209

console.log(formatGallons(litersToUSGallons(500)));
// 132.09

Good formatting is part of the user experience.

5. Handle empty and invalid input

Users do not always type perfect values.

They may:

clear the field
paste spaces
enter text
type a negative number
use decimals
enter a very large number

Your converter should not show NaN.

Start with a safe parser:

function parseInput(value) {
  if (value.trim() === "") {
    return null;
  }

  const number = Number(value);

  if (!Number.isFinite(number)) {
    return null;
  }

  return number;
}

Then use it before converting:

function convertInput(value) {
  const liters = parseInput(value);

  if (liters === null) {
    return "";
  }

  const gallons = litersToUSGallons(liters);
  return `${formatGallons(gallons)} US gal`;
}

This keeps the UI clean.

6. Decide whether negative values are allowed

Mathematically, negative liters can be converted:

console.log(litersToUSGallons(-5));
// -1.32086026179

But does that make sense in your product?

For a general math tool, maybe yes.

For fuel, water, cooking, aquarium volume, beverage containers, or household measurement, negative volume usually does not make sense.

If your tool should block negative values, make that rule explicit:

function parseVolumeInput(value) {
  const number = parseInput(value);

  if (number === null || number < 0) {
    return null;
  }

  return number;
}

This is not a math decision.

It is a product decision.

7. Build the converter client-side

For simple unit conversions, an API is usually unnecessary.

The browser can calculate this instantly:

10 liters × 0.264172052358

There is no need to send that value to a server.

Client-side conversion gives you:

faster response
no network dependency
lower server cost
better privacy
fewer failure points

For simple calculators, the best backend is often no backend.

8. Minimal working example

Here is a basic liters-to-US-gallons converter using plain HTML and JavaScript:

<label for="liters">Liters</label>
<input
  id="liters"
  type="number"
  inputmode="decimal"
  placeholder="Enter liters"
/>

<p>
  Result:
  <output id="result">0 US gal</output>
</p>

<script>
  const US_GALLONS_PER_LITER = 0.264172052358;

  const input = document.getElementById("liters");
  const result = document.getElementById("result");

  function litersToUSGallons(liters) {
    return liters * US_GALLONS_PER_LITER;
  }

  function formatNumber(value, maxDecimals = 6) {
    return new Intl.NumberFormat("en-US", {
      maximumFractionDigits: maxDecimals,
    }).format(value);
  }

  function formatGallons(value) {
    if (Math.abs(value) < 1) {
      return formatNumber(value, 6);
    }

    if (Math.abs(value) < 100) {
      return formatNumber(value, 4);
    }

    return formatNumber(value, 2);
  }

  function parseInput(value) {
    if (value.trim() === "") {
      return null;
    }

    const number = Number(value);

    if (!Number.isFinite(number)) {
      return null;
    }

    return number;
  }

  input.addEventListener("input", () => {
    const liters = parseInput(input.value);

    if (liters === null) {
      result.textContent = "0 US gal";
      return;
    }

    const gallons = litersToUSGallons(liters);
    result.textContent = `${formatGallons(gallons)} US gal`;
  });
</script>

This is small, but it handles the important parts:

correct US gallon formula
readable output
empty input handling
mobile-friendly number input
no API request
clear unit label

9. Test the boring cases

Most converter bugs happen in boring places.

Test these first:

console.log(litersToUSGallons(0));
// 0

console.log(litersToUSGallons(1));
// 0.264172052358

console.log(litersToUSGallons(2));
// 0.528344104716

console.log(litersToUSGallons(10));
// 2.64172052358

console.log(litersToUSGallons(100));
// 26.4172052358

Also test the UI:

empty input
spaces only
decimal values
very small values
very large values
negative values
mobile keyboard input

A converter that only works for perfect input is not finished.

10. Add useful examples

A good converter should not only calculate.

It should also help users understand common values quickly.

Examples are useful:

1 L = 0.264172 US gal
2 L = 0.528344 US gal
5 L = 1.320860 US gal
10 L = 2.641721 US gal
20 L = 5.283441 US gal
100 L = 26.417205 US gal

These examples make the tool easier to trust.

They also help users check whether the result looks reasonable.

Final checklist

Before publishing a liters-to-gallons converter, check these:

Are you using US gallons or imperial gallons?
Does the UI clearly say which gallon type is used?
Is the conversion factor correct?
Is the result formatted clearly?
Does the input handle empty values?
Does the UI avoid showing NaN?
Does it work well on mobile?
Are common examples included?
Is an API really necessary?
Is the output accessible?

The formula is easy.

The real mistake is assuming “gallon” means the same thing everywhere.

That one detail can make the whole converter wrong.

You can test a live US-gallon version here: liters to gallons converter.

Claude Code: The Complete Setup Guide for macOS, Windows, and Linux

Dev Daily — Sun, 10 May 2026 10:28:18 +0000

Claude Code is Anthropic's official command-line agent for software engineering. It lives in your terminal, reads your repository, runs commands on your behalf, and edits files with a level of context awareness that no autocomplete can match. This guide walks you through installing it on macOS, Windows, and Linux, signing in, configuring your first project, and getting to a productive flow before lunch.

We'll skip the marketing and focus on the parts that actually matter — the install steps that fail silently if you skip them, the settings worth tweaking on day one, and the workflow patterns that make Claude Code feel like a senior engineer pairing with you instead of a fancier autocomplete.

What you'll learn

Installing Claude Code via the official installer or npm
Signing in with an Anthropic account or API key
Trusting your first project and running your first prompt
Configuring permissions, hooks, and MCP servers
A workflow checklist for daily use

Prerequisites

You need a working terminal, Node.js 18 or newer if you choose the npm install path, and an Anthropic account. A paid Claude.ai subscription gets you generous usage; otherwise an API key works the same way and bills per token.

macOS: any modern Mac (Apple Silicon or Intel) with Terminal or iTerm2.
Windows: Windows 10 or 11 with WSL2 strongly recommended for the Linux-flavored tooling.
Linux: any major distro with a recent shell.

Install on macOS

The fastest path on macOS is the official one-liner. It downloads the binary, places it in ~/.local/bin, and adds the directory to your shell PATH if it isn't already there.

# Official installer (recommended)
curl -fsSL https://claude.ai/install.sh | sh

# Verify
claude --version

If you prefer to keep all your CLIs managed by a package manager, you can use Homebrew or npm:

# Homebrew (community formula)
brew install anthropic/claude/claude

# Or via npm (works on every OS)
npm install -g @anthropic-ai/claude-code

Install on Windows

On Windows you have two reasonable options: native PowerShell or WSL2. Most teams pick WSL2 because the rest of the developer experience — Docker, Git, Node — works more smoothly there. Inside WSL2, follow the Linux steps below. For native Windows, install Node 18+ and run:

# In an Admin PowerShell
npm install -g @anthropic-ai/claude-code
claude --version

Note: If claude isn't found after install, restart your shell so the new PATH entry takes effect.

Install on Linux

# Recommended
curl -fsSL https://claude.ai/install.sh | sh

# Or with npm
npm install -g @anthropic-ai/claude-code

# Confirm
claude --version

Sign in for the first time

Run claude inside any terminal and follow the browser prompt. You'll authenticate against Anthropic, your local CLI will receive a session token, and subsequent runs won't need to log in again.

claude
# → opens a browser tab → sign in → return to the terminal

Prefer using a raw API key (e.g., for headless servers or CI)? Export it before launching:

export ANTHROPIC_API_KEY=sk-ant-...
claude

Trust your first project

Open a real repository — not your home folder — and start claude from inside it. The first time, Claude Code asks for permission to read and edit files in that directory. Approve it for the project root and you're ready to prompt.

cd ~/code/my-project
claude

Try a small, observable task first. Ask Claude to summarize the project, identify the entry points, or fix a tiny bug. The point is to see Claude read files, run commands, and propose edits before you trust it with larger work.

Configure on day one

Three settings pay for themselves immediately:

Permissions: in ~/.claude/settings.json, allow safe shell tools by default and require confirmation for destructive ones (anything that touches Git history, deletes files, or pushes to remotes).
Hooks: add a hook that runs your formatter and tests after every edit. The model gets immediate feedback when it breaks something.
MCP servers: wire up a database MCP server so Claude can read your schema, and a docs MCP server for your framework of choice.

A first-day workflow

Once installed, the actual productivity move is treating Claude Code like a junior engineer who happens to be very fast. Brief it like a colleague: explain the goal, point at the right files, share constraints, and review its diffs the way you'd review a teammate's pull request. Don't dump bare instructions and expect magic — context is what makes this work.

Start each session by orienting Claude: "Here is what we're working on, here is the relevant file, here is what success looks like."
Have it write tests before the implementation when you can — it forces the spec into the open.
Run a tight feedback loop: edit, test, commit. Don't let it stack ten changes without verification.

Troubleshooting

Most install failures fall into three buckets — corporate proxies blocking the install script, stale shell cache hiding the new PATH, or Node version mismatches when using the npm install path. Restart the shell, check which claude, and try the official installer if npm misbehaves.

Where to go next

Once you're set up, learn three concepts: slash commands for repeatable workflows, hooks for automatic verification after edits, and MCP servers for giving Claude access to data sources beyond the file system. We cover each in dedicated tutorials on the blog.

Originally published on DevDaily — practical engineering tutorials, daily.

We list 3 self-host PagerDuty alternatives. None of them are alive. (May 2026)

os-alt — Sun, 10 May 2026 10:24:24 +0000

The on-call OSS space has a problem. Of the three self-hostable PagerDuty alternatives our directory recommends, zero are currently alive.

Last week's first repo-health snapshot flagged ~11% of all listed self-host alternatives as not-alive. This week we're zooming in on the worst-affected single category: on-call rotation and incident paging. It's not 11%. It's 100%.

If you're paying $21–41/user/month for PagerDuty and were planning the self-host escape hatch, the directories you're staring at — including ours — are largely out of date. Here's what May 2026 actually looks like, and what to do instead.

The three we listed (and what their health pill says today)

Repo	Stars	Last commit	Archived	State
`grafana/oncall`	3,881	2026-03-24	yes	dead
`linkedin/oncall`	1,249	2025-08-20	no	stale
`cabotapp/cabot`	—	—	—	404 from GitHub API

Three projects, three different ways of being not-alive. Worth taking each one in turn — the failure modes generalize to any OSS-buying decision in 2026.

Grafana OnCall — archived two months ago

The most painful entry. Grafana archived their own on-call project on 2026-03-24. The repo's README points at "Grafana IRM" — Grafana's roadmap-rebranded successor. As of May 2026, IRM is a paid Grafana Cloud feature, not a self-host package.

For a self-hoster, that means: the codebase is frozen, no PRs accepted, the next features live behind a SaaS paywall. What makes this trap harder to spot is that the repo still has recent commits — the archive happened after a scramble of farewell fixes. A tool that surfaces only last_commit_at would tell you OnCall is fine. The signal that catches it is archived: true.

Lesson: when you're picking a self-host target, last-commit-recency is half the answer. The other half is the archive flag, and roughly a third of the "dead" repos in our snapshot are dead specifically because of archived: true, not because their commits dried up.

LinkedIn Oncall — nine months silent

LinkedIn's Oncall was always a partial story. It's the rotation/calendar layer; you paired it with linkedin/iris for actual paging. Two processes, MySQL underneath, a 2018-vintage UI. Acceptable trade-off if it shipped.

It hasn't. Nine months without a commit on a tool that needs to keep up with Twilio API versions, Slack Block Kit revisions, and Prometheus AlertManager schema is a real risk. Open-issue count is 78. The iris half (linkedin/iris) shows similar stagnation.

This is a textbook "acquihire-grade abandonment": a single open-source project that an internal team kept alive while a single maintainer was around, then stopped touching when that person rotated off. Not malicious, not formally dead — just no one driving.

Cabot — repo no longer exists

cabotapp/cabot returns 404 from the GitHub API today. Renamed, deleted, or transferred to a private namespace — we genuinely don't know which.

Cabot was the smallest install of the three: a Pingdom-plus-paging combo with just Postgres + Cabot. The minimal surface area made it attractive for tiny teams. But a 404 from api.github.com/repos/cabotapp/cabot means no clone, no fork, no historical issue tracker. Whatever knowledge was in there is — for any practical self-host purpose — gone.

We hold it as unknown in our snapshot rather than promoting it to dead, because someone might restore the namespace next month. But the 404 is itself the strongest "do not put this on a 2026 roadmap" signal we have.

Why the on-call vertical decays harder than most

A few observations from staring at this category specifically:

On-call tools live or die on integrations that age fast. Twilio outbound API versions, Slack Block Kit, Prometheus AlertManager schema, PagerDuty's own webhook format for receiving migrations. Six months of maintainer silence and you've got at least one of those broken. A static site generator can ship a single commit a year and still be useful. An on-call tool cannot.
The vendor money in this space is real. PagerDuty, Splunk On-Call, Opsgenie, FireHydrant — all well-funded SaaS with vested interest in killing OSS competition. Grafana OnCall arcing into Grafana IRM is the textbook end state: get acquired-by-roadmap, archive the public repo, sell the same code as a hosted feature.
It's a high-trust install. People deploy a status page on a whim. People do not deploy "the thing that decides who gets woken up at 3am" without serious vetting. So the user base of OSS on-call tools skews smaller and more demanding — which inverts the casual-contributor loop healthier OSS projects depend on.

The combination is brutal. You need ongoing integration maintenance, the vendors will hire away your one maintainer, and your user base is too small and too cautious to cushion the gap with PRs.

What you should actually self-host for paging in 2026

Two real options, neither of which is on our /pagerduty/ page yet — this is a directory bug we'll fix in the next sweep:

1. Keep — `keephq/keep`

11,805 stars, last commit yesterday (2026-05-09), AGPL-3.0
Bills itself as the open-source AIOps and alert management platform. Modern stack (Python + Next.js), active Discord, regular releases.
The clearest current self-host alternative to PagerDuty. Native integrations for Prometheus, Datadog, Sentry, Slack, Twilio. Workflow engine for routing rules.

The fact that we hadn't surfaced this on our /pagerduty/ page when we wrote it is the editorial bug this whole post is paying off. The June 2026 sweep will add it.

2. Hand-rolled: AlertManager + a calendar + Twilio

Deeply boring. Prometheus AlertManager handles routing. Google Calendar (or any calendar with an iCal feed) holds the rotation. A tiny webhook script translates "AlertManager fired → who's on call right now per the calendar → Twilio outbound call/SMS".

Not a product. Not a deploy. A weekend script. But it's what a lot of small teams have actually converged on while waiting for the OSS on-call market to settle, and it has zero supply-chain dependency on anyone else's roadmap.

What this means if you trusted our /pagerduty/ page last week

Honestly: the page is misleading right now. Our pill colors will tell you Grafana OnCall is dead, but the directory still lists it as the lead alternative. That's an editorial state we have to fix, not a "feature".

This is exactly the failure mode a freshness-first directory is supposed to catch quickly — and the reason we built the graveyard page (every dead/stale repo across our 100 SaaS pages, with backlinks to the SaaS each is listed under) and the public JSON API (so anyone aggregating us downstream gets the freshness signal too).

If you were planning a 2026 PagerDuty migration and our /pagerduty/ page was your starting point — thank you for reading carefully. Your fallback today is Keep, or hand-rolled AlertManager + calendar + Twilio. Don't put grafana/oncall, linkedin/oncall, or cabotapp/cabot on a 2026 self-host roadmap.

What's next

This is the second post in the monthly snapshot series. The May post established the overall ~11% not-alive headline. This post zooms in on the worst category. Future posts in this series will cover:

The first month-over-month diff (June 2026 — what flipped state)
Linktree-style "link in bio" tools (BioDrop dead, littlelink stale — same pattern, smaller stakes)
Form builders post-Typeform (ohmyform abandoned — what's actually shipping)

Want the diff post when it lands? Subscribe to the monthly digest from any SaaS page on the directory.

We'd rather you find out from us than from a git clone followed by a confused stare at the archive banner.

The `new` Keyword in JavaScript

Pratham — Sun, 10 May 2026 10:23:31 +0000

How JavaScript creates objects from blueprints — and what actually happens behind the scenes.

At some point in your JavaScript journey, you'll stop creating one-off objects and start thinking: "I need to create many objects that all have the same structure." Ten users. Fifty products. A hundred tasks. Each one has the same properties — name, email, role — but with different values.

You could write each one by hand:

const user1 = { name: "Pratham", role: "admin" };
const user2 = { name: "Arjun", role: "editor" };
const user3 = { name: "Priya", role: "viewer" };
// ... 97 more?

That doesn't scale. What you actually want is a blueprint — a template that says "every user has a name and a role" — and then a way to stamp out new objects from that blueprint. That's exactly what constructor functions and the new keyword give you.

This concept clicked for me during the ChaiCode Web Dev Cohort 2026, and it's one of those fundamentals that connects directly to how classes, React components, and object-oriented patterns work. Let me walk you through it.

What Does the `new` Keyword Do?

The new keyword creates a new object from a constructor function. It automates a bunch of steps that you'd otherwise have to do manually.

In one sentence: new takes a blueprint (constructor function) and produces an instance (a new object) based on that blueprint.

Think of it like a cookie cutter. The constructor function is the cutter (the shape). Every time you press it into dough (use new), you get a new cookie (a new object) — same shape, but each one is its own cookie.

Constructor Function (blueprint)
         ↓
     new keyword
         ↓
  New Object (instance)

Constructor Functions — The Blueprint

A constructor function is a regular function that's designed to be called with new. By convention, constructor function names start with a capital letter to distinguish them from regular functions.

Basic Example

function User(name, role) {
  this.name = name;
  this.role = role;
}

const user1 = new User("Pratham", "admin");
const user2 = new User("Arjun", "editor");
const user3 = new User("Priya", "viewer");

console.log(user1); // User { name: "Pratham", role: "admin" }
console.log(user2); // User { name: "Arjun", role: "editor" }
console.log(user3); // User { name: "Priya", role: "viewer" }

Three objects, all with the same structure, created from one blueprint. Each one is its own independent object — changing user1.name doesn't affect user2.

Adding Methods to the Constructor

function User(name, email) {
  this.name = name;
  this.email = email;
  this.greet = function () {
    console.log(`Hi, I'm ${this.name} (${this.email})`);
  };
}

const pratham = new User("Pratham", "pratham@prathamdev.in");
pratham.greet(); // "Hi, I'm Pratham (pratham@prathamdev.in)"

const arjun = new User("Arjun", "arjun@example.com");
arjun.greet(); // "Hi, I'm Arjun (arjun@example.com)"

Each instance gets its own name, email, and greet method. The constructor function acts as a factory — you feed it values, and it produces fully formed objects.

The Object Creation Process — Step by Step

This is the part that most tutorials gloss over, but understanding what new actually does behind the scenes is what separates surface-level knowledge from real understanding.

When you write new User("Pratham", "admin"), JavaScript does four things automatically:

Step 1: Create a New Empty Object

// JavaScript internally does:
const obj = {};

A brand-new, empty object is created. This is the object that will eventually be returned.

Step 2: Link the Object's Prototype

// JavaScript internally does:
obj.__proto__ = User.prototype;

The new object's internal prototype is linked to the constructor function's prototype property. This is how the object inherits shared methods (more on this shortly).

Step 3: Call the Constructor with `this` = New Object

// JavaScript internally does:
User.call(obj, "Pratham", "admin");

The constructor function runs, but this inside it refers to the new empty object. So this.name = name becomes obj.name = "Pratham", and the object gets populated with properties.

Step 4: Return the New Object

// JavaScript internally does:
return obj;

Unless the constructor explicitly returns a different object, JavaScript automatically returns the newly created and populated object.

The Complete Picture

new User("Pratham", "admin")

  Step 1:  {} (empty object created)
             ↓
  Step 2:  {}.__proto__ → User.prototype (linked)
             ↓
  Step 3:  User runs with this = {}
           this.name = "Pratham"
           this.role = "admin"
           Now: { name: "Pratham", role: "admin" }
             ↓
  Step 4:  Return { name: "Pratham", role: "admin" }

Result:  user1 = { name: "Pratham", role: "admin" }

Simulating `new` Manually

To really drive this home, here's what new does — written as regular code:

function fakeNew(Constructor, ...args) {
  // Step 1: Create empty object
  const obj = {};

  // Step 2: Link prototype
  Object.setPrototypeOf(obj, Constructor.prototype);

  // Step 3: Call constructor with this = obj
  Constructor.apply(obj, args);

  // Step 4: Return the object
  return obj;
}

function User(name, role) {
  this.name = name;
  this.role = role;
}

const user = fakeNew(User, "Pratham", "admin");
console.log(user); // { name: "Pratham", role: "admin" }
console.log(user instanceof User); // true ✅

That fakeNew function does exactly what new does. Understanding these four steps means you truly understand new.

Constructor → Instance Creation Flow

┌──────────────────────────────────────────────────────────┐
│                  Constructor Function                     │
│                                                           │
│   function Product(name, price) {                        │
│     this.name = name;                                     │
│     this.price = price;                                   │
│   }                                                       │
└────────────────────┬─────────────────────────────────────┘
                     │
         ┌───────────┼───────────┐
         ↓           ↓           ↓
    new Product  new Product  new Product
   ("Laptop",   ("Phone",    ("Headphones",
     75000)       25000)        3000)
         ↓           ↓           ↓
┌────────────┐ ┌────────────┐ ┌─────────────┐
│  Instance  │ │  Instance  │ │  Instance    │
│            │ │            │ │              │
│ name:      │ │ name:      │ │ name:        │
│  "Laptop"  │ │  "Phone"   │ │ "Headphones" │
│ price:     │ │ price:     │ │ price:       │
│  75000     │ │  25000     │ │  3000        │
└────────────┘ └────────────┘ └─────────────┘

One blueprint → many instances.
Each instance is independent.

How `new` Links Prototypes

Here's where things get powerful. Remember Step 2 — linking the prototype? This is how instances share methods without duplicating them.

The Problem Without Prototypes

function User(name) {
  this.name = name;
  this.greet = function () {
    console.log(`Hi, I'm ${this.name}`);
  };
}

const user1 = new User("Pratham");
const user2 = new User("Arjun");

console.log(user1.greet === user2.greet); // false!

Each instance gets its own copy of the greet function. If you create 1,000 users, that's 1,000 copies of the same function in memory. Wasteful.

The Solution: Prototype Methods

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

// Shared method — lives on the prototype, not on each instance
User.prototype.greet = function () {
  console.log(`Hi, I'm ${this.name}`);
};

const user1 = new User("Pratham");
const user2 = new User("Arjun");

user1.greet(); // "Hi, I'm Pratham"
user2.greet(); // "Hi, I'm Arjun"

console.log(user1.greet === user2.greet); // true! ✅ Same function in memory

Both instances use the same greet function from User.prototype. One copy in memory, shared by all instances.

Prototype Linking Visual

                User.prototype
               ┌─────────────────────┐
               │ greet: function()   │  ← shared method (one copy)
               └──────────┬──────────┘
                          │
           ┌──────────────┼──────────────┐
           ↓              ↓              ↓
    ┌────────────┐  ┌────────────┐  ┌────────────┐
    │   user1    │  │   user2    │  │   user3    │
    │            │  │            │  │            │
    │ name:      │  │ name:      │  │ name:      │
    │ "Pratham"  │  │ "Arjun"    │  │ "Priya"    │
    │            │  │            │  │            │
    │ __proto__──┤  │ __proto__──┤  │ __proto__──┤
    │   → User  │  │   → User  │  │   → User  │
    │  .prototype│  │  .prototype│  │  .prototype│
    └────────────┘  └────────────┘  └────────────┘

    Each instance has its own "name" (data).
    All instances SHARE "greet" via the prototype chain.

When you call user1.greet(), JavaScript:

Looks for greet on user1 → not found
Follows __proto__ to User.prototype → found!
Runs it with this = user1

This is the prototype chain — JavaScript's inheritance mechanism.

Instances Created from Constructors

Every object created with new is an instance of its constructor. You can verify this with instanceof:

function Car(brand, model) {
  this.brand = brand;
  this.model = model;
}

const myCar = new Car("Toyota", "Camry");
const myBike = { brand: "Honda", model: "Activa" };

console.log(myCar instanceof Car); // true ✅
console.log(myBike instanceof Car); // false ❌

myCar was created with new Car(), so it's an instance of Car. myBike is a plain object literal — no constructor involved.

Multiple Instances, Independent Data

function Task(title, priority) {
  this.title = title;
  this.priority = priority;
  this.completed = false;
}

Task.prototype.complete = function () {
  this.completed = true;
  console.log(`✅ "${this.title}" marked as complete.`);
};

const task1 = new Task("Learn JavaScript", "high");
const task2 = new Task("Write article", "medium");
const task3 = new Task("Push to GitHub", "low");

task1.complete();
// ✅ "Learn JavaScript" marked as complete.

console.log(task1.completed); // true
console.log(task2.completed); // false — independent!
console.log(task3.completed); // false — independent!

Each instance has its own data, but shares methods through the prototype. This is the foundation of object-oriented programming in JavaScript.

What Happens Without `new`?

This is a common mistake — calling a constructor function without new:

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

// With new — works correctly
const user1 = new User("Pratham");
console.log(user1); // User { name: "Pratham" } ✅

// Without new — BAD!
const user2 = User("Arjun");
console.log(user2); // undefined ❌
console.log(window.name); // "Arjun" — accidentally polluted global scope!

Without new:

No new object is created
this becomes the global object
Properties get attached to window (in browsers)
The function returns undefined (no explicit return)

That's why the capital-letter convention exists — it signals "use new with this function." And that's why ES6 classes (which we'll cover later) enforce new automatically.

Let's Practice: Hands-On Assignment

Part 1: Create a Constructor Function

function Student(name, age, course) {
  this.name = name;
  this.age = age;
  this.course = course;
}

Student.prototype.introduce = function () {
  console.log(`I'm ${this.name}, ${this.age}, studying ${this.course}.`);
};

Part 2: Create Multiple Instances

const s1 = new Student("Pratham", 22, "Web Dev Cohort 2026");
const s2 = new Student("Arjun", 21, "Data Science");
const s3 = new Student("Priya", 23, "Machine Learning");

s1.introduce(); // "I'm Pratham, 22, studying Web Dev Cohort 2026."
s2.introduce(); // "I'm Arjun, 21, studying Data Science."
s3.introduce(); // "I'm Priya, 23, studying Machine Learning."

Part 3: Verify Instances and Shared Methods

console.log(s1 instanceof Student); // true
console.log(s2 instanceof Student); // true

// All instances share the same introduce method
console.log(s1.introduce === s2.introduce); // true ✅
console.log(s2.introduce === s3.introduce); // true ✅

Part 4: Add More Prototype Methods

Student.prototype.changeCourse = function (newCourse) {
  const old = this.course;
  this.course = newCourse;
  console.log(`${this.name} switched from ${old} to ${newCourse}.`);
};

s1.changeCourse("Full-Stack Development");
// "Pratham switched from Web Dev Cohort 2026 to Full-Stack Development."

s1.introduce();
// "I'm Pratham, 22, studying Full-Stack Development."

Key Takeaways

The new keyword creates a new object from a constructor function. It automates object creation, prototype linking, and returning.
Constructor functions are blueprints for creating multiple objects with the same structure. Name them with a capital letter by convention.
new performs four steps: create empty object → link prototype → run constructor with this = new object → return the object.
Prototype methods are shared across all instances — one copy in memory instead of one per object. This is efficient and is the basis of JavaScript's inheritance.
Every object created with new is an instance of its constructor, verifiable with instanceof.

Wrapping Up

The new keyword is one of those foundational pieces that connects everything in JavaScript's object model. Constructor functions give you blueprints. new gives you instances. Prototypes give you shared behavior. Together, they form the basis of object-oriented JavaScript — and they're exactly what ES6 classes are built on top of (classes are just syntactic sugar over constructors and prototypes).

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg, and understanding new was the moment prototypes stopped being abstract theory and became something I could actually use. If you're building towards classes and React, this is essential groundwork.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

How Naver Leads Multimodal AI Search Innovation

lifes koreaplus — Sun, 10 May 2026 10:20:39 +0000

The tech world is currently buzzing with the rapid advancements in multimodal AI – systems that seamlessly understand and process text, images, audio, and even video. From OpenAI's GPT-4V to Google's Gemini, the promise of more intuitive and context-aware interactions is finally becoming a tangible reality. As engineers, we're keenly watching how these innovations will reshape user experiences and development paradigms. But what if I told you that a major player has been quietly perfecting this art, integrating sophisticated multimodal understanding into its core services for over a decade, long before it became a global buzzword? Enter Naver, South Korea's leading internet company, whose journey offers invaluable lessons for anyone building the next generation of AI-powered platforms.

Pioneering Multimodal Fusion in the Early Days

A decade ago, the landscape for building advanced AI was vastly different. Computational resources were scarcer, deep learning frameworks were nascent, and large-scale multimodal datasets were a distant dream. This is precisely the challenging environment in which Naver began its deep dive into multimodal AI. While global giants are now rolling out advanced features, Naver was solving the fundamental engineering problems of integrating disparate data streams – text from queries, images from user uploads, audio from voice commands – into a cohesive search experience. This wasn't about simply adding a visual search tab; it was about truly fusing these modalities at a deeper, semantic level within their search engine architecture.

The technical implications of this early commitment are profound. It necessitated significant in-house research and development into cross-modal embedding techniques, robust data pipelines capable of handling diverse formats at scale, and custom model architectures designed for efficient inference across multiple input types. Imagine building a recommendation engine that doesn't just look at product descriptions, but also visually analyzes product images and understands the emotional tone of user reviews, all while ensuring low latency for millions of users. Naver’s engineering teams had to develop proprietary solutions for aligning feature spaces from different modalities, allowing their systems to derive a richer, more contextual understanding of user intent and information relevance, long before off-the-shelf solutions were available.

Engineering for Deep Contextual Understanding

The real power of Naver's decade-long investment isn't just in *what* they built, but *how* it translated into a deeply contextual and intuitive user experience. For a developer, this means moving beyond keyword matching or simple image recognition. It implies a system that can understand a query like "show me restaurants near here with outdoor seating that are dog-friendly" and instantly filter results by combining location data, image analysis (to identify outdoor seating in restaurant photos), and text analysis of reviews (for "dog-friendly" mentions). This level of contextual understanding requires a sophisticated interplay of natural language processing (NLP), computer vision (CV), and speech recognition (ASR) modules, all contributing to a unified understanding of the user's need.

Naver's approach demonstrates a critical engineering insight: multimodal AI is not just about stacking models, but about creating synergistic feedback loops. Their search engine, for instance, learns from how users interact with image results after a text query, or how voice queries lead to specific video consumption. This continuous learning, fueled by a vast, diverse dataset gathered over many years across services like search, e-commerce, and mapping, has allowed them to refine their cross-modal representations and fusion strategies. This iterative process of data collection, model training, deployment, and feedback loop closure is the bedrock of their advanced, intuitive platforms, providing a blueprint for how to build truly intelligent systems that anticipate user needs rather than just reacting to explicit inputs.

The Data Moat and Future-Proofing AI

A decade of multimodal data collection and model refinement has created a formidable "data moat" for Naver. This isn't just about having a lot of data; it's about having *diverse, interconnected* multimodal data, meticulously curated and tagged from real-world user interactions across a rich ecosystem of services. This proprietary dataset is a goldmine for training and fine-tuning advanced foundational models, giving Naver a distinct advantage in developing highly specialized and accurate AI for the Korean language and cultural context, which is often a challenge for global models.

From an engineering perspective, this deep data resource enables faster iteration, more robust model performance, and the ability to explore cutting-edge AI applications from a position of strength. It means they can push the boundaries into areas like hyper-personalized content generation, advanced conversational AI, and even sophisticated AI-powered content moderation, all underpinned by a holistic understanding of information across modalities. Naver's journey illustrates that while foundational models are powerful, the true competitive edge in the AI era will increasingly belong to those who can effectively leverage their unique data assets and integrate multimodal intelligence deeply into their platform architecture, preparing them for the next wave of AI innovation, whether it's embodied AI or advanced synthetic media generation.

For the full deep-dive — market data, company financials, and strategic analysis — read the complete article on KoreaPlus.

Popcorn Movies and TV

Synchronous vs Asynchronous JavaScript

What Does Synchronous Code Mean?

Synchronous Execution Timeline

The Problem: Blocking Code

Real-World Example: Waiting for Data

Code Example of Blocking

What Does Asynchronous Code Mean?

Why JavaScript Needs Asynchronous Behavior

Asynchronous Examples: Timers and API Calls

setTimeout — The Simplest Async Example

The Zero-Delay Mystery (Explained!)

setInterval — Repeat at Intervals

API Calls with fetch (Preview)

The Asynchronous Task Queue Concept

Step-by-Step Trace

Synchronous vs Asynchronous — Side by Side

Everyday Analogy

Problems That Occur with Blocking Code

1. Frozen UI

2. Poor User Experience

3. Timeouts and Failures

4. Wasted Resources

Let's Practice: Hands-On Assignment

Part 1: Predict the Output

Part 2: Simulate Async Data Loading

Part 3: Experience Blocking vs Non-Blocking

Key Takeaways

Wrapping Up

Coding Cat Oran S2 Ep1 — The Excel Republic

Learning Xahau: Debunking Common Myths About Xahau

1. “Xahau Is an XRP Ledger Sidechain”

2. “Projects Built on Xahau Don’t Actually Use XAH”

3. “Hooks Are Just Ethereum Smart Contracts”

4. “The XAH You See on XRPL Is Native XAH”

5. “Xahau Is Just XRP Ledger With Smart Contracts”

6. “Hooks Are Dangerous Because They Can Do Anything”

7. “Xahau Depends on Ripple”

8. “Xahau Is Trying to Compete With Every Other Blockchain”

Final Thoughts

Why Your RAG Chatbot Looks Great in Week 1 and Hallucinates by Month 2

🔍 Why RAG Fails in Production (It's Not the Model)

🧠 Rule 1: Evals Before Prompts

🛠 Rule 2: One Source of Truth

🎯 Rule 3: Fallback Over Hallucination

💡 Rule 4: Observability from Day One

Key Takeaways

👋 Let's Connect

I Built Graphode — An AI-Powered GitHub Repository Visualizer

I Built Graphode — An AI-Powered GitHub Repository Visualizer

What is Graphode?

Watch it in action:

Features

Perfect For

Try it free

Building Echovault During a 130,000 Person Hackathon

The Stack

The Disaster Moment

The Result

Why We Render Everything in the Browser

The Axiom

The Origin

The Cost

The Question

The Most Common Bug in Liters to Gallons Converters

1. Be clear: US gallons or imperial gallons?

2. Use readable constants

3. Format the result before showing it

4. Use smart precision

5. Handle empty and invalid input

6. Decide whether negative values are allowed

7. Build the converter client-side

8. Minimal working example

9. Test the boring cases

10. Add useful examples

Final checklist

Claude Code: The Complete Setup Guide for macOS, Windows, and Linux

What you'll learn

Prerequisites

Install on macOS

`setTimeout` — The Simplest Async Example

`setInterval` — Repeat at Intervals

API Calls with `fetch` (Preview)

1. Keep — `keephq/keep`

What Does the `new` Keyword Do?

Step 3: Call the Constructor with `this` = New Object

Simulating `new` Manually

How `new` Links Prototypes

What Happens Without `new`?