About Frontend Dummies

Who writes this site, and how the material gets made.

Who runs this site

Frontend Dummies is written and maintained by a single person: me, Pratik Rai. I'm a software engineer based in Gurgaon, India, with over two years of experience building production web applications in React, Next.js and TypeScript.

Why this site exists

Most frontend learning material stops at the level of the API surface. It tells you what Array.prototype.map does, but not what happens when you implement it yourself, or why the browser stalls when you get the critical rendering path wrong.

I kept running into that gap — first while preparing for interviews, then while doing the work. Frontend Dummies is the resource I wanted: challenges you actually build, polyfills you write from scratch, and long-form notes that go a layer deeper than the documentation. Everything here comes out of problems I've hit in production or while studying, not from paraphrasing other tutorials.

What you'll find here

  • Coding challenges — UI components and interactive widgets built from scratch, each with a written explanation and a runnable demo.
  • JavaScript polyfills and drills — implementing the standard library by hand, because that's where the language stops being magic.
  • Deep notes — long-form write-ups on web performance, security, rendering and fundamentals.
  • An in-browser playground — a JavaScript editor with live console output, for trying things without leaving the page.

How the content is made

Every article and challenge on this site is written by me. I build each challenge before writing about it, and the explanations describe the approach I actually took, including the parts that were awkward. Where I'm uncertain about something, I say so rather than papering over it.

The order is deliberate: implement first, write second. A polyfill gets written against the specification and then tested against the native method until the two agree, including on the cases that are easy to miss — sparse arrays, a missing this argument, callbacks that mutate the array while it is being walked. Only then does the write-up get drafted, which is why the explanations spend more time on edge cases than on the happy path. If a challenge has a runnable demo, that demo is the same code the article discusses, not a simplified version of it.

Long-form notes work the same way. Claims about browser behaviour are checked against the specification or against a browser before they go in, and where the answer is “it depends on the engine”, the write-up says that instead of picking a tidy answer. Nothing here is generated or rewritten from another tutorial. When something turns out to be wrong, the page gets corrected rather than quietly deleted.

Corrections are welcome and I'd rather hear about a mistake than leave it up. If you spot something wrong, please get in touch.

Elsewhere