DEV Community: Viram Choksi

Nobody teaches you to debug

Viram Choksi — Tue, 04 Aug 2026 18:42:49 +0000

You've been here.

The code looks right. It runs. The output is wrong.

No error. No stack trace. Nothing to paste into Google. Just a number that should
be 10 and is 4, and no idea where it went.

Three years of writing code, zero of fixing it

Every assignment I was given was graded on writing something from scratch.

Not one was graded on fixing something broken.

Then you get to real work and it inverts completely. You spend far more time
reading code you didn't write and finding out why it misbehaves than you ever
spend on a blank file.

We're trained for the rare case and left to improvise the common one.

Bugs aren't infinite. They're a handful of shapes

This is the thing that changed how I think about it.

Almost every bug is one of a small number of patterns:

the shape	what you see
🔁 Loop runs one time too many	`IndexError` on the last item
0️⃣ A valid `0` treated as missing	Setting it to zero has no effect
🔒 Closure captures the variable, not the value	Every callback reports the last one
📋 A "copy" that's the same object	Editing the copy changes the original

Once you can recognise the shape, you stop debugging line by line and start
recognising. The next one takes minutes instead of an afternoon.

You can't get that from reading. You get it from finding bugs, repeatedly, and
being told what you just found.

So I built the practice

BugHunt gives you working code with exactly one
bug in it.

You get the symptom, not the cause:

last_char("hello") raises IndexError: string index out of range

def last_char(text):
    return text[len(text)]     # ← one character too far

You find it. Fix it in the browser. Run it against the test cases.

When it passes, you get an explanation of the pattern — not just the diff.
Knowing this loop needed i + 1 is nearly worthless. Recognising an off-by-one
on sight is worth a lot.

A few things that matter

Nothing to install. Python runs through WebAssembly right in the tab. Works on
a locked-down college lab machine with no admin rights.

No account needed. Solve a bug, read the explanation, close the tab. An account
only saves your progress.

Watch it run. Step through line by line and see every variable at every step.
Seeing the exact moment a value goes wrong is very different from being told
where the bug was.

Free. No ads, no paywall. It runs on free hosting tiers on purpose — there's
nothing to recoup, so there's no reason to start charging.

Try one

Pick a bug and see how long it takes you:

trybughunt.vercel.app

If an explanation is confusing, there's a report button on every challenge. I
read them.

Four things that surprised me running Python in the browser

Viram Choksi — Tue, 04 Aug 2026 18:31:20 +0000

I built a debugging-practice site where student code runs entirely in the
browser. Python via Pyodide, JavaScript in a worker. No
server executes anything.

No execution bill, no queue, no sandbox to maintain. But four things bit me hard.

1. Your arguments aren't Python objects

Pass a JS object into Python and you get this:

TypeError: 'pyodide.ffi.JsProxy' object is not subscriptable

It's not a dict. It's a live view of the JS object, and it supports neither
obj[key] nor .get().

Convert explicitly:

const pyArgs = input.map((arg) => pyodide.toPy(arg));
const result = fn(...pyArgs);

2. `null` is not `None`

This one passed my entire test suite while being broken in production.

pyodide.toPy(null)

check	result
`type(v)`	`JsNull`
`bool(v)`	`False`	✅ falsy, as expected
`v is None`	`False`	❌ the surprise

It's falsy, so truthiness checks work fine. But is None fails — which was
exactly what my code was checking.

Why my tests missed it: the harness used json.loads. The app used toPy.
Different conversion paths, different answers.

If you need a real None, create it in Python. Don't pass one across.

3. `sys.settrace` is a free step debugger

Want to show users their code running line by line? Python basically hands it to you:

def _tracer(frame, event, arg):
    if frame.f_code.co_name != target:
        return None                    # skip library frames
    if event == "line":
        steps.append({
            "line": frame.f_lineno,
            "locals": dict(frame.f_locals),
        })
    return _tracer

Two things this naive version gets wrong:

Add a step cap. A tight loop generates steps faster than it burns a 5-second timeout. You need both guards.
Handle exception. During unwinding, the return event still fires with arg=None. Miss it and your trace says "returned None" for code that crashed.

4. Your snapshots are lying

A user screenshot exposed this one.

Every step in the trace showed the final state of a list. Step 1 included
mutations that hadn't happened yet.

  tracing:  nums = []; nums.append(1); nums.append(2)

- what the trace showed        + what actually happened
- step 1   nums = [1, 2]       + step 1   nums = []
- step 2   nums = [1, 2]       + step 2   nums = [1]
- step 3   nums = [1, 2]       + step 3   nums = [1, 2]

frame.f_locals gives you references. Snapshot a list and you've stored a
pointer to something the program keeps mutating.

# copy at capture time
return json.loads(json.dumps(value))

Any time you snapshot mutable state over time, you're one reference away from
a history that rewrites itself.

Worth it?

Yes. Zero execution cost, scales infinitely, works on a locked-down lab machine
with nothing installed.

But test against the real runtime. Every bug above was found by running the
actual thing — not by unit tests around it. The JsNull one passed a fully green
suite.

Built for BugHunt — free debugging practice,
runs in your browser, no account needed.

Why My Portfolio Has a Boot Sequence, Window Manager, and 6 Playable Games

Viram Choksi — Sun, 29 Mar 2026 17:19:36 +0000

I Built a Full Operating System as My Developer Portfolio — Here's How

Most developer portfolios look the same: a hero section, some cards, a contact form. I wanted mine to make recruiters stop scrolling.

So I built ViramOS — a fully functional desktop operating system that runs in the browser. Boot sequence, login screen, draggable windows, taskbar, 13+ interactive apps, 6 playable games, and a working terminal. All built with Next.js, React, and Framer Motion.

Live demo: viram-choksi.vercel.app

What Does It Actually Do?

When you visit my portfolio, you don't see a webpage. You see this:

Boot Sequence — Matrix rain, ASCII art, fake BIOS logs loading frameworks
Login Screen — Glassmorphic card with animated gradient ring, press Enter to unlock
Desktop — Animated wallpapers, floating particles, draggable app icons
Window Manager — Drag, resize, minimize, maximize, snap-to-edge (like Windows 11)
Taskbar — Running app indicators, system tray, control center, clock

And then 13+ apps you can actually use:

Terminal with 15+ commands (whoami, neofetch, benchmark, architecture)
Projects file manager with metrics and impact numbers
Skills package manager with proficiency bars
Games — Snake, 2048, Tic Tac Toe (with minimax AI), Typing Test, Memory Card, Reaction Time
System Monitor — Real-time FPS, Core Web Vitals, bundle size breakdown, architecture decision records
Settings — 12 wallpapers, accent colors, font scaling, night shift, high contrast
Command Palette — Press / to fuzzy-search and launch any app

The Tech Stack

Layer	Technology
Framework	Next.js 16 (App Router, SSR, ISR)
UI	React 19, Framer Motion
Styling	Tailwind CSS 4
3D	Three.js + React Three Fiber
State	React Context (no Redux needed)
Email	Nodemailer via API route
Analytics	Vercel Analytics + Speed Insights
Deploy	Vercel (Edge Network)

Architecture Decisions That Matter

Why React Context over Redux?

The OS state (open windows, settings, theme) is shared across components but updates infrequently — user clicks, not real-time data. Context + useCallback/useMemo keeps the bundle smaller and API simpler. Redux would add ~12KB gzipped for state that changes maybe 5 times per session.

Why DOM Windows, Not Canvas?

I considered building the window manager on Canvas (like Figma does). But DOM-based windows mean:

Native text selection inside windows
Form inputs work naturally
Screen readers can access content
Standard React component composition

Canvas would give better performance at 50+ simultaneous windows, but a portfolio never has more than 5 open.

Why Framer Motion over CSS Animations?

The boot sequence, window transitions, and desktop effects need orchestrated animations with exit transitions. CSS can't do AnimatePresence — you can't animate an element leaving the DOM. Framer Motion costs ~45KB gzipped but enables spring physics, gesture-based drag, and coordinated mount/unmount animations.

Window Snap Zones

I implemented Windows 11-style snap zones: drag a window to the left edge and it snaps to the left half, right edge for right half, top for maximize. The snap preview shows a translucent overlay while dragging near edges. Dragging a snapped window out restores it to its original size.

const getSnapZone = (clientX, clientY) => {
  const vw = window.innerWidth;
  if (clientY <= 12) return "top";     // maximize
  if (clientX <= 12) return "left";    // left half
  if (clientX >= vw - 12) return "right"; // right half
  return null;
};

Settings Persistence

All user preferences (wallpaper, accent color, font size, night shift) persist to localStorage. The trick with Next.js SSR: you can't read localStorage during server render or you get hydration mismatches. So I start with defaults, then restore from localStorage in a useEffect after mount.

SEO for a JavaScript-Heavy Portfolio

The biggest SEO challenge: the homepage is entirely JS-rendered. Google can crawl dynamic content, but it takes extra time. My approach:

sr-only content — Full text resume hidden but crawlable (same content as the interactive apps)
<noscript> fallback — Visible content for JS-disabled users and crawlers
11 static landing pages — /frontend-developer-ahmedabad, /react-developer-ahmedabad, etc. with visible content, FAQ schema, and breadcrumbs
JSON-LD structured data — 7 schemas: Person, FAQPage, WebSite, ProfessionalService, ItemList, LocalBusiness, Organization
Dynamic sitemap with proper priorities and dates

Accessibility in an OS Simulation

Building an accessible OS simulation sounds contradictory, but I took it seriously:

prefers-reduced-motion — All CSS animations respect the user preference
role="application" on the desktop, role="dialog" on windows
Skip link — Tab-accessible "Skip to desktop" link
Keyboard navigation — Tab through desktop icons, Enter/Space to open apps
aria-label on all interactive elements (window controls, taskbar, context menu)
Focus indicators — Visible focus-visible rings on all buttons
Semantic HTML — <main>, <nav>, <button> instead of <div> everywhere

WCAG compliance in my day job went from 40% to 95%. I applied the same thinking here.

Performance

Despite the visual complexity, the portfolio loads fast:

Code splitting — Each app component only loads when its window opens
Immutable cache headers — 1-year cache for JS/CSS assets
Adaptive particles — Fewer particles on mobile for 60fps
Lazy window rendering — Zero hidden DOM nodes for closed apps
Vercel Edge Network — CDN distribution + SSR

What I Learned

The OS metaphor forces you to solve real problems — Window z-index management, focus trapping, state persistence, responsive layouts for different "screen sizes" inside windows. These are the same problems production apps face.
Constraints breed creativity — A scrollable page is easy. An interactive desktop with overlapping windows, a taskbar, and 13 apps forces you to think about layout, performance, and UX simultaneously.
Recruiters spend 15-30 seconds — If they don't instantly see something interesting, they leave. The boot sequence animation buys you 5 seconds of attention. The desktop experience keeps them exploring.

Try It

Live: viram-choksi.vercel.app

Open the Terminal and type help. Try / to open the Command Palette. Play Snake. Change the wallpaper in Settings. Drag a window to the edge and watch it snap.

If you're building your own portfolio, steal the architecture — just don't copy the design. The world needs more creative portfolios and fewer Bootstrap templates.

I'm Viram Choksi, a Frontend Engineer in Ahmedabad, India. I build with React.js, Next.js, Vue.js, and TypeScript. Currently at Motadata, previously at MindInventory. Say hi at viramchoksi77166@gmail.com or find me on LinkedIn.

Tags: #webdev #javascript #react #portfolio #nextjs #frontend #career