DEV Community: Adarsh

Engineering a Real-Time Collaborative Editor with Supabase

Adarsh — Sun, 22 Feb 2026 12:43:37 +0000

As a developer who values the "Build → Break → Optimize" philosophy, I wanted to tackle one of the hardest problems in web development: Real-time Concurrency.

I built BitPad, a collaborative code editor where developers can create rooms and code together in live-sync. The backbone of this entire system? Supabase.

Why Supabase?

Instead of managing a complex WebSocket server manually, I leveraged Supabase's Realtime engine. This allowed me to focus on the user experience while the infrastructure handled the heavy lifting of syncing state across multiple clients.

The Technical Stack:

Database & Realtime: Supabase (Postgres) for instant data broadcasting.
Frontend: Next.js and Tailwind CSS for a lean, high-performance UI.
Architecture: A room-based system where every keystroke is synchronized across all connected peers.

The Challenge: Managing State at Scale

The hardest part of building BitPad was ensuring that the "Room" state didn't become a bottleneck. By using Supabase's row-level security and realtime listeners, I was able to create a secure, fast, and scalable environment where developers can jump in and out of sessions without losing a single line of code.

Key Learnings

Infrastructure over Boilerplate: Supabase allowed me to ship a "Live Share" competitor in record time.
Concurrency Patterns: Handling simultaneous edits taught me a massive amount about database locks and race conditions.

Check out the live build: bitpad.vercel.app

Why I Built DSA Portal 2026: Solving the Roadmap Problem

Adarsh — Sun, 22 Feb 2026 12:40:39 +0000

Data Structures and Algorithms (DSA) are the foundation of computer science, but for most students, the biggest hurdle isn't the logic—it's the resource overload. Between YouTube, LeetCode, and textbooks, it's easy to get lost.

I built DSA Portal 2026 to act as a centralized "source of truth." My goal was to move away from chaotic bookmarking and toward a structured, high-performance learning hub.

The Architecture of Learning

When building this portal, I didn't just want a list of links. I wanted a platform that felt like an extension of the developer workflow:

Structured Taxonomy: Organizing topics by complexity (Arrays → Trees → Graphs) ensures a logical progression.
Minimalist UX: Built with Next.js and Vercel to ensure zero latency. When a student is in "deep work" mode, the UI should disappear.
Curated Signal, No Noise: Every resource in the portal is hand-picked to ensure it provides the highest ROI for learning time.

Tech Stack

Framework: Next.js (for optimized routing)
Styling: Tailwind CSS (maintaining a clean, "Sandip-style" minimalist aesthetic)
Deployment: Vercel (CD/CI for instant updates)

The Philosophy: Build to Learn

My philosophy is Build → Break → Optimize. By building this portal, I had to deeply understand the relationships between different DSA topics to categorize them correctly. It wasn’t just a web project; it was a knowledge-mapping exercise.

Whether you're preparing for interviews or just want to strengthen your fundamentals, having a structured roadmap is the fastest way to progress.

Explore the portal here: dsa-portal-2026-ad.vercel.app

What is your preferred way to track your DSA progress? Let’s discuss in the comments.

How I Engineered a Custom Chromium Adblocker from Scratch (Manifest V3)

Adarsh — Sun, 22 Feb 2026 12:26:43 +0000

As a Linux-first developer, my entire workflow is built around granular control. I rely on Neovim and the terminal to keep my environment lean and completely free of bloatware. Recently, I decided to apply that exact same philosophy to my web browser.

Instead of just downloading a black-box extension to block ads, I wanted to understand the mechanics underneath. My engineering philosophy is simple: Build → Break → Optimize.

So, I built and shipped v1.0 of my own Chromium-based adblocker. Here is exactly how it works under the hood using Manifest V3.

The Engine: `manifest.json`

Every Chromium extension starts with the manifest. With the controversial shift to Manifest V3 (MV3), Google changed how adblockers operate, moving away from the old webRequest API to the newer declarativeNetRequest API.

This means the browser handles the blocking natively based on rules we provide, making it faster and more secure. Here is the core of the engine:

{
  "manifest_version": 3,
  "name": "ZeroBloat Adblocker",
  "version": "1.0",
  "description": "A lightweight, custom adblocker built for speed.",
  "permissions": [
    "declarativeNetRequest",
    "declarativeNetRequestFeedback"
  ],
  "host_permissions": [
    "<all_urls>"
  ],
  "declarative_net_request": {
    "rule_resources": [
      {
        "id": "ruleset_1",
        "enabled": true,
        "path": "rules.json"
      }
    ]
  }
}

rules.json:

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||doubleclick.net^",
      "resourceTypes": ["script", "image", "xmlhttprequest"]
    }
  },
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||googleadservices.com^",
      "resourceTypes": ["script", "image"]
    }
  }
]

Breaking Down the Mechanics:

id: Every rule needs a unique integer.

action: { "type": "block" }: This tells the browser to instantly drop the connection before it even resolves.

urlFilter: This uses standard Adblock Plus syntax. The ||means it matches the domain and all subdomains, catching the trackers before they load.

The "Optimize" Phase

Building v1.0 was about getting the core mechanics working. It successfully strips out the heavy tracking scripts and media elements from standard pages, resulting in a much cleaner, faster browsing experience.

The next phase is optimizing the rule sets and exploring how to handle dynamic element hiding without introducing the very bloatware I set out to avoid.

If you are a student or developer who usually relies on out-of-the-box tools, I highly recommend building your own. You learn vastly more about browser architecture by breaking and building the tools you use every single day.