JavaScript fundamentals, CSS and Tailwind, why React and Next.js won, interview prep — and notes from what actually shipped in production, with the tradeoffs left in.
75 posts
The difference between a code review that makes a codebase better and one that just makes the author defensive comes down to a handful of specific, learnable habits.
JavaScript was a 10-day prototype that became the only language every browser runs natively. Here's the actual reason it never got replaced.
Reproduce, isolate, hypothesize, verify — the actual discipline that separates a bug fixed in 20 minutes from the same bug chased for two days on hunches.
How a vague product ask becomes a scoped, shippable spec in one structured conversation — the same questions that scoped Amber Car Rental.
Git flow, trunk-based development, and the actual, practical middle ground most real teams land on — with the reasoning for why, not just a diagram of branch names.
Not a hype piece — where AI-assisted tooling genuinely earns its place in a real full-stack JavaScript workflow, and where it structurally can't.
The actual day-to-day mechanics of working with two different AI tools on the same codebase — not a highlight reel, the boring parts that make it work.
The Quote Management System case study used them for a real reason. The general version of that reasoning — and the real cost most projects shouldn't pay.
The real decision is not which is faster — it is whether your data's relationships are known and stable, or genuinely variable. That decides the rest.
The lightweight planning approach behind every project on this site — positioning, architecture, data model, and SEO, decided before any code exists.
Three mechanisms, each solving a genuinely different piece of 'how does the server know who you are' — and where each one's security tradeoff lives.
REST has a real limitation with nested data. GraphQL fixes that, at a real cost — not a strictly better technology, a different tradeoff entirely.
Keeping a native booking calendar in sync with a Turo listing over iCal — polling, diffing snapshots, and avoiding a double-booking across two systems.
Not 'types are nice to have' — the specific class of bug TypeScript catches at compile time that JavaScript's type coercion lets through silently.
No DOM, no window — but the same V8 engine and event loop. What actually changes, and what stays identical, when JavaScript runs on a server.
An honest retrospective on being the only engineer on Amber Car Rental — what breaks, what I'd have prioritized sooner, and what I'd genuinely repeat.
One language, five surfaces — the actual technical reason JavaScript depth compounds instead of being one skill among many, walked through surface by surface.
The problem → decision → result structure that makes a project story land — the same shape every case study on this site uses, and for the same reason.
The concrete, unglamorous changes to a legacy government React codebase that added up to a 30% load-time cut.
What a machine-coding round actually checks — working code under time pressure — and two implementations you should be able to write cold.
Not a cheat sheet — the actual axes a strong system design answer gets judged on, and why 'just use React' is never a complete answer.
The MMRDA platform couldn't go down for a rebuild. How to improve a legacy codebase when 'just rewrite it' isn't an option.
The capstone of the CSS and Tailwind series — specificity, the box model, Flexbox vs Grid, and centering a div, with the mechanism behind each answer.
The 'flash of wrong theme' bug — light mode briefly showing before snapping to dark — has a specific, fixable cause, and custom properties are the fix.
What a micro-frontend split actually bought a multi-team insurance quotation platform — and what it cost.
Tailwind's default scale IS the design system for most projects — the real skill is knowing when to constrain it further, not abandon it for something custom.
BEM and CSS Modules solve the same scoping problem Tailwind solves, in earlier, more manual ways worth understanding — the problem is the actual point.
A booking race condition, two ways to fix it, and why the boring database-level answer beat the clever application-level one.
Three real approaches to styling a component, with three genuinely different runtime and maintenance tradeoffs — not a popularity ranking.
Not 'it's popular' — the specific problem Tailwind solves that hand-written CSS classes structurally can't, once a codebase and team grow large.
How Amber Car Rental moved off a no-code prototype and a third-party rental tool onto Next.js + Supabase — live, without losing a single reservation.
Unlike a Sass variable, a CSS custom property is a live runtime value the browser can recompute — the entire mechanism behind a JS-free dark-mode toggle.
Mobile-first isn't a design trend — it's a technical strategy (base styles for the smallest screen, add complexity upward) with a real reason to prefer it.
Not autocomplete, not hype — a real breakdown of where an AI coding agent earns its place in a solo full-stack workflow, and where it doesn't.
Both do layout. One is for one-dimensional arrangement; the other is two-dimensional. Most confusion comes from using one where the other fits better.
A four-part score, calculated per selector, decides which rule wins — not the order you wrote them in, and not how many !important you're willing to stack.
Every element is four nested boxes. content-box vs border-box changes what 'width: 200px' actually means — the top source of unexpected layout math.
Three different browser storage mechanisms, three different actual use cases — and the specific reason auth tokens belong in one of them and not the others.
REST isn't a technology — it's a set of architectural constraints. Knowing which constraint solves which problem is what makes an API actually RESTful.
Not a compliance checklist — the four real principles behind WCAG, and the handful of checks that catch most real-world accessibility bugs.
A <div onClick> is not a button. The actual, functional cost of reaching for generic elements instead of the semantically correct one — not a purity argument.
The general concept, for any tech stack — not the Next.js-specific mechanics covered elsewhere here, but the actual tradeoff every rendering strategy answers.
Parse, style, layout, paint, composite — the five real stages between an HTML response and visible pixels, and which ones a CSS change can skip.
The DOM is a live, in-memory tree built from your HTML — knowing it's a tree, not the HTML text itself, is what makes React's whole model click.
Methods, status codes, headers, and what TLS is actually encrypting — the protocol underneath every fetch() call, explained past the memorized 200/404/500 list.
The capstone of the why-Next.js series — SSR vs SSG, the App Router, Server Components, and the actual reasoning behind each, not just the API names.
The classic interview question, actually answered end to end — DNS, TCP, TLS, HTTP, and rendering, in the order they really happen.
CRA is deprecated. The specific gaps that pushed the React ecosystem toward Next.js explain what actually matters in a production frontend.
next/image and next/font aren't convenience wrappers — they fix two of the most common, measurable causes of a bad Core Web Vitals score, automatically.
A route.ts file in the App Router is a real backend endpoint, in the same codebase and deploy as your frontend. When that's actually enough.
Google can execute JavaScript — that is not the real argument for server rendering. The real reasons are speed, reliability, and every non-Google crawler.
Folders are routes, layout.tsx nests automatically, every page is a Server Component by default. How the pieces fit together, not just the names.
Four rendering strategies, four different answers to 'when does this HTML get generated' — and a real decision framework for which fits which page.
Create React App gives you a blank canvas and zero opinions on routing, data fetching, or SEO. A real production app needs answers to all three.
The capstone of the why-React series — every answer here traces back to the actual mechanism (closures, the virtual DOM, Server Components), not a memorized line.
'use client' isn't a styling choice — it draws a real line about where code executes, what it can access, and what ships to the browser.
Four tools all called 'state management,' solving three genuinely different problems — most complaints come from using the wrong one for the job.
Hooks weren't added for syntax convenience — they solved a real, specific problem with how class components shared and organized stateful logic.
JSX looks like it breaks the classic rule of separating markup from logic. Here's what it actually compiles to, and why that reframes the objection entirely.
Breaking a UI into small, composable pieces sounds obviously good. Worth being honest about the real cost, not just the benefit.
React answers how to build a UI. Electron answers how to ship a web app as a desktop app. Different questions, not competing answers to one.
Not a popularity contest — the real architectural tradeoffs between the four major frontend frameworks, and when each is genuinely the better choice.
Not about speed for its own sake — it's what makes 'describe the result, don't write the mutations' actually practical to implement.
Backbone, Ember, Angular.js, then React — a technical, not nostalgic, account of what each generation of frontend framework actually got right and wrong.
Before component frameworks, the frontend was direct DOM manipulation with jQuery — and the exact problem that approach hits at scale is the reason React exists.
Not another answer key — every question links to the actual mechanism, because interviewers can tell a memorized answer from real understanding.
this isn't determined by where a function is defined — it's determined by how it's called. One rule, four call patterns, one arrow-function exception.
Not a changelog — the post-2015 JavaScript features that measurably improve correctness, and the ones that are mostly syntax sugar.
Why [] + [] is an empty string, why NaN !== NaN, and the one rule that explains almost every coercion 'gotcha' people love to screenshot.
The three eras of asynchronous JavaScript, in order, and why each one exists specifically to fix a real problem with the one before it — not just as syntax sugar.
JavaScript doesn't have classes underneath the class keyword — it has objects linked to other objects. Here's what that actually means and why it matters.
A closure isn't a trick question — it's how every debounce function, every useState, and every module pattern in JavaScript actually works under the hood.
Function scope vs block scope, the temporal dead zone, and the classic closure-in-a-loop bug that var causes and let quietly fixes.
Why a setTimeout(fn, 0) doesn't run immediately, why a Promise callback jumps the queue ahead of it, and what's actually happening between the two.
Why JavaScript is single-threaded, what happens when a function is called, and why unbounded recursion crashes with a specific, nameable error.