Forem: Amelia Dutta

Revisiting DSA Through Mini Projects #2: HTML Syntax Validator

Amelia Dutta — Thu, 05 Feb 2026 15:43:26 +0000

I am back with another mini project on revisiting DSA and today's topic is Stack! And how I built a simple HTML syntax checker app applying the Stack.

What is a Stack?

A stack is a collection of objects that are inserted and removed according to the Last-In,First-Out(LIFO) principle.

For example: Our Browser's Search history is an example of a stack where each time you visit a new web address, it will be pushed onto the stack of web addresses and by returning you are actually popping back the last searched address to the previously visited site!

Second Project of This Series: A HTML Syntax Checker
Before diving deeper into the project and the logic, check the app here: syntax-validator

Let's See How It Works

To check if HTML tags are balanced, we can use the LIFO property of a Stack. The logic is as follows:

Scan the Code: We read the HTML string from left to right.
Push Open Tags: Whenever we encounter an opening tag (like <div> or <p>) we push it onto our stack.
Pop Closing Tags: When we find a closing tag (like </div> or </p>) we check the top of our stack.
- If the stack matches the current closing tag (e.g. top is div and current is /div) we pop it off. This means the tag was correctly closed!
- If the stack is empty or the tags don't match, we know the syntax is invalid.
After reading the whole string if the stack is completely empty it means every opening tag had a matching closing tag and our html code is valid!

Implementation

I kept the implementation simple using vanilla JavaScript. Here is the snippet where the magic happens:

while(i != -1){
    // If it is an opening tag that means doesn't start with '/'
    if(!tag.startsWith("/")){
        stack.push(tag);
    }
    // If it is a Cclosing tag
    else{
        // Check if we have anything to close
        if(stack.length == 0){
            output.innerText = "Invalid Syntax";
            return;
        }
        // Check if it matches the last opened tag
        // Here tag.slice(1) removes the '/' so we compare "div" with "div"
        if(tag.slice(1) !== stack.pop()){
            output.innerText = "Invalid Syntax";
            return;
        }
    }
}

The key methods here are stack.push(tag) to add to our history of open tags and stack.pop() to match them when we close a tag.

Limitation

As I was revising stack and wanted to make a simple project on that topic so this project has some limitations:

Strict Matching: This code checks for exact string matches. That means <div class="hero-section"> wouldn't match </div> because the strings are different!
Empty Tags: HTML has "empty/void" tags like <img>, <br> and <hr> that don't need a closing tag. Which is why this code will return this as an Invalid Tag!

This project made me realize that finding the right data structure is only half the battle. While the stack was the perfect tool for the core logic, I realized that a real-world solution must handle more complex issues, such as attributes and empty tags.

Revisiting DSA Through Mini Projects #1: Optimizing a Phonebook with HashMap

Amelia Dutta — Mon, 02 Feb 2026 10:24:27 +0000

I am starting to revise the DSA topics when an idea popped in; how about starting to create one mini project based on each topic while revisiting them? This way it can give me insights into how data structures and algorithms are applied in the real world and also I can have something to showcase.

First Project of This Series: A Phonebook App

Without further ado, here is the first project of my learning series: a Phonebook App. Check the app here: https://hashphonebook.netlify.app/

I made this app some years ago but at that time I used the logic of linear searching. Which is good because it was a demo project and there is no need to store thousands of numbers, so the search can check all the possibilities and then return the desired result.

Initially I stored my contacts in a simple JavaScript Array:

let userArray = [
    { userName: "Jane", number: "1237893457" },
    { userName: "Oscar", number: "4562317895" }
];

And to find a contact I used .find() which loops through the array one by one:

// Time Complexity: O(n) Linear Time
const result = userArray.find(contact => contact.userName === "Oscar");

But Why Is Linear Search Not Enough?

In the real world, the scenario is different. We need to store many numbers in our contact list. For example: we store 100000 numbers and in an emergency case, taking the worst scenario if our phonebook takes O(100000) time to show the result then it is too much in this fast-paced world.

This is where performance actually matters not just whether the app works or not!

Optimizing the Search Logic

So the solution is using something that can give results in a shorter time. I changed the array to a HashMap and searched through the map using the key (username).

This way, the lookup time is much faster (O(1)) and more suitable for real-world use cases. Because A Hashmap acts like a real-world dictionary. You don't read every word to find "Strawberry" you flip straight to S.

let contactMap = {
    "Jane": "1237893457",
    "Oscar": "4562317895"
};

// Time Complexity: O(1) Constant Time
const number = contactMap["Jane"];

It doesn't matter if I have 5 contacts or 5 billion. The lookup speed is constant.

The Code Refactor

Here is the actual code I changed in my project:

Before (Array.push):

userArray.push({ userName, contactNumber });

After (Map Key-Value):

// Storing as a key-value pair and making the search case-insensitive
contactMap[userName.toLowerCase()] = { 
    originalName: userName, 
    number: contactNumber 
};

This project made me realize that a "working code" is not always "good code". Linear search was enough for a demo but it doesn't scale and real-world applications demand better solutions.

This is just the first step in my DSA revision journey and I plan to keep building small projects like this!

Step Into Mystic Falls: A Halloween Story Telling Game

Amelia Dutta — Mon, 10 Nov 2025 06:06:07 +0000

> “There is no such thing as a bad idea. Only poorly executed awesome ones,”
Damon once said and I couldn't stop thinking about that while building this Halloween project.

When I stumbled upon the Frontend Challenge - Halloween Edition, Perfect Landing_, I thought why not revisit some old JavaScript fundamentals and create a landing page that truly captures the Halloween spirit?

The Founder's Day and the Lockwood Masquerade Ball have always been my favorite events from The Vampire Diaries so while planning this project I thought, "Let's merge them together!"

That's how The Founder's Ball was born: an interactive storytelling game that lets users step into a dark ballroom, pick a partner, and uncover their supernatural identity.

The Experience

The entire app is built with HTML, CSS, and Vanilla JavaScript (ES6).

Key Technical Features:

Modular JavaScript with ES6 imports/exports for cleaner code organization
CSS Keyframes for smooth fade-in transitions between sections
Responsive Design optimized for mobile, tablet, and desktop (5 breakpoints)
Dark Gothic UI with gradients, animations, and elegant typography

The user journey flows through 6 distinct sections:

Landing → Enter the mysterious ballroom
Attire Selection → Choose your formal wear
Outfit Choice → Pick from 4 elegant designs
Partner Selection → Meet your mysterious companion
Identity Reveal → Discover your supernatural nature
Your Story → Read your personalized tale

My goal was to create a user journey that felt like navigating through a storybook, where each choice transitions seamlessly into the next moment.

My Learnings

This challenge gave me the perfect push to revisit my Vanilla JavaScript foundations and dust off some forgotten concepts.

Here's what I brushed up on:

Array Methods: join(), find(), map()
State Management
DOM Manipulation
ES6+ Features: arrow functions, modules, destructuring

Play The Founder's Ball

View Source Code

Halloween doesn't always have to be scary. Sometimes it's about mystery, elegance, and the thrill of becoming something supernatural for a night.

So… if you've ever wondered what your story will be in Mystic Falls, come find out. The Founder's Ball awaits you at the Lockwood Mansion from sunset to midnight. 🦇

All images used in this project are credited to their original owners.

How Being Part of a Community Took Me from Hesitant to 5 PRs Merged

Amelia Dutta — Sun, 02 Nov 2025 18:26:26 +0000

Ding-dong! The ghouls are gone and the season of Christmas begins; the month long Hacktoberfest wraps up, filled with learning, debugging and late night commits! 🎃
This year, I learned so much more through contributing to Open Source which I never got from just reading tutorials or doing personal projects. and honestly a big chunk of that credit goes to the Torc community.
(Before diving into my journey, check out Torc)

At the beginning of the month, my feed was full of posts from people on LinkedIn and Twitter buzzing about Hacktoberfest. Everyone seemed so ready and excited. And me? I was like, "Umm, nice... but where do I even start?" My calendar was already packed with other events so I didn't really have time to plan my contributions.
And that's where the magic of a good tech community kicks in. Around the second week of October, right when Hacktoberfest was in full swing I finally got a break and logged back in. That's when I discovered that Torc discord have a dedicated hacktoberfest channel, shout out to Jason Torres for creating the torctoberfest repo. And I got a place to start! My interest was back, but then came the real question: what do I contribute to?

The Beginning of torcReads

While scrolling through the channels I suddenly remembered, I hadn't even read the book we picked for our book club! That's when the idea hit me. Huge thanks to Angelos Katrantzis for starting the Torc Book Club; otherwise I might never have thought of this project in the first place!
The initial plan was simple: build a website to log the books we read each month in the club. But then my brain went "Wait, why not add more?" So I started adding features like study guides and monthly voting options. The frontend came out beautifully; Responsive, Clean and Minimalist. And guess what? My first two PRs got merged! Cool, right? 😎

After hosting it for testing, I realized something... Oops it is storing all the data locally! Which meant once deployed, everyone would see their own data. Total chaos incoming!
And here's the twist: I never worked with any backend before. So laptop on, a little googling, some brainstorming with Claude and a few Stack Overflow tabs later; BAM! I discovered Supabase! It lets you store data globally and even offers generous free storage. But of course... I had zero experience integrating a database with frontend.

Still I told myself "we've got a week and a half before 31st October! Why not learn something new?"

My Learnings in the Process

While setting up the database with the frontend I learned a few cool things:

Row Level Security (RLS)
Access control that defines who can read, insert, update, or delete specific rows based on policies.
Migration Files
Version controlled SQL scripts that track and apply database schema changes over time, allowing teams to sync database structures across environments.
CRUD Operations (Create, Read, Update, Delete)
The four fundamental database operations: Create adds new data, Read retrieves it, Update modifies it, and Delete removes it.
Uploading files to cloud
Cloud file storage service that uploads files to remote servers and returns public URLs, allowing applications to store and retrieve uploaded content without managing server infrastructure.
Organizing files
Containers that group and organize related files in cloud storage.
Public vs Private buckets
Access control for file storage; public buckets allow anyone with the URL to download files while private buckets require authentication.

Check out the Torctoberfest Repo here: https://github.com/jasonetorres/torctoberfest

Building torcReads taught me far more than just coding. Before this, I thought backend and database were way out of my league. But once hit a real problem, I had no choice but to figure it out! Kudos to Pat Clark for reviewing and giving thoughtful feedback on each of my pull requests.

I realized open source isn't about being an expert in everything and you don't need to know all to get started. It's about showing up, trying things and learning in public. Even a small idea can turn into something valuable when you have a great community guiding you!

Happy Hacking! 🕸️👻