DEV Community: aarthirs

DesiPasta — Italian Comfort, Indian Soul 🍝

aarthirs — Fri, 14 Aug 2026 14:08:50 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I built DesiPasta, a minimal interactive single-page experience celebrating Indian-style pasta.

Pasta is traditionally associated with Italian cuisine, but at home, we have a way of making almost everything our own. This concept imagines a bowl of pasta cooked with Indian spices, vegetables, and that familiar homemade comfort.

The goal was to make the website feel like the food itself — warm, playful, colourful, and comforting.

The Design

The page uses:

A warm Indian-inspired cream, orange, and green palette
Large editorial typography
A 3D-inspired pasta hero composition
Floating food elements and subtle depth
Minimal UI instead of a traditional navigation-heavy layout
Recipe information revealed through interaction
Responsive design for desktop and mobile

The main interaction is intentionally simple:

Get the Recipe → reveal the complete recipe

I wanted the interaction to feel like opening a recipe card rather than navigating to another page.

Technical Highlights

Built using:

HTML
CSS
Vanilla JavaScript
CSS 3D transforms
Mouse-based 3D parallax
CSS animations
Responsive CSS
Accessible interactive controls

One of the things I particularly enjoyed was experimenting with CSS perspective and transforms to make the food composition feel more dimensional without turning the entire page into a complicated 3D experience.

Demo

codepen.io/aarthi

What I Learned

This challenge reminded me that a good frontend experience doesn't necessarily need dozens of components or complicated interactions.

Sometimes one strong visual, one meaningful interaction, and a clear story are enough.

For me, DesiPasta is a small love letter to the way food becomes part of home and culture. ❤️

Food is not just fuel, it's a feeling of home.

Thanks to the DEV Community for another fun frontend challenge!

⚙️I Thought I Was Solving Localization. I Ended Up Building an Industrial Vocabulary Engine.

aarthirs — Thu, 30 Jul 2026 09:09:36 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

⚙️I Thought I Was Solving Localization. I Ended Up Building an Industrial Vocabulary Engine.

When I picked up this task, I thought it was just another localization feature.

You know the drill—create language files, wrap labels with translation keys, fetch the dictionary, and call it a day.

I even estimated two days.

Then the first client requirement landed.

"This should say CNC Machine for Client A, Blow Moulding Unit for Client B, and Injection Press for Client C."

Same screen.

Same database row.

Same physical machine.

Three different names.

At that moment I realized I wasn't solving a localization problem anymore.

I was solving an industrial vocabulary problem.

In manufacturing, operators don't think in generic software terms. They think in the language they've used every day for years. If someone has always called a machine "Blow-2", your beautifully designed dashboard instantly loses credibility the moment it says "Machine 12."

That one requirement slowly expanded beyond machines.

Soon I had to support moulds, products, RFID stations, manual entry forms, production dashboards, alarms, and reports.

What started as "translate a few labels" became building a scalable engine capable of handling an entire industrial ecosystem.

🏭 The Stack

There wasn't anything fancy about the project.

HTML
JavaScript
PHP

No build tools.

No third-party localization framework.

So the solution had to stay lightweight.

I built a runtime translation engine using data-i18n attributes and a MutationObserver so dynamically injected content could be translated automatically.

<div class="asset-card">
    <span data-i18n="asset.machine.label">Machine</span>
    <span data-i18n="asset.status.running">Running</span>
</div>

The first version looked perfectly reasonable.

function translate(root) {
    root.querySelectorAll("[data-i18n]").forEach((element) => {
        const key = element.dataset.i18n;
        const translation = translations.find(t => t.key === key);

        if (translation) {
            element.textContent = translation.value;
        }
    });
}

It worked beautifully during development.

Which, as every engineer knows, is usually when the real problems are still politely waiting for production.

🐞 The Bug That Didn't Look Like a Bug

Nothing crashed.No red errors in the console.The dashboard simply became... slower.

Profiling eventually revealed the culprit.Every time I translated text, I modified the DOM.

Every DOM modification triggered the MutationObserver.

Which called the translator again.

Which modified the DOM again.

Thankfully it wasn't an infinite loop, but it was enthusiastically doing the same work hundreds of times.

To make things worse, every lookup searched an array linearly.

One translated element wasn't expensive.

Thousands certainly were.

🔧 Small Changes, Big Difference

The solution wasn't rewriting everything.

It was removing unnecessary work.

First, I converted the translation list into a Map.

const dictionary = new Map();

translations.forEach(item => {
    dictionary.set(item.key, item.value);
});

Now every lookup became constant time instead of repeatedly scanning the entire array.

Next, I gave translated elements a memory.

Instead of translating every node repeatedly, I stored a small version stamp.

<span
    data-i18n="asset.machine.label"
    data-i18n-done="en:v3">
</span>

If an element had already been translated for the current dictionary version, it was skipped.

Finally, I temporarily disconnected the MutationObserver while applying updates.

That one change stopped the observer from reacting to its own work.

Sometimes debugging feels like arguing with yourself.

In this case, the DOM literally was.

📈 Scaling Beyond Machines

Performance was only half the problem.

The more interesting challenge was designing something that would continue working as the application grew.

Initially I considered maintaining separate translation files for every client.

That approach lasted about five minutes.

Every new feature meant updating multiple dictionaries, and eventually someone would forget one.

Instead, I designed a layered vocabulary system.

The server resolved the correct terminology for each client and sent one flattened dictionary to the browser.

The frontend didn't need to know whether a label came from a client override, an industry profile, or the default language.

It simply performed one lookup.

The exact same engine eventually handled:

Domain	Example
Machines	CNC Machine, Blow Moulding Unit
Moulds	Client-specific mould names
Products	Factory terminology
RFID Stations	Scanner labels
Manual Entry Forms	Operator-friendly field names

The code never changed.

Only the vocabulary did.

That turned out to be one of the biggest wins of the project.

📊 Before / After

	Before	After
Lookup cost per key	`O(n)` array scan	`O(1)` Map read
Re-processing already-resolved nodes	Every pass	Never (guard stamp)
Observer reacting to its own writes	Yes	No (disconnect + rAF batch)
Writes per navigation (dense screen)	~2,400	~0 for unchanged nodes
Visible label flicker	Yes	Gone
Language switch	Full manual re-render	Bump `version`, DOM self-heals

💡 What This Project Taught Me

Every production bug teaches something.

This one taught me that solving the immediate problem isn't always enough—you have to understand the domain behind it.

A few lessons have stayed with me ever since:

Build for change, not just today's requirements. What started as machine labels quickly expanded to moulds, products, RFID stations, manual entry forms, and dashboards. A flexible design saved countless future changes.
Generic solutions outlast duplicated ones. One reusable vocabulary engine proved far more maintainable than creating separate implementations for every client.
Model your data carefully. Once the vocabulary became structured data instead of hardcoded strings, the UI became simpler, faster, and easier to extend.
Performance is often about eliminating unnecessary work. Converting lookups to a Map helped, but the biggest improvement came from preventing repeated translations in the first place.
Technology should adapt to the business—not the other way around. Every factory had its own terminology, and the software needed to respect that rather than forcing a single vocabulary.

Looking back, the biggest improvement wasn't the optimization itself—it was designing an architecture that could evolve as the business grew.

🎯 Looking Back

When I accepted this task, I expected to build a simple localization feature.

Instead, I ended up designing a scalable vocabulary engine that now supports machines, moulds, products, RFID workflows, manual entry forms, and multiple industrial domains—all using the same underlying architecture.

The most valuable lesson wasn't learning how to optimize a MutationObserver or replace an array with a Map.

It was realizing that in industrial software, words are part of the domain model.

The labels on a screen aren't just UI text—they represent years of operational knowledge and the language people trust every day.

Once I started treating vocabulary as business data instead of presentation text, many architectural decisions became surprisingly clear.

I started by solving one machine.

I ended up building a platform capable of understanding an entire industrial ecosystem. 🚀

From LeetCode to Production: What the Boyer-Moore Voting Algorithm Taught Me

aarthirs — Tue, 14 Jul 2026 06:47:08 +0000

Like many developers, I spend part of my free time solving LeetCode problems. Recently, I came across Majority Element II, which asks us to find all elements that appear more than ⌊n/3⌋ times.

My first instinct was the obvious one—use an unordered_map to count frequencies.

It worked.

It passed every test case.

Then I noticed the follow-up:

Can you solve it in O(n) time using O(1) extra space?

That single constraint completely changed the way I looked at the problem.

Instead of asking:

"How do I count frequencies?"

I started asking:

"How can I identify frequent elements without storing every frequency?"

That question led me to the Boyer-Moore Voting Algorithm.

🤯 The "Wait... How Does This Even Work?" Moment

At first, the algorithm honestly felt like magic.

How can you find the majority element without actually counting everything?

The answer is surprisingly elegant.

Instead of keeping track of every element, we maintain only a few potential candidates along with their counters.

Whenever we encounter:

the same candidate → increase its vote
a different number while a counter is available → make it the new candidate
a completely different number while both candidates are active → decrease both counters

Instead of counting frequencies, the algorithm lets different values cancel each other out.

Imagine every element casting a vote. Whenever two different values compete, they cancel each other's votes. By the end of the first pass, only the elements with enough "support" remain as potential candidates.

💡 Key Takeaway

One of the most elegant properties of the Boyer-Moore Voting Algorithm is:

For a problem where an element must appear more than ⌊n/k⌋ times, you only need to track k − 1 candidates.

Why?

Because there can never be k distinct elements, each occurring more than ⌊n/k⌋ times. Their combined occurrences would exceed n, which is impossible.

For Majority Element II, the threshold is ⌊n/3⌋, so there can be at most two majority elements.

That's why we only maintain:

2 candidate buckets
2 counters

instead of storing frequencies for every unique number.

🧠 The Core Idea

The heart of the algorithm looks something like this:

for (int num : nums) {
    if (num == candidate1)
        count1++;
    else if (num == candidate2)
        count2++;
    else if (count1 == 0) {
        candidate1 = num;
        count1 = 1;
    }
    else if (count2 == 0) {
        candidate2 = num;
        count2 = 1;
    }
    else {
        count1--;
        count2--;
    }
}

Notice that this doesn't guarantee the candidates are actual majority elements.

It simply identifies the most likely candidates after all possible cancellations.

That's why the algorithm performs a second pass to verify whether these candidates actually occur more than ⌊n/3⌋ times.

This two-pass approach is what allows Boyer-Moore to achieve:

Time Complexity: O(n)
Space Complexity: O(1)

🚀 Then I Started Thinking Beyond LeetCode...

Once I understood the algorithm, I realized something interesting.

The optimization wasn't just about passing an interview.

It was about thinking differently when memory is limited.

Imagine you're building a backend service processing millions of events every second.

You're monitoring:

API requests
User IDs
Search queries
Clickstream events
Network traffic

Keeping a frequency map for every unique value isn't always practical.

As the number of unique items grows, so does the memory required to store them.

Instead, modern streaming systems rely on algorithms that summarize data while using a fixed amount of memory.

The Boyer-Moore Voting Algorithm is a perfect example of this mindset.

Rather than remembering everything, it continuously filters out less significant data and preserves only the strongest candidates.

That idea appears repeatedly in large-scale systems where memory is a precious resource.

Whether it's identifying heavy hitters in a data stream, processing telemetry, or analyzing high-volume events, engineers often prefer algorithms that make intelligent trade-offs instead of storing every detail.

💭 What This Problem Actually Taught Me

Before solving this problem, I viewed algorithms as interview questions.

Now I see them as engineering decisions.

The follow-up constraint wasn't there just to make the question harder.

It was teaching an important design principle:

Sometimes the smartest solution isn't storing more information—it's figuring out what information you can safely discard.

That realization changed the way I think about optimization.

🎯 My Takeaway

If you're grinding LeetCode, don't stop once you get the green Accepted badge.

Instead, ask yourself:

Why does this optimization exist?
What real-world limitation is it solving?
Where would this idea actually be useful in production?
What trade-offs is this algorithm making?

For me, the Boyer-Moore Voting Algorithm wasn't just another optimization problem.

It became a reminder that great software engineering isn't about using more memory or writing more code.

It's about building solutions that remain efficient even when the scale grows beyond what brute force can handle.

Sometimes, one LeetCode problem can teach a system design lesson you'll carry throughout your engineering career.

Have you ever learned an interview algorithm that completely changed how you think about software engineering?

I'd love to hear your story in the comments. 👇

Passion Journal AI - Weekend Challenge

aarthirs — Sun, 12 Jul 2026 11:28:56 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Passion Journal AI is an AI-powered journaling application that helps users reflect on what they're passionate about.

Instead of simply storing journal entries, the application analyzes each reflection using Google Gemini AI to identify:

Primary Passion
Mood
Passion Score
AI Reflection
Personalized Goal

It also tracks progress through a modern analytics dashboard with:

Weekly trend charts
Daily streaks
Previous journal history
Progress statistics

The idea came from the challenge theme "Passion."

Passion isn't only about sports or hobbies—it can also be about learning, building, reading, coding, exercising, or anything that motivates us to improve every day.

I wanted to build an application that encourages users to reflect on those passions instead of letting them fade into everyday routines.

Demo

🌐 Live Application URL : Passion_Journal_AI

Code

GitHub Repository : github

How I Built It

I built the project as a complete full-stack application.

Frontend

React
Vite
Tailwind CSS
Context API
Custom Hooks
Recharts
Axios

The dashboard was designed with reusable components to keep the UI modular and maintainable.

Backend

The backend uses:

Node.js
Express.js

The server exposes an API that receives journal entries and forwards them to Google Gemini AI.

AI Integration

Google Gemini analyzes every journal and returns structured JSON containing:

Passion
Mood
Passion Score
Reflection
Goal

To make the application more reliable, I also implemented a rule-based fallback engine. If the AI service is unavailable or returns invalid data, the application still generates meaningful insights using keyword analysis.

Architecture Decisions

Some design decisions I focused on:

Context API for centralized state management
Reusable service layer for API communication
Component-based UI architecture
Local Storage persistence
Validation before AI requests
Responsive dashboard layout
Clean separation between frontend and backend

Challenges

One interesting challenge was ensuring that AI responses were always usable.

Large Language Models don't always return perfectly formatted JSON, so I added:

Response validation
JSON cleanup
Score normalization
Fallback rule engine

This made the application much more resilient.

Another challenge was designing an interface that presents AI insights without overwhelming the user. I iterated on the layout to balance journaling, analytics, and reflection in a clean dashboard.

What I Learned

This project helped me gain hands-on experience with:

Google Gemini API
Prompt engineering
AI response validation
React Context API
Dashboard architecture
Building production-style full-stack applications

More importantly, it reinforced how AI can support personal growth—not by replacing reflection, but by making it more meaningful.

Prize Categories

🏆 Best Use of Google AI

Google Gemini powers the core experience of Passion Journal AI by analyzing journal entries and generating structured insights, reflections, and goals. The application also includes validation and a fallback analysis engine to ensure a reliable user experience.

Thank you to the DEV team for organizing this challenge. It was a great opportunity to combine AI, full-stack development, and a meaningful theme into one project.

MongoDB Indexes Finally Clicked for Me: Understanding Indexes, Compound Indexes & the Prefix Rule 🚀

aarthirs — Wed, 24 Jun 2026 09:34:53 +0000

While working on a MERN project, I came across these indexes:

transactionSchema.index({ user: 1, date: -1 });
transactionSchema.index({ user: 1, type: -1 });
transactionSchema.index({ user: 1, category: -1 });

My first reaction was:

"Why are we creating 3 different indexes for the same schema? Isn't one index enough?"

At that time, my understanding was:

"Indexes help MongoDB find records faster."

Which is true, but it wasn't enough to explain why multiple indexes existed for the same collection.

That simple doubt led me down a rabbit hole of learning about indexes, compound indexes, how MongoDB stores them, and the famous Prefix Rule.

Here's what I learned.

What is an Index?

Imagine a collection with millions of transactions.

db.transactions.find({
  user: "Aarthi"
});

Without an index, MongoDB may need to inspect every document until it finds the matching records.

This is called a Collection Scan.

Think of it like searching for a chapter in a book without a table of contents. You'd have to flip through page after page until you find it.

An index works like a book's table of contents.

Instead of scanning every document, MongoDB can jump directly to the relevant records.

Example:

db.transactions.createIndex({
  user: 1
});

Now MongoDB can quickly locate all transactions belonging to a specific user.

What is a Compound Index?

A compound index contains multiple fields.

Example:

db.transactions.createIndex({
  user: 1,
  date: -1
});

This means MongoDB organizes the index by:

user
  └── date

Conceptually, it looks something like:

Aarthi
   2025-08-10
   2025-08-09
   2025-08-08

John
   2025-08-10
   2025-08-05

The data is first grouped by user, and within each user, it is ordered by date.

Now queries like:

db.transactions.find({
  user: "Aarthi"
}).sort({
  date: -1
});

become very efficient.

MongoDB can jump directly to Aarthi's records and retrieve them in date order.

The Prefix Rule: The Concept That Finally Made It Click

Consider this index:

{
  user: 1,
  date: -1
}

MongoDB can efficiently use it for:

find({
  user: "Aarthi"
});

✅ Works

find({
  user: "Aarthi",
  date: "2025-08-10"
});

✅ Works

But:

find({
  date: "2025-08-10"
});

❌ Not efficient

Why?

Because the index is organized by user first and then by date.

MongoDB knows where each user's records start, but it doesn't know where a specific date begins without first navigating through the user groups.

This behavior is known as the Prefix Rule.

A compound index can efficiently support queries that start from the leftmost fields of the index.

For example:

{
  user: 1,
  date: -1,
  type: 1
}

can efficiently support:

find({ user })

find({ user, date })

find({ user, date, type })

But not:

find({ date })

find({ type })

find({ date, type })

because those queries do not start from the leftmost field.

Back to My Original Doubt

I originally saw:

transactionSchema.index({ user: 1, date: -1 });
transactionSchema.index({ user: 1, type: -1 });
transactionSchema.index({ user: 1, category: -1 });

Now it makes sense.

Recent Transactions

find({ user }).sort({ date: -1 });

Uses:

{ user: 1, date: -1 }

Filter By Transaction Type

find({
  user,
  type: "expense"
});

Uses:

{ user: 1, type: -1 }

Filter By Category

find({
  user,
  category: "food"
});

Uses:

{ user: 1, category: -1 }

Each index is optimized for a different query pattern.

Another Question I Had: Where Are Indexes Stored?

Initially, I thought indexes somehow reorganized the actual documents.

But that's not what happens.

MongoDB stores documents and indexes separately.

Conceptually:

Collection
-----------
Doc1
Doc2
Doc3
Doc4

And separately:

Index(user,date)
----------------
Aarthi -> Doc5
Aarthi -> Doc2
Aarthi -> Doc1

Rosy -> Doc8

Index(user,type)
----------------
Aarthi -> expense -> Doc1
Aarthi -> income  -> Doc2

Rosy -> expense -> Doc8

Index(user,category)
--------------------
Aarthi -> food -> Doc1
Aarthi -> travel -> Doc2

Rosy -> food -> Doc8

The actual documents remain unchanged.

Indexes are separate data structures that contain references to documents.

Then Why Do We Need `.sort()` If the Index Is Already Sorted?

This confused me too.

Suppose we have:

{
  user: 1,
  date: -1
}

The index itself is sorted.

However, MongoDB does not guarantee that results should be returned in date order unless we explicitly request it.

For example:

db.transactions.find({
  user: "Aarthi"
});

This may use the index to locate records quickly.

But:

db.transactions.find({
  user: "Aarthi"
}).sort({
  date: -1
});

tells MongoDB:

"Return these records in descending date order."

Since the index is already sorted that way, MongoDB can use the index directly and avoid an expensive in-memory sort.

That's one of the biggest performance benefits of compound indexes.

How Does MongoDB Handle Multiple Indexes?

This was another question I had.

Suppose we have:

{ user: 1, date: -1 }

{ user: 1, type: 1 }

{ user: 1, category: 1 }

MongoDB creates three completely separate index structures.

Think of them as three separate books:

Index 1

Aarthi
  2025-08-10
  2025-08-09

Rosy
  2025-08-10

Index 2

Aarthi
  expense
  income

Rosy
  expense

Index 3

Aarthi
  food
  travel

Rosy
  shopping

When a query arrives, MongoDB's query planner decides which index can answer the query most efficiently.

Example:

find({
  user: "Aarthi",
  type: "expense"
});

MongoDB sees:

{ user: 1, type: 1 }

and chooses that index.

For:

find({
  user: "Aarthi"
}).sort({
  date: -1
});

MongoDB chooses:

{ user: 1, date: -1 }

because it perfectly matches the query.

Why Not Create One Huge Index?

I also wondered:

{
  user: 1,
  date: -1,
  type: 1,
  category: 1
}

Wouldn't this solve everything?

Not really.

Because of the Prefix Rule.

This index efficiently supports:

find({ user })

find({ user, date })

find({ user, date, type })

But:

find({
  user,
  category
});

is not optimal because date and type appear before category in the index definition.

MongoDB cannot efficiently skip the middle fields.

That's why index design should follow actual query patterns rather than simply including every field.

The Trade-Off Most Beginners Miss

Indexes speed up reads.

But they are not free.

Every insert, update, or delete must also update all related indexes.

For example, when inserting:

{
  user: "Aarthi",
  date: "2025-08-10",
  type: "expense",
  category: "food"
}

MongoDB must update:

Index(user,date)

Index(user,type)

Index(user,category)

every single time.

So indexes improve read performance at the cost of:

Additional storage
Slower writes
Extra maintenance

This is the classic database trade-off.

My Biggest Takeaway

Before this, I thought:

"Indexes make queries faster."

Now I think:

"Indexes make specific query patterns faster."

Understanding compound indexes, how MongoDB stores them, and the Prefix Rule completely changed the way I think about database design.

The best index is not the one with the most fields.

The best index is the one that matches the queries your application runs most often.

Sometimes a simple question like:

"Why do we have 3 indexes for the same schema?"

can lead to understanding an entire database concept.

If you've had a similar "aha!" moment while learning databases, I'd love to hear it in the comments.

JavaScript Promises & Async/Await Explained with a Real-Life Example 🍕

aarthirs — Mon, 15 Jun 2026 16:15:42 +0000

In my previous post, "JavaScript Async Explained Like a Grocery Store 🛒", I covered how the Call Stack, Browser APIs, Event Loop, and Queues work together to handle asynchronous operations.

In this post, we'll answer the next set of questions:

Why do Promises exist?
How does fetch() return data if the API call takes time?
What exactly does .then() do?
Why was async/await introduced?
Does await block JavaScript?

Let's dive in.

The Problem: Waiting Is Expensive

Imagine ordering a pizza online.

After placing the order, would you stand at the door doing absolutely nothing until the delivery arrives?

Probably not.

You would continue:

Watching YouTube
Working
Talking to friends
Doing other tasks

When the pizza arrives, you'll handle it.

JavaScript behaves the same way.

Operations like:

API requests
Database calls
File operations
Timers

can take seconds to complete.

If JavaScript waited for each operation to finish, your application would freeze.

Instead, JavaScript continues executing other code while waiting for the result.

Enter Promises

A Promise represents a value that will be available sometime in the future.

const promise = fetch("/users");

At this moment, the user data isn't available yet.

The Promise is basically saying:

"I don't have the result right now, but I'll let you know when it's ready."

A Promise can be in one of three states:

Pending
   ↓
Fulfilled (Success)

OR

Rejected (Failure)

Where is `new Promise()`?

One question confused me when I first learned Promises.

If Promises are important, why don't I see this everywhere?

new Promise((resolve, reject) => {
  // async work
});

Instead, I often see:

fetch("/users")
  .then(...)

The reason is simple:

Most modern APIs already return Promises for us.

For example:

fetch("/users");

already returns a Promise.

Conceptually, it works something like this:

function fetch(url) {
  return new Promise((resolve, reject) => {

    // Browser performs request

    if (success) {
      resolve(response);
    } else {
      reject(error);
    }

  });
}

The browser creates the Promise.

We simply consume it.

So What Does `.then()` Actually Do?

Consider:

fetch("/users")
  .then(data => {
    console.log(data);
  });

Many beginners think .then() somehow retrieves the data.

That's not really what's happening.

.then() simply registers a callback function.

You're telling JavaScript:

"When this Promise successfully finishes, run this function."

Think of it like a food delivery app.

Order food
      ↓
Food arrives
      ↓
Call me

orderFood().then(eatFood);

The callback doesn't run immediately.

It waits until the Promise resolves.

Promise Chaining

Let's say we need:

User data
User posts
User comments

A common approach is:

fetchUser()
  .then(user => fetchPosts(user.id))
  .then(posts => fetchComments(posts))
  .then(comments => {
    console.log(comments);
  })
  .catch(error => {
    console.log(error);
  });

This works perfectly.

But as applications grow, chains become harder to read and maintain.

Why Async/Await Was Introduced

Async/Await solves the readability problem.

Instead of:

fetchUser()
  .then(user => fetchPosts(user.id))
  .then(posts => {
    console.log(posts);
  });

we can write:

async function getData() {
  const user = await fetchUser();
  const posts = await fetchPosts(user.id);

  console.log(posts);
}

This feels much closer to normal synchronous code.

The logic becomes easier to follow.

Does `await` Block JavaScript?

One of the most common interview questions.

Consider:

async function demo() {
  console.log("A");

  await fetch("/users");

  console.log("B");
}

demo();

console.log("C");

Output:

A
C
B

Many developers initially expect:

A
B
C

But that's not what happens.

When JavaScript reaches:

await fetch("/users");

it pauses only the current async function.

The rest of the application keeps running.

So the flow becomes:

A
Pause async function
C
API finishes
Resume async function
B

This is why await does not block JavaScript.

It only pauses that specific function.

What Happens Under the Hood?

This code:

async function getData() {
  const data = await fetch("/users");
  console.log(data);
}

is roughly equivalent to:

function getData() {
  return fetch("/users")
    .then(data => {
      console.log(data);
    });
}

That's the key idea.

Async/Await is built on top of Promises.

The Promise mechanism still does all the work.

Async/Await simply provides a cleaner syntax.

Mental Models That Help Me Remember

Promise

The food is on the way.

fetch()

Place an online order.
Returns a Promise immediately.

.then()

When the food arrives,
call me.

await

I'll wait here for the food,
but everyone else can continue working.

async function

This function may contain waiting points.

Bonus: Quick Interview Answers !!

What is a Promise?

A Promise is an object representing the eventual success or failure of an asynchronous operation.

What does `.then()` do?

It registers a callback that executes when a Promise resolves successfully.

Why does `fetch()` work with `.then()`?

Because fetch() already returns a Promise.

Does `await` block JavaScript?

No. It pauses only the current async function.

Why was Async/Await introduced?

To make asynchronous code easier to read and maintain compared to Promise chaining.

Async/Await vs Promises?

Async/Await is syntactic sugar built on top of Promises.

Final Takeaway

Whenever I think about asynchronous JavaScript, I remember this:

Promise = Future Value

fetch() = Returns a Promise

.then() = Call me when ready

await = Pause this function, not JavaScript

async/await = Cleaner Promise syntax

Once these five ideas click, Promises and Async/Await become much easier to understand.

# JavaScript Async Explained Like a Grocery Store 🛒

aarthirs — Sat, 13 Jun 2026 07:32:12 +0000

When I first learned JavaScript's Event Loop, I kept reading explanations like:

"Asynchronous tasks are offloaded to Web APIs and their callbacks are placed into the Microtask Queue or Macrotask Queue."

I memorized the words.

But I didn't actually understand what was happening.

Then I started thinking about JavaScript like a grocery store.

JavaScript = One Cashier

Imagine a store with only one cashier.

The cashier can only serve one customer at a time.

That's JavaScript.


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

Output:

A
B
C

Simple. One task after another.

The Problem

Now imagine a customer says:

"Wait 5 seconds before helping the next customer."

If the cashier literally waited 5 seconds, the entire store would stop moving.

That's exactly what would happen if JavaScript handled timers itself.

Browser Web APIs = Helpers

Instead, JavaScript asks a helper:

`setTimeout(() => {
  console.log("Hello");
}, 5000);`

JavaScript says:

"Hey Browser, can you watch this timer for me?"

The browser helper takes the job.

JavaScript immediately continues working.

Start
End

After 5 seconds, the helper comes back and says:

"The timer finished."

Callback Queue = Waiting Line

The browser cannot interrupt JavaScript directly.

So it places the callback into a waiting line.

Browser Helper
      ↓
Callback Queue

The callback waits until JavaScript is free.

Event Loop = Store Manager

The Event Loop is like a manager constantly checking:

Is the cashier busy?

If yes:

Wait

If no:

Take the next customer from the waiting line

That's all the Event Loop does.

Why Does Promise Run Before setTimeout?

`console.log("Start");

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

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

console.log("End");`

Output:

Start
End
Promise
Timeout

Because JavaScript has two waiting lines:

High Priority Line

Promise.then()
queueMicrotask()

Normal Line

setTimeout()
setInterval()
DOM events

The Event Loop always clears the high-priority line first.

That's why Promise executes before setTimeout.

What About fetch()?

`fetch("/users")
  .then(res => res.json())
  .then(data => console.log(data));`

The browser handles the network request.

JavaScript doesn't sit around waiting for the server.

Once the response arrives, the callback gets added to the queue and runs when JavaScript is ready.

Why Do Web Workers Exist?

Imagine the cashier receives a task that takes 10 minutes.

Nobody else gets served.

The store freezes.

That's what happens when JavaScript performs heavy calculations on the main thread.

Web Workers solve this by hiring another cashier.

Heavy work runs on a separate thread while the main UI remains responsive.

Final Mental Model

Whenever you see async JavaScript:

JavaScript = Cashier

Browser Web APIs = Helpers

Callback Queue = Waiting Line

Event Loop = Manager

Web Workers = Extra Cashiers

Once this model clicks, the Event Loop becomes much easier to understand than memorizing definitions.

# The Turing Dial: A Solstice Cryptography Protocol

aarthirs — Sun, 07 Jun 2026 15:19:26 +0000

This is a submission for the June Solstice Game Jam

How It Works (The Theme Connection)
The game maps the physical passage of time during the Solstice to computational logic constraints. As the game clock cycles from day to night, your processing framework degrades across three environmental phases:

Sunrise (Unary): Pure binary processing.
High Noon (Boolean): Advanced algebraic logic gates (AND, OR, NOT).
Midnight (Enigma): Hard cryptographic bit-parity challenges that honor Turing's codebreaking at Bletchley Park.

Behind the Curtain: Best Google AI Usage

Instead of using the Gemini API as a simple chat box, Gemini 2.5 Flash acts as our automated Procedural Level Designer.

Every time the environment transitions, the system fires a background request to Google AI Studio. Gemini dynamically parses the current game state and feeds back:

A unique, context-aware matrix puzzle directive (puzzleHint).
The dynamic numeric or parity solution ruleset (solutionKey).
A curated, inspiring quote reflecting Alan Turing's legacy, Juneteenth, or Pride Month (historyQuote).

If the network connection ever fails, a native hardware fallback loop steps in to ensure seamless offline gameplay.

Built With

Pure HTML5 / CSS Grid (with a custom CRT scanline terminal effect)
Modular Vanilla JavaScript
Official @google/genai SDK via CDN

Play the Game

GitHub Repository: github
Live Demo:vid demo

DEV Community: aarthirs

DesiPasta — Italian Comfort, Indian Soul 🍝

What I Built

The Design

Technical Highlights

Demo

What I Learned

⚙️I Thought I Was Solving Localization. I Ended Up Building an Industrial Vocabulary Engine.

🏭 The Stack

🐞 The Bug That Didn't Look Like a Bug

🔧 Small Changes, Big Difference

📈 Scaling Beyond Machines

📊 Before / After

💡 What This Project Taught Me

🎯 Looking Back

From LeetCode to Production: What the Boyer-Moore Voting Algorithm Taught Me

🤯 The "Wait... How Does This Even Work?" Moment

💡 Key Takeaway

🧠 The Core Idea

🚀 Then I Started Thinking Beyond LeetCode...

💭 What This Problem Actually Taught Me

🎯 My Takeaway

Passion Journal AI - Weekend Challenge

What I Built

Demo

🌐 Live Application URL : Passion_Journal_AI

Code

How I Built It

Frontend

Backend

AI Integration

Architecture Decisions

Challenges

What I Learned

Prize Categories

MongoDB Indexes Finally Clicked for Me: Understanding Indexes, Compound Indexes & the Prefix Rule 🚀

What is an Index?

What is a Compound Index?

The Prefix Rule: The Concept That Finally Made It Click

Back to My Original Doubt

Recent Transactions

Filter By Transaction Type

Filter By Category

Another Question I Had: Where Are Indexes Stored?

Then Why Do We Need .sort() If the Index Is Already Sorted?

How Does MongoDB Handle Multiple Indexes?

Index 1

Index 2

Index 3

Why Not Create One Huge Index?

The Trade-Off Most Beginners Miss

My Biggest Takeaway

JavaScript Promises & Async/Await Explained with a Real-Life Example 🍕

The Problem: Waiting Is Expensive

Enter Promises

Where is new Promise()?

So What Does .then() Actually Do?

Promise Chaining

Why Async/Await Was Introduced

Does await Block JavaScript?

What Happens Under the Hood?

Mental Models That Help Me Remember

Promise

fetch()

.then()

await

async function

Bonus: Quick Interview Answers !!

What is a Promise?

What does .then() do?

Why does fetch() work with .then()?

Does await block JavaScript?

Why was Async/Await introduced?

Async/Await vs Promises?

Final Takeaway

# JavaScript Async Explained Like a Grocery Store 🛒

JavaScript = One Cashier

The Problem

Browser Web APIs = Helpers

Callback Queue = Waiting Line

Then Why Do We Need `.sort()` If the Index Is Already Sorted?

Where is `new Promise()`?

So What Does `.then()` Actually Do?

Does `await` Block JavaScript?

What does `.then()` do?

Why does `fetch()` work with `.then()`?

Does `await` block JavaScript?