About
I'm Adarsh — a software engineer based in Kerala, India, working mostly in JavaScript and TypeScript on the web.
This site is where I write things down as I learn them. The posts are the explanations I wanted to find when I was first working through a topic: the mechanism rather than the summary, the trade-off rather than the recommendation, and the failure mode that only shows up in production.
Most articles are built around an animation you can step through. It turns out that a stack popping, a cache prefix invalidating, or a search expanding across a grid is much easier to understand when you can watch it happen and move back a step.
What's here
- 76
- articles
- 26
- practice questions
- 4
- topics
The writing splits into 4 areas — AI Engineering, DSA, JavaScript and System Design. There is also a structured DSA path that orders the algorithms articles from recursion through dynamic programming, and a practice set grouped by the pattern that solves each question.
What I work with
What this site runs on
- Next.js 16App Router, React Server Components, Turbopack
- React 19Server components by default; client only for the interactive parts
- TypeScriptStrict mode, path alias @/* → ./src/*
- Tailwind CSS 4CSS-first config — no tailwind.config.ts
- MDXnext-mdx-remote rendering posts as RSC, frontmatter parsed by hand
- sugar-highSyntax highlighting, small enough to run at render time
- GeistSans and mono, self-hosted through next/font
How it's built
Posts are files, not a CMS
Every article is an .mdx file in the repo. Frontmatter carries the title, date, summary and tags; the build reads the directory and generates a static page per post. Writing is a commit, and the history of a post is its git history.
Diagrams are components, not images
Each visualizer is a small client component built on one shared step player, so it animates, steps, and replays — and stays sharp, themed, and readable in both light and dark. A screenshot could not do any of that, and an image cannot be diffed in review.
Search runs in the browser
The index — titles, summaries, tags, headings and prose with code stripped out — is built at compile time and served as one static file, fetched the first time you press ⌘K. No search service, no query logging, and it works the same on a fork running locally.
Static where possible
Almost every route is prerendered at build time, including the OG images and the RSS feed. What is left is a handful of query-driven pages. The result is a site that is cheap to host and fast for the reader.