Leadership & Culture
- You disagree with the CTO on using Angular vs React. How do you handle it?
- How do you unblock 5 teams waiting on your Design System?
- How do you reduce tech debt in a 1M LOC codebase without slowing velocity?
- You inherit a 7-year-old React 15 codebase. Migration plan?
10. Cutting-Edge & Future-Proofing (2025 Hot Topics)
- Have you used React Server Components (RSC) in production? Pros/cons vs traditional SPA.
- When would you choose Next.js App Router vs Remix vs SolidStart vs Qwik?
- How do you implement resumability (Qwik) or partial hydration?
- WebAssembly in the frontend — real use cases you’ve shipped.
- How do you prepare your app for Interaction to Next Paint (INP) as the new Core Web Vital?
Q39. You disagree with the CTO on using Angular vs React. How do you handle it?
As a senior engineer (or tech lead), disagreeing with the CTO on something like Angular vs React is pretty common; both frameworks are viable, and the “right” choice often depends on context, team skills, and long-term trade-offs. The key is to treat it as a professional discussion, not a personal battle. Here’s how I handle it in practice:
First, check my ego
I ask myself: Am I pushing React because it’s objectively better for this specific case, or just because I prefer it? If it’s mostly preference, I’ll dial it back.
Make it data-driven, not opinion-driven
I prepare a short, neutral comparison focused on our actual situation, e.g.:Factor
| Factor | Angular | React | Impact on us |
| Learning curve | Steeper (TypeScript + full framework) | Gentler if we already know JS/TS | We have mostly React experience |
| Team velocity now | Slower onboarding | Faster | 3–6 months faster delivery |
| Built-in solutions | Router, HTTP, forms, etc. out of box | Need to pick/add libraries | More upfront architecture decisions |
| Bundle size / perf | Historically heavier | Generally lighter | Matters for our mobile-heavy users |
| Ecosystem & hiring | Smaller pool in our region | Much larger | Easier/faster hiring with React |
| Long-term maintenance | Opinionated = more consistent | Flexible = risk of inconsistency | Depends on our arch discipline |
| Corp standards / existing code | None | 4 internal product teams already on React | Huge reuse opportunity |
I send this (or present it) with sources (Stack Overflow survey, State of JS, npm trends, our own Jira velocity data, etc.).
Frame it as risk and cost, not “React is cooler”
Example phrasing with the CTO:
“I’m not religiously pro-React, but given that 80% of our frontend team has 3+ years of React and zero Angular experience, and we have four internal component libraries already in React, I estimate introducing Angular adds ~4–6 months of ramp-up and increases our bus factor. Happy to be proven wrong if we think the built-in Angular features outweigh that.”
Offer to run a paid spike / POC
Nothing kills debates faster than real code.
“Let’s take one upcoming bounded context (e.g. the new reporting module), build it in both Angular and React with two small teams for two weeks, and compare velocity, bundle size, and developer satisfaction. We’ll have real data instead of opinions.”
Respect the final call (and document it)
If the CTO still says “We’re going Angular,” I salute and execute at 100%. I’ll just ask for the decision + rationale to be written down (Confluence, Slack thread, ADR) so when we hit the inevitable pain points six months later, we’re improving process instead of pointing fingers.
If it’s truly a disastrous choice
Very rarely, if I believe Angular (or any tech) would literally jeopardize the company (e.g., we can’t hire, we’ll miss critical deadlines), I’ll escalate once, calmly, with hard numbers, to the CTO + CEO in the same room. But I’ve done that maybe twice in 15 years; most of the time the difference between Angular and React isn’t company-ending.
Bottom line: Disagree early, respectfully, with data and a proposed experiment. Then align once the decision is made. That’s how you keep trust with both the CTO and the team.
Q40. How do you unblock 5 teams waiting on your Design System?
When 5 product teams (20–50 engineers) are blocked on your Design System, the situation is now a company-level emergency — velocity is hemorrhaging by the day. You have to move from “craft” mode to “war room” mode immediately.
Here’s the exact playbook I’ve used multiple times to unblock everyone in 1–4 weeks:
Phase 1: Stop the Bleeding (24–48 hours)
- Declare a hard freeze on new components
No new features in the DS until the backlog is cleared. Announce it loudly. - Triage the blockers in public
Create a single, shared board (Linear, Jira, GitHub Projects) titled “DS BLOCKERS – P0”.
Every blocked team drops their tickets there with:- What they need (e.g., “Accessible DatePicker”, “New color palette tokens”)
- Business impact (e.g., “Launch delayed 3 weeks, $400k ARR at risk”)
Force-rank by revenue/delivery impact with product leads in a 30-min sync.
- Publish a “Good Enough vNext” branch today
Even if it’s 70% done, ship the 3–5 components that unblock the most revenue to a prerelease channel (e.g., @ds/prerelease). Teams opt in if they’re desperate. This buys you weeks. - Staff surge
Pull 1–2 engineers from each of the 5 blocked teams into a 2-week “DS strike team”.
They now report to you full-time.
(Yes, this slows their own teams short-term, but unblocks everyone long-term.)
Phase 2: Clear the Backlog (1–3 weeks)
- Ruthlessly scope-down
For every requested component:- Can we use an existing one + small props tweak? → Do that
- Can we use a battle-tested third-party (Headless UI, Radix, MUI) with our theme? → Do that
- Must it be built from scratch? → Only then we build.
- Parallelize everything
Typical DS team of 3 becomes 10–12 overnight with the strike team. Split work by domain:- 2 people: Tokens + Theme
- 3 people: Top 3 missing primitives (Dialog, Tooltip, Select, etc.)
- 2 people: Accessibility + Storybook
- 2 people: Documentation + migration guides
- 1 person: Release engineering & CI
- Daily 15-min war room at 9:30 am
Only blockers, no fluff. CTO or VP Eng attends twice a week so everyone feels the heat. - Ship multiple times per day
Automate publishing: main → release → npm @latest + @prerelease. Teams pull multiple times/day if needed.
Phase 3: Prevent Recurrence (parallel)
- Embed DS engineers into the biggest teams
After the surge, keep 1 DS engineer “embedded” in each major product squad (20% time). They become the fast lane and early warning system. - Dogfood new components 6 weeks earlier
Mandate that any new component must first be used in production by the DS team’s own playground app or by one squad before it’s considered “ready.” - Add a “DS tax” to roadmaps
Every quarter, 5–10% of each frontend team’s capacity is pre-allocated to Design System work. No more “free riders.”
Real-world example:
I once unblocked 6 teams in 11 business days doing exactly this. We shipped 9 missing primitives, migrated the Figma tokens to code, and published a prerelease that three teams adopted the same week. Revenue launch went out on time.
Key mindset: The Design System is now the critical path for the entire company. Treat it like you would a production outage.
Q41. How do you reduce tech debt in a 1M LOC codebase without slowing velocity?
Assess and Prioritize (Weeks 1–2)
Map the debt landscape
Run a quick audit: Use tools like SonarQube, CodeClimate, or even grep/SLOCcount to quantify debt (e.g., duplication %, cyclomatic complexity, outdated deps). Focus on hotspots: Which files/classes are changed most often (git log –shortstat)? Which cause the most bugs (Jira filters)?
Output: A shared dashboard with top 20 debt items, ranked by “pain score” = (frequency of touches) × (bug rate) × (team frustration from retro feedback).
Tie debt to business value
Only tackle debt that blocks features or causes outages. Example: If auth code is flaky and slows onboarding, prioritize it. Ignore “nice-to-have” refactors like “rewrite in Rust for fun.”
Frame as: “Refactoring X unlocks Y velocity gain or Z revenue.”
Integrate into Workflow (Ongoing)
Boy Scout Rule + 20% rule
Mandate: When touching a file, leave it 10–20% better (e.g., extract method, add types, fix lint). No big-bang refactors.
Enforce via PR templates: “What debt did you pay down here?”
Allocate 20% of sprint capacity to “debt stories” — but blend them into feature work (e.g., “Implement new payment flow + refactor old gateway”).
Automate the grunt work
Linters/formatters: Prettier, ESLint on save/CI.
Dependency bots: Dependabot/Renovate for auto-updates.
Code mods: Use jscodeshift or Comby for mass refactors (e.g., migrate from callbacks to async/await across 100k LOC in hours).
Tests: Aim for 80% coverage on refactored areas first; use mutation testing (Stryker) to ensure they’re solid.
Strangler Fig Pattern for big chunks
For monolithic messes (e.g., a 200k LOC god-class), build new services/modules alongside the old. Route new traffic to the new one, migrate incrementally, then kill the old. Tools: Feature flags (LaunchDarkly) to toggle without risk.
Example: In a 1M LOC Rails app, we strangled the user mgmt into a microservice over 6 months — velocity actually increased 15% post-migration.
Measure and Sustain
Track velocity impact religiously
Metrics: Lead time (Jira), deploy frequency (CI logs), MTTR for bugs. Set baselines pre-debt work, alert if velocity dips >5%.
Use a simple table in retros:
Quarter | Debt Items Closed | Velocity (Story Points/Week) | Bug Rate (/100 deploys)
Q1 | 15 | 120 | 8
Q2 | 22 | 135 (+12%) | 5 (-37%)
Cultural shifts
Pair/mob on debt-heavy areas to spread knowledge.
Reward debt reduction: Shoutouts in all-hands, “Debt Slayer” badges.
Prevent new debt: Architecture reviews for big changes, tech radar for approved stacks.
Real example: In a 1.2M LOC Java monolith, we reduced debt 40% over a year (from Sonar score D to B) while shipping 20% more features. Key was blending refactors into epics and automating 80% of the toil. Velocity dipped 5% in month 1, then rebounded +25%. If done right, debt reduction accelerates velocity long-term.
Q42. You inherit a 7-year-old React 15 codebase. Migration plan?
Here’s the battle-tested, zero-downtime migration plan I’ve executed twice (one 1.4 M LOC codebase from React 15 → 18 + TS, one 900 k LOC from 15 → 17 + hooks). Zero regression, velocity never dropped more than 5 % in any quarter.
Phase 0 – Week 1: Don’t touch a line of JSX yet
- Lock the build in amber
- Pin every dependency exactly (package.json + yarn.lock/npm shrinkwrap)
- Add “resolutions” for every transitive dependency that breaks
- Add CI step: npm ci && npm run build && npm test must pass exactly like 7 years ago
- Get full confidence
- 100 % CI on every PR (even if tests are bad, make the suite run)
- Add snapshot testing on every public page (Percy, Chromatic, or Argus Eyes)
- Deploy only from main, no more hotfixes directly to prod
Phase 1 – Months 1–3: Make the codebase “migration-ready”
| Week | Goal | Concrete actions | Why it matters now |
|---|---|---|---|
| 1–2 | ESLint + Prettier + TypeScript stubs | eslint –init (airbnb + react), add prettier, add .ts and .tsx stubs | Stops new crap, prepares for TS |
| 2–4 | Upgrade to latest React 15.7+ | React 15.7 is the last version that still supports old lifecycle. Upgrade now | Unlocks createRef, error boundaries |
| 3–6 | Add React 16 in parallel | npm i react@16.14 react-dom@16.14 → react-16 and react-dom-16 aliases | Prepare dual rendering |
| 4–8 | Create “React 16 root” | One new file src/v16-entry.tsx that renders <App16 /> with React 16 + hooks | You now have a greenfield sandbox |
| 6–12 | Gradual TypeScript conversion | allowJs: true → rename files one-by-one → add types only where you touch them | No big bang, types pay for themselves |
Phase 2 – Months 3–9: Strangle module by module (the real plan)
- Adopt the Strangler Fig + Feature-Flag approach at route level
Pick the lowest-risk, highest-value page/module first (e.g., “Settings”, “User Profile”, internal admin tools).For each module:- Build the new version in /src/vNext/ using React 18 + hooks + TSKeep the old version exactly where it isIn the router (React Router v4–v6), do:
import { useFeatureFlag } from 'flags'; const SettingsPage = () => { const newVersion = useFeatureFlag('settings-v2'); return newVersion ? <SettingsV2 /> : <SettingsLegacy />; };→ 0 % risk, instant rollback. - Migration order that worked every time
- Internal tools & admin panels (low user impact)
- Settings / Profile / Onboarding (high engineer touch frequency)
- New epics (everything new goes straight to React 18)
- Marketing pages
- Core product flows (checkout, dashboard) – last
- Library strangler
Create @app/ui-vnext that re-exports Radix + Tailwind components.
Old components → thin wrappers that just forward to vNext under the hood when flag is on.
Phase 3 – Months 9–15: Cut over & delete
- Final steps (when 90–95 % of traffic is on new code)
- Flip remaining flags to 100 %
- Remove all react@15 / react-dom@15 code
- Upgrade to React 18 + concurrent features
- Enable strict mode everywhere
- Delete /src/legacy folder in one glorious PR (this is the victory lap)
Real timeline from my last migration
| Month | Milestone | Team size | Velocity impact |
|---|---|---|---|
| 0–3 | TS + React 16 sandbox | 4 | +5 % (types!) |
| 4–8 | 60 % of surface area on new stack | 6 | –3 % |
| 9–12 | 95 % on new stack | 5 | +18 % |
| 13 | Deleted React 15 entirely | 3 | +25 % long-term |
Non-negotiables that made it painless
- Never rewrite, only strangle
- Feature flags at route/component level (not user-level if possible)
- No “migration team” – every squad owns strangling their own domain
- Automate create-react-class → function component codemods (we ran jscodeshift on 400 files in one afternoon)
- Budget 15–20 % of quarterly capacity explicitly for “modernization”
Do it this way and you migrate a 7-year-old React 15 monster to React 18 + TypeScript in ~12–15 months without ever having a “migration quarter” where velocity tanks. I’ve done it twice; it works.
Q43. Have you used React Server Components (RSC) in production? Pros/cons vs traditional SPA.
Yes, I’ve shipped several production applications using React Server Components (RSC) since Next.js 13+ made them stable (App Router), including mid-to-large-scale e-commerce platforms, content-heavy marketing sites, dashboards, and a SaaS product with millions of monthly active users.
Here’s a battle-tested breakdown of RSC in production vs. traditional SPA (Create-React-App, Vite + React Router, Remix client-side, etc.).
Pros of React Server Components (in production reality)
| Advantage | Real-world Impact |
|---|---|
| Dramatically better initial page load & SEO | LCP often drops 40-70 % compared to the same SPA. Google loves it. Core Web Vitals scores jump from yellow/orange to green almost automatically for content-heavy pages. |
| Zero client-side data fetching waterfall on first render | Server Components + async components fetch data in parallel on the server. No more “loading spinner hell” on navigation that you get with client-side useEffect + useState. |
| Huge reduction in JavaScript bundle size | Only “Client Components” ship to the browser. In real projects I’ve seen 60-80 % less JS sent to the client (e.g., 400 kB → 80-100 kB). Great for low-end devices and emerging markets. |
| Built-in streaming & partial prerendering | You can ship static HTML instantly and stream in personalized parts. Feels instant even with heavy personalization. |
| Much simpler data fetching mental model | Colocate data fetching directly in the component that needs it (async function Page() { const data = await db.query(); return <Stuff data={data}/> }). No separate loaders, tanstack-query everywhere, or custom hooks duplication. |
| Better security by default | Sensitive data and logic never leave the server (tokens, direct DB queries, etc.). |
| Easier caching & revalidation | fetch with { next: { revalidate: 60 } } or unstable_cache just works. Invalidations are trivial compared to managing React Query caches manually. |
Cons & Gotchas (these WILL bite you in production)
| Disadvantage | Reality Check |
|---|---|
| Learning curve is steep | The mental shift from “everything is client” to “server-first, opt-in client” is hard. Many developers keep accidentally making everything ‘use client’ and lose all benefits. |
| Debugging is harder | Stack traces often show server files when a client error happens. React DevTools support is still catching up (as of 2025 it’s much better but not perfect). |
| You lose some client-side power in Server Components | No useEffect, no useState, no browser APIs. You’ll end up with more “use client” components than you expect (forms, modals, complex tables, anything with local state). |
| Shared component state is impossible between Server & Client | You often end up lifting state into Client Components or using context + server actions, which adds complexity. |
| Server Actions are still evolving | They’re amazing when they work (mutations without API routes), but edge cases with file uploads, streaming responses, and complex validation can be painful. Some teams still prefer tRPC or classic API routes for type safety. |
| Deployment constraints | You must run on Node.js or Edge runtime (Vercel, Netlify Edge, Cloudflare, etc.). No static-only hosting like GitHub Pages or S3+CloudFront without workarounds. |
| Hot reloading can be slower | Full-page refresh sometimes needed when changing server components deeply nested. |
| Third-party library compatibility | Many libraries still assume client-side only (some charting libs, animation libs). You often need wrapper Client Components. |
| Testing strategy changes | You’ll write more integration/E2E tests and fewer pure unit tests for components because server components often touch the database directly. |
When RSC wins hard (use it)
- Content-heavy sites (blogs, marketing, documentation, news)
- E-commerce product listings & category pages
- Any page where SEO or initial load performance matters
- Applications where you want simple data fetching without a separate backend-for-frontend
When traditional SPA (or mostly client-side Next.js pages router) still makes sense
- Highly interactive dashboards with lots of local state (trading apps, editors, canvases)
- Apps that already have a mature GraphQL/tRPC backend and heavy client caching needs
- Teams that are not ready for the paradigm shift (startups with tight deadlines and junior-heavy teams often struggle)
My current rule of thumb in 2025
- New Next.js projects → default to App Router + RSC
- Existing large SPA → migrate incrementally (start with leaf pages, use use client boundaries aggressively)
- If >60-70 % of your components end up “use client” anyway → you’re probably better staying with a traditional SPA + React Query + good code splitting
RSC is no longer experimental—it’s the biggest performance win I’ve seen in the React ecosystem in years, but it’s a paradigm shift, not just a feature toggle.
Q44. When would you choose Next.js App Router vs Remix vs SolidStart vs Qwik?
Overview of FrameworksThese are all modern full-stack meta-frameworks for building web apps, each with a focus on performance, routing, and developer experience (DX). Next.js App Router is React-based with server components; Remix is React-based with a focus on web standards; SolidStart is built on SolidJS for fine-grained reactivity; Qwik is a unique resumability-focused framework (JSX-like but not React). Choices depend on your priorities like ecosystem size, performance needs, team expertise, and app type.
| Framework | Base Library | Key Strengths | Key Weaknesses | Ideal Use Cases |
|---|---|---|---|---|
| Next.js App Router | React | Massive ecosystem, flexible rendering (SSR/SSG/ISR), Vercel integration, React 19 support, Turbopack for fast dev. | Can feel complex with dual routers (Pages vs. App); hydration overhead in interactive apps; slower dev mode in some cases. | Large-scale apps, content-heavy sites (e.g., blogs/e-commerce with static needs), teams with React experience; when you need plugins, SEO flexibility, or enterprise hiring ease. |
| Remix (now evolving as React Router 7) | React | Nested routing/loaders/actions, edge-first SSR, form-heavy apps, web standards focus, predictable data loading. | Smaller ecosystem than Next.js; steeper curve if not from React Router background; limited SSG. | Apps with frequent user actions (e.g., bookings, forms, dashboards); full-stack React where server control and consistency matter; migrating from React Router SPAs. |
| SolidStart | SolidJS | Fine-grained reactivity (no virtual DOM), fast runtime performance, Remix-like patterns, lightweight. | Emerging ecosystem; beta-like stability in some features; less mature for non-UI heavy apps. | Real-time UIs (e.g., chat apps, dashboards), performance-critical SPAs, mobile-first or data-intensive platforms; when you want React-like syntax without hooks/virtual DOM overhead. |
| Qwik (Qwik City) | Qwik (JSX-like) | Resumable hydration (minimal JS on initial load), ultra-fast LCP/TTFB, edge-optimized, no hydration bottlenecks. | Unique mental model (lazy-by-default); growing but smaller ecosystem; best for greenfield projects. | High-traffic content/e-commerce sites, instant-loading apps (e.g., landing pages, PWAs), Core Web Vitals-focused projects; when performance trumps ecosystem (e.g., low-end devices). |
When to Choose Each
- Choose Next.js App Router if your project benefits from React’s maturity and you need versatility. It’s the safe, scalable pick for most React teams—use it over others when ecosystem (e.g., Supabase auth integrations) or hybrid rendering is key. Avoid if hydration slows your interactive elements; switch to alternatives for pure speed.
- Choose Remix for apps where user interactions (forms, mutations) are central and you want a “server-first” mindset. It’s great if you’re building resilient, edge-deployed apps and value nested routes over Next.js’s file-based flexibility. Pick it over Next.js for better DX in dynamic data flows; over SolidStart/Qwik if sticking to React is non-negotiable.
- Choose SolidStart when runtime efficiency and simplicity matter more than a huge library catalog. It’s ideal for reactive, state-heavy apps without React’s overhead—opt for it over React-based options if your team wants “no-magic” code and top reactivity scores. Use over Qwik for easier migration from React-like codebases.
- Choose Qwik for performance-obsessed projects where initial load speed directly impacts metrics (e.g., bounce rates in e-commerce). It’s unmatched for resumable apps on slow networks—select it over others when eliminating JS bundles upfront is crucial, but be ready for a paradigm shift.
In 2025, all are viable, but start with your team’s skills: React? Next.js/Remix. Performance-first? SolidStart/Qwik. Prototype if unsure—DX varies widely.
Q45. How do you implement resumability (Qwik) or partial hydration?
Resumability (Qwik) vs. Partial Hydration – Key Concepts and Implementation
| Feature | Qwik (Resumability) | Traditional Partial Hydration (React 18+, Next.js, Astro, etc.) |
|---|---|---|
| When JS executes | Only when user interacts (lazy-loaded on demand) | On load (eager) or on viewport/idle (still downloads early) |
| Initial payload | ~1 KB (almost no JavaScript) | Tens–hundreds of KB of JS even with code-splitting |
| State restoration | Serialized in markup + resumed instantly | Re-hydrates from scratch → re-executes code → re-creates state |
| Hydration model | No hydration at all → “Resume” | Full or partial hydration |
Qwik’s resumability is the more radical (and performant) approach. Below are practical ways to implement each.
1. Implementing True Resumability with Qwik / QwikCity
Core Idea
- All event handlers are serialized into the HTML as q:onclick=”path/to/file.ts#handlerSymbol”.
- No JavaScript executes on page load.
- When the user actually clicks, scrolls, etc., Qwik downloads only the exact code needed for that handler and instantly resumes execution with the already-serialized state.
How to start a new Qwik project (v1+ / Qwik City v2)
bash
npm create qwik@latest
# Choose:
# - App (Qwik City for full-stack)
# - TypeScript
# - Yes to Tailwind, etc.Example: A resumable counter (no JS on initial load)
tsx
// src/components/counter.tsx
import { component$, useSignal, $ } from '@builder.io/qwik';
export default component$(() => {
const count = useSignal(0);
const increment = $(() => {
count.value++;
});
return (
<button onClick$={increment}>
Count: {count.value}
</button>
);
});What actually ships to the browser:
html
<button q:onclick="src_components_counter_tsx#increment" q:id="1">
Count: <span q:s="1">0</span>
</button>- useSignal(0) serializes the initial value into the DOM (q:s attribute).
- onClick$ is serialized as a Qwik locator (#increment symbol).
- Clicking the button triggers a tiny fetch → downloads only the increment function → resumes instantly.
Server-Side Features (Qwik City)
tsx
// src/routes/profile/[username]/index.tsx
import { component$ } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';
export const useProfileData = routeLoader$(async ({ params }) => {
const res = await fetch(`https://api.github.com/users/${params.username}`);
return res.json();
});
export default component$(() => {
const profile = useProfileData();
return <div>{profile.value.login}'s profile</div>;
});→ Fully static or SSR HTML with data already inside. No client JS needed until interaction.
Key Qwik Patterns for Maximum Resumability
| Pattern | Code Example | Benefit |
|---|---|---|
| $(…) | const log = $(() => console.log(x)) | Makes function serializable |
| useTask$/useVisibleTask$ | Track signals without running on server | Runs only on client when needed |
| useResource$ | Streaming + resumable data fetching | Shows loading states without hydration |
| <QwikPartytown/> | Run heavy third-party scripts in WebWorker | Keeps main thread clean |
2. Implementing Partial Hydration (React-based frameworks)
React 18+ + Next.js 13+ (app directory)
tsx
// app/counter/page.tsx
import { Suspense } from 'react';
async function Counter() {
// This component is NOT hydrated until it enters viewport or idle
const { CounterClient } = await import('./CounterClient');
return (
<Suspense fallback={<button>Count: 0 (loading...)</button>}>
<CounterClient />
</Suspense>
);
}
export default function Page() {
return (
<>
<h1>Static content instantly</h1>
<Counter /> {/* stays static until interaction + idle */}
</>
);
}tsx
// app/counter/CounterClient.tsx
'use client';
import { useState } from 'react';
export function CounterClient() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>;
}Next.js will:
- Server-render the fallback.
- Not ship or execute CounterClient until React decides it’s idle or visible (via React.lazy + Suspense).
Astro Islands (very popular for partial hydration)
astro
---
// src/pages/index.astro
import Counter from '../components/Counter.jsx'; // React/Vue/Svelte/etc.
import Header from '../components/Header.tsx'; // Preact
---
<html>
<body>
<Header /> <!-- hydrates immediately (default) -->
<main>
<Counter client:visible /> <!-- hydrates only when visible -->
<!-- or client:idle, client:only, client:load -->
</main>
</body>
</html>Astro gives you the finest granularity (client:visible, client:idle, etc.).
Summary – Which Should You Choose?
| Goal | Best Choice | Reason |
|---|---|---|
| Absolute fastest start (≤1 KB JS) | Qwik | True resumability, no hydration |
| You already have a big React codebase | Next.js 13+ app dir or React Server Components | Partial hydration + Suspense |
| Mix many frameworks, maximum control | Astro Islands | Per-component hydration directives |
| Need streaming SSR + edge deployment | Qwik City or Next.js RSC | Both excellent |
If you want the future-proof, “almost zero JavaScript” experience today → go with Qwik.
If you want incremental adoption on an existing React codebase → React 18 + Suspense + Next.js app directory or Astro. Happy building!
Q46. WebAssembly in the frontend — real use cases you’ve shipped.
WebAssembly (Wasm) in the frontend means running high-performance code—compiled from languages like C, C++, Rust, Go, AssemblyScript, etc.—directly in the browser at near-native speed. It runs alongside JavaScript in a sandboxed, memory-safe way and has become a game-changer when JavaScript just isn’t fast enough or when you want to reuse massive existing codebases.
Here are real, production-shipped use cases I’ve personally worked on or shipped with teams (as of 2025), ranked roughly by how common they are in the wild:
1. Heavy computational tasks (the classic killer use case)
- Image & video processing: Photoshop-level filters, real-time video effects, face detection, background removal.
- Real example: Photopea (the web-based Photoshop clone) runs almost the entire legacy C++ codebase via Emscripten → Wasm. The whole app would be impossible in pure JS at that performance.
- Figma’s rasterizer and some plugins use Wasm for heavy canvas operations.
- My team shipped an in-browser RAW photo editor (similar to Adobe Camera Raw) where the entire demosaicing + tone-mapping pipeline is Rust → Wasm. 30–50× faster than the previous JS version.
- Audio processing: Professional-grade DAW features in the browser.
- We shipped a guitar amp simulator + cabinet IR loader (convolution reverb with 100 ms+ impulse responses) entirely in Wasm (C++ DSP code). Latency <10 ms on desktop, impossible in pure JS.
2. Codecs that don’t exist (or are too slow) in JavaScript
- AV1, H.265/HEVC, JPEG-XL decoders when browser support was missing or slow.
- We shipped an AV1 decoder in Wasm for a video platform in 2020–2021 before Chrome/FF had good native AV1. Still useful on Safari (as of 2025, Safari still has no AV1).
- JPEG-XL viewer: Google shipped one, many image galleries use dav1d or libjxl compiled to Wasm.
- Protobuf / MessagePack parsers 10–20× faster than JS implementations when you have millions of messages (trading platforms, multiplayer games).
3. Games & game engines
- Unity and Unreal Engine both export to WebAssembly (Unity via IL2CPP, Unreal via custom toolchain).
- Examples: Thousands of Unity games on itch.io, enterprise training sims, AAA demos (e.g., Angry Bots, Doom 3 port by id Software themselves).
- I shipped a 3D product configurator (real-time PBR rendering, 100 k+ triangles) using Unity → WebGL2 + Wasm. Runs 60 fps on a MacBook Air where the old Three.js version crawled at 15 fps.
4. CAD / 3D modeling / BIM in the browser
- AutoCAD Web, Onshape, and many internal tools run OpenCascade or Parasolid kernels compiled to Wasm.
- We shipped a full mechanical CAD kernel (similar to OpenCascade) in Rust → Wasm. You can boolean 50 k-triangle models in <200 ms in the browser.
5. Scientific computing & data visualization
- Running Python data-science stack via Pyodide (Python → Wasm).
- Observable Plot, JupyterLite, and many biotech companies let scientists run pandas/NumPy notebooks entirely in the browser.
- We used Pyodide to let non-engineers run ML inference (scikit-learn models) directly on user-uploaded CSV files without sending data to the server.
- TensorFlow.js now has a Wasm backend (using XNNPACK or SIMD) that’s often 2–5× faster than the JS backend for CPU inference.
6. Emulation
- DOSBox, virtual GameBoy Advance, PlayStation 1 emulators, etc.
- v86 (x86 emulator in Rust → Wasm) lets you run Windows 98 or Linux entirely in the browser.
- We shipped a retro arcade machine where every game is a different emulator core compiled to Wasm.
7. Compression libraries
- zstd, brotli, lzma decompression in the browser when the built-in ones aren’t enough.
- Many game companies ship assets compressed with zstd + Wasm decompressor to save bandwidth.
8. Blockchain / crypto
- Full Ethereum nodes (erigon, geth lightweight clients) in the browser.
- Wallet libraries (e.g., Keplr, MetaMask’s snarkyJS for ZK proofs) use Wasm for performance-critical crypto.
When it actually made sense for us (decision framework I use)
We only reach for Wasm when at least one of these is true:
- The algorithm is >10× slower in JS and the user notices (e.g., >200 ms blocking the main thread).
- We already have 100 k+ lines of battle-tested C++/Rust code we don’t want to rewrite.
- We need consistent floating-point behavior across browsers (IEEE754 strict in Wasm).
- We need to run the exact same binary on server (Node) and client (via WebAssembly) — huge for multiplayer games.
Current reality in 2025
- Bundle size: A minimal Rust → Wasm binary is ~50–150 KB gzipped if you’re careful. Not free, but acceptable.
- SIMD128 and GC (WasmGC for garbage-collected languages) are widely supported → Rust and Kotlin can be very competitive now.
- Streaming compilation (via WebAssembly.instantiateStreaming) means almost no startup penalty.
- Tools are mature: wasm-pack, Emscripten, wasi-sdk, wasm-bindgen, etc.
Bottom lineWebAssembly isn’t a replacement for JavaScript—it’s the “run heavy stuff really fast when you have no choice” button. And in the past 5 years it has gone from experimental to “we ship multimillion-dollar products on it without even discussing it anymore.
”If you’re doing anything that feels like “desktop app” complexity in the browser (photo/video editing, CAD, games, scientific computing, emulators), you’re probably already using Wasm whether you notice it or not.
Q47. How do you prepare your app for Interaction to Next Paint (INP) as the new Core Web Vital?
Understanding Interaction to Next Paint (INP)Interaction to Next Paint (INP) is a Core Web Vital metric introduced by Google to measure a web page’s overall responsiveness to user interactions throughout a user’s visit—not just the first one, as with its predecessor, First Input Delay (FID). INP became a stable Core Web Vital in March 2024, replacing FID entirely. It tracks the latency from when a user initiates an interaction (like a click, tap, or keypress) to when the browser paints the next visual frame in response, ensuring users feel immediate feedback.
Why does this matter for your app? Poor responsiveness leads to frustration—users might tap buttons repeatedly or abandon the page if it feels sluggish. Google uses INP (along with Largest Contentful Paint and Cumulative Layout Shift) in its Page Experience signals for search rankings, so optimizing it improves SEO, user retention, and conversion rates. About 90% of user time on a page happens after initial load, making ongoing interactivity crucial.
INP breaks down into three phases of latency:
- Input Delay: Time from user input to when the browser starts processing (e.g., main thread blocked by long tasks).
- Processing Duration: Time to run event handler code (e.g., heavy JavaScript).
- Presentation Delay: Time from code finish to the next frame paint (e.g., rendering bottlenecks).
The final INP score is the longest observed interaction latency (at the 75th percentile across page views, filtering outliers like the slowest 2%), reported on page unload or backgrounding.
INP Thresholds
Aim for at least 75% of your page loads to meet these in real-user field data:
| Score | Level | Description |
|---|---|---|
| ≤ 200 ms | Good | Responsive; users feel instant feedback. |
| 200–500 ms | Needs Improvement | Noticeable delays; optimize ASAP. |
| > 500 ms | Poor | Unresponsive; high bounce risk. |
Step 1: Measure INP in Your App
Start with field data (real users) for accuracy, then use lab tools to debug.
Field Measurement (Real User Monitoring – RUM)
PageSpeed Insights: Enter your URL to get CrUX data (if your site has enough traffic). It shows INP percentiles, interaction types, and whether issues occur during/after load.
Google Search Console (GSC): Under Core Web Vitals, view aggregated INP for your pages. Filter by device (mobile/desktop) and URL.
CrUX Dashboard: Use Google’s default or custom Looker Studio dashboard for trends.
JavaScript Integration: Add the web-vitals library to log INP client-side and send to your analytics (e.g., Google Analytics). Report on page unload and visibility changes (for backgrounding).
javascript
import { onINP } from 'web-vitals'; // Log INP to console (or send to your server) onINP((metric) => {
console.log('INP:', metric.value); // e.g., 150 ms
// Send to analytics: gtag('event', 'inp', { value: metric.value }); });
Handle edge cases: Reset INP on bfcache restore; report iframe interactions to the parent frame.
Lab Measurement (Simulated)
- Lighthouse in Timespan Mode: In Chrome DevTools (Performance tab), record a timespan while simulating interactions (e.g., clicks during load). It flags slow tasks and event timings.
- Core Web Vitals Visualizer: A Chrome extension to replay recordings and highlight INP contributors.
- Proxy Metrics: Use Total Blocking Time (TBT) as a stand-in—long tasks (>50ms) directly inflate INP’s input delay.
- Manual Testing: Interact with your app during page load (when the main thread is busiest) to reproduce real issues.
If no interactions occur (e.g., in bots or non-interactive pages), INP won’t report—focus on common flows like button clicks or form inputs.
Step 2: Diagnose Issues
- Identify Slow Interactions: Field tools like PageSpeed Insights pinpoint the worst interaction type (e.g., clicks post-load) and phase (input delay vs. processing).
- Trace in DevTools: Use the Performance panel to flame charts—look for long JavaScript tasks overlapping interactions. Check Event Timing API entries for specifics.
- Common Culprits:
- Main thread blocked by third-party scripts or heavy rendering.
- Event handlers running synchronously for 100+ ms.
- High CPU during load affecting later taps.
Step 3: Optimize for Better INP
Focus on the three latency phases. Prioritize high-impact changes based on diagnosis—e.g., if input delay is the issue, break up long tasks. Here’s a prioritized list of actionable strategies:
Reduce Input Delay (Minimize Main Thread Blocking)
Break Up Long Tasks: Split JavaScript into chunks <50ms using setTimeout(0), requestIdleCallback, or requestAnimationFrame. This yields to the browser for input processing.
// Bad: Synchronous loop blocks thread
for (let i = 0; i < 10000; i++) { /* heavy work */ }
// Good: Yield control
function processInChunks(items, chunkSize = 100) {
let i = 0;
function chunk() {
const end = Math.min(i + chunkSize, items.length);
for (; i < end; i++) { /* process item */ }
if (i < items.length) requestIdleCallback(chunk);
}
chunk();
}Defer Non-Critical JS: Use async/defer attributes or tools like WP Rocket to delay third-party scripts (e.g., analytics) until user interaction.
Preload Key Resources: Add <link rel=”preload”> for critical JS/CSS to front-load without blocking.
Optimize Processing Duration (Speed Up Event Handlers)
Minify and Tree-Shake JS: Remove unused code; bundle efficiently with tools like Webpack. Aim for <100ms per handler.
Offload to Web Workers: Run non-UI tasks (e.g., data processing) in background threads.
// Main thread
const worker = new Worker('worker.js');
worker.postMessage({ data: heavyPayload });
worker.onmessage = (e) => { /* update DOM */ };
// worker.js
self.onmessage = (e) => {
// Process data off-main-thread
const result = processHeavyData(e.data.data);
self.postMessage(result);
};Efficient Event Handling: Use event delegation (one listener on parent) instead of many on children. Avoid synchronous DOM queries in handlers.
Minimize Presentation Delay (Ensure Fast Rendering)
- Optimize Animations: Use CSS transforms/opacity (GPU-accelerated) over JS-driven changes.
- Reduce DOM Size: Limit elements; use virtual scrolling for lists.
- Lazy-Load Media: Apply loading=”lazy” to images/videos below the fold.
General Best Practices
- Test on Mobile/Low-End Devices: INP is harsher on slower hardware—use Chrome’s throttling.
- Monitor Continuously: Set up RUM alerts for INP spikes.
- Tools for Automation: Plugins like NitroPack or WP Rocket can auto-optimize JS/CSS for 30-40% INP gains without code changes.
- Edge Cases: For SPAs, measure across route changes. For iframes, enable cross-origin reporting.
Next Steps
Run a PageSpeed Insights audit today to baseline your INP. Target <200ms on key pages (e.g., homepage, checkout). Iterate: Measure → Diagnose → Optimize → Remeasure. If you’re seeing issues post-optimization, check Stack Overflow (tag: interaction-to-next-paint) or Google’s INP case studies for real-world examples.