Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Frontend Engineering — Architecture, Performance, and Production Reality

​

Real-World Stories: Why Frontend Engineering Matters

​

Part I — Frontend Architecture & Rendering

​

1. Component Architecture

​

1.1 Mental Models Across Frameworks

function ProductCard({ product, onAddToCart }) {
  const [quantity, setQuantity] = useState(1);
  
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} />
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <input 
        type="number" 
        value={quantity} 
        onChange={(e) => setQuantity(Number(e.target.value))} 
      />
      <button onClick={() => onAddToCart(product.id, quantity)}>
        Add to Cart
      </button>
    </div>
  );
}

<script setup>
import { ref } from 'vue';

const props = defineProps(['product']);
const emit = defineEmits(['addToCart']);
const quantity = ref(1);
</script>

<template>
  <div class="product-card">
    <img :src="product.image" :alt="product.name" />
    <h3>{{ product.name }}</h3>
    <p>${{ product.price }}</p>
    <input type="number" v-model.number="quantity" />
    <button @click="emit('addToCart', product.id, quantity)">
      Add to Cart
    </button>
  </div>
</template>

@Component({
  selector: 'app-product-card',
  template: `
    <div class="product-card">
      <img [src]="product.image" [alt]="product.name" />
      <h3>{{ product.name }}</h3>
      <p>{{ product.price | currency }}</p>
      <input type="number" [(ngModel)]="quantity" />
      <button (click)="onAddToCart()">Add to Cart</button>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ProductCardComponent {
  @Input() product!: Product;
  @Output() addToCart = new EventEmitter<{id: string, qty: number}>();
  quantity = 1;

  onAddToCart() {
    this.addToCart.emit({ id: this.product.id, qty: this.quantity });
  }
}

​

1.2 Composition vs. Inheritance

• Flexibility: A component that accepts children or render props can be used in contexts the author never anticipated. An inherited component can only extend the base class.
• Testability: Composed components can be tested in isolation. Inherited components carry implicit behavior from their entire ancestor chain.
• Readability: With composition, you can see every behavior a component uses by reading its imports and hooks. With inheritance, you have to trace the entire class hierarchy.

// Composition: flexible, explicit
function SearchableList({ items, renderItem, onSearch }) {
  const [query, setQuery] = useState('');
  const filtered = items.filter(item => 
    item.name.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <div>
      <SearchInput value={query} onChange={setQuery} />
      <ul>{filtered.map(renderItem)}</ul>
    </div>
  );
}

// Usage -- the parent decides how to render each item
<SearchableList 
  items={products} 
  renderItem={(p) => <ProductCard key={p.id} product={p} />}
/>

​

1.3 Component Patterns That Scale

// Presenter -- pure UI, no data fetching
function OrderList({ orders, onCancel, isLoading }) {
  if (isLoading) return <Skeleton count={5} />;
  return (
    <ul>
      {orders.map(order => (
        <OrderRow key={order.id} order={order} onCancel={onCancel} />
      ))}
    </ul>
  );
}

// Container -- data fetching and business logic
function OrderListContainer() {
  const { data: orders, isLoading } = useQuery(['orders'], fetchOrders);
  const cancelMutation = useMutation(cancelOrder, {
    onSuccess: () => queryClient.invalidateQueries(['orders']),
  });

  return (
    <OrderList 
      orders={orders ?? []} 
      isLoading={isLoading} 
      onCancel={(id) => cancelMutation.mutate(id)} 
    />
  );
}

​

2. Rendering Strategies

​

2.1 Client-Side Rendering (CSR)

1. Browser requests the page. Server sends a near-empty HTML document.
2. Browser downloads and parses the JavaScript bundle (50KB-2MB+ depending on the app).
3. JavaScript executes, makes API calls, builds the DOM.
4. User sees a blank page (or spinner) until step 3 completes.

• Authenticated dashboards behind a login wall (SEO does not matter, users expect a loading state).
• Highly interactive applications like design tools (Figma), spreadsheets (Google Sheets), or IDEs (VS Code for Web) where the entire app is a single interactive surface.
• Internal tools where Time to Interactive matters more than First Contentful Paint.

• Content-heavy pages that need SEO (blogs, e-commerce product pages, marketing sites).
• Low-end devices and slow networks — a 500KB JS bundle takes 8-15 seconds to parse and execute on a low-end Android phone on a 3G connection.
• Pages where first meaningful paint matters — users see nothing until all JS has downloaded and executed.

​

2.2 Server-Side Rendering (SSR)

1. Browser requests the page. Server runs the component tree, fetches data, generates complete HTML.
2. Browser receives full HTML and renders it immediately — the user sees content.
3. Browser downloads and executes JavaScript.
4. JavaScript “hydrates” the existing HTML — attaching event listeners, restoring state, making it interactive.
5. The page is now fully interactive (Time to Interactive).

​

2.3 Static Site Generation (SSG)

• Content that changes infrequently (documentation, blogs, marketing pages).
• Pages that are the same for every user (no personalization in the initial HTML).
• Sites where build time is acceptable (a 10,000-page site might take 10-30 minutes to build).

• Frequently updated content (a news site with hundreds of articles per day cannot rebuild the entire site for each article).
• Personalized content (the page is different for every user — cannot pre-render at build time).
• Very large sites (100,000+ pages create build times measured in hours).

​

2.4 Incremental Static Regeneration (ISR)

// Next.js Pages Router ISR
export async function getStaticProps() {
  const products = await fetchProducts();
  return {
    props: { products },
    revalidate: 60, // Regenerate at most every 60 seconds
  };
}

​

2.5 Streaming SSR

// React 18 with Suspense boundaries
function ProductPage({ productId }) {
  return (
    <Layout>
      <Header />
      <Suspense fallback={<ProductSkeleton />}>
        <ProductDetails productId={productId} />
      </Suspense>
      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews productId={productId} />
      </Suspense>
    </Layout>
  );
}

​

2.6 React Server Components (RSC) — What They Actually Change

1. Runs on the server to generate HTML (SSR).
2. The component’s JavaScript is sent to the client (~5-50KB for the component + its dependencies).
3. The component re-executes on the client during hydration.

1. Runs on the server. Its rendered output (not its source code) is streamed to the client.
2. Zero JavaScript is sent to the client for this component.
3. No hydration needed for this component.

​

2.7 Framework Comparison for Rendering

​

3. State Management

​

3.1 The State Management Hierarchy

​

3.2 Server State vs Client State

// Server state -- use TanStack Query
function useProducts(category) {
  return useQuery({
    queryKey: ['products', category],
    queryFn: () => fetch(`/api/products?cat=${category}`).then(r => r.json()),
    staleTime: 5 * 60 * 1000, // Consider fresh for 5 minutes
    gcTime: 30 * 60 * 1000,   // Keep in cache for 30 minutes
  });
}

// Client state -- use component state or Zustand
const useCartStore = create((set) => ({
  items: [],
  addItem: (product, qty) => set((state) => ({
    items: [...state.items, { product, qty }],
  })),
  removeItem: (productId) => set((state) => ({
    items: state.items.filter(i => i.product.id !== productId),
  })),
}));

​

3.3 State Library Comparison

​

3.4 State Machines (XState)

idle -> loading -> success
idle -> loading -> error -> idle (retry)

// XState machine for an async operation
const fetchMachine = createMachine({
  id: 'fetch',
  initial: 'idle',
  context: { data: null, error: null },
  states: {
    idle: {
      on: { FETCH: 'loading' },
    },
    loading: {
      invoke: {
        src: 'fetchData',
        onDone: { target: 'success', actions: assign({ data: (_, e) => e.data }) },
        onError: { target: 'error', actions: assign({ error: (_, e) => e.data }) },
      },
    },
    success: {
      on: { RESET: 'idle' },
    },
    error: {
      on: { RETRY: 'loading', RESET: 'idle' },
    },
  },
});

// Bad -- new object every render, all consumers re-render
<ThemeContext.Provider value={{ theme, setTheme }}>

// Better -- memoize the value
const value = useMemo(() => ({ theme, setTheme }), [theme]);
<ThemeContext.Provider value={value}>

// Bad -- new function identity every render
<List onItemClick={(id) => handleClick(id)} />

// Better -- stable reference
const handleItemClick = useCallback((id) => handleClick(id), [handleClick]);
<List onItemClick={handleItemClick} />

​

4. Micro-Frontends

​

4.1 When Micro-Frontends Make Sense (Hint: Rarely)

• You have 5+ teams shipping features to different sections of the same application.
• Teams need independent deployment — Team A cannot be blocked by Team B’s broken build.
• Teams use different frameworks (one team is Angular, another is React) and a full rewrite is not feasible.
• The application is large enough that a monolithic build takes 30+ minutes and affects developer velocity.

• You have fewer than 3-4 frontend teams. The coordination overhead exceeds the independence benefit.
• Your teams can reasonably share a codebase (same framework, same repo, compatible release cadence).
• Performance is a top priority. Micro-frontends add overhead: multiple framework runtimes, duplicate dependencies, inter-app communication costs.

​

4.2 Implementation Approaches

// webpack.config.js for the "product" micro-frontend
new ModuleFederationPlugin({
  name: 'product',
  filename: 'remoteEntry.js',
  exposes: {
    './ProductCard': './src/components/ProductCard',
    './ProductGrid': './src/components/ProductGrid',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.0.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
  },
});

​

Part II — Performance & Core Web Vitals

​

5. Core Web Vitals Deep Dive

​

5.1 Largest Contentful Paint (LCP)

​

5.2 Interaction to Next Paint (INP)

1. Long event handlers: An onClick that synchronously filters 10,000 items, re-sorts them, and updates a complex component tree can take 200-500ms. Fix: debounce heavy operations, use startTransition (React 18+) to mark non-urgent updates, move computation to a Web Worker.
2. Layout thrashing in handlers: Reading layout properties (offsetHeight, getBoundingClientRect) and then writing to the DOM (changing styles) in the same handler forces the browser to recalculate layout synchronously. Fix: batch reads and writes separately, use requestAnimationFrame for DOM writes.
3. Third-party scripts blocking the main thread: Analytics scripts, chat widgets, and ad scripts that register long-running event listeners. Fix: load third-party scripts with async/defer, use loading="lazy" on iframes, audit third-party impact with Chrome DevTools Performance panel.
4. Hydration blocking interaction: On SSR pages, the user clicks a button before hydration completes. The browser queues the event, but the handler is not yet attached. Once hydration finishes and the handler fires, the time since the click counts as input delay. Fix: use selective hydration (React 18), islands architecture (Astro), or resumability (Qwik).

​

5.3 Cumulative Layout Shift (CLS)

​

6. JavaScript Performance

​

6.1 Bundle Size — The Silent Killer

// React lazy loading -- each route is a separate chunk
const ProductPage = lazy(() => import('./pages/ProductPage'));
const CartPage = lazy(() => import('./pages/CartPage'));
const CheckoutPage = lazy(() => import('./pages/CheckoutPage'));

function App() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Routes>
        <Route path="/product/:id" element={<ProductPage />} />
        <Route path="/cart" element={<CartPage />} />
        <Route path="/checkout" element={<CheckoutPage />} />
      </Routes>
    </Suspense>
  );
}

// Don't import a 200KB chart library in the main bundle
// Load it only when the user navigates to the analytics page
const ChartComponent = lazy(() => import(
  /* webpackChunkName: "charts" */
  './components/AnalyticsChart'
));

​

6.2 Runtime Performance

// Bad -- blocks main thread for entire duration
function processLargeList(items) {
  items.forEach(item => {
    expensiveOperation(item); // Blocks until all items processed
  });
}

// Better -- yield to the main thread between chunks
async function processLargeList(items) {
  const CHUNK_SIZE = 100;
  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    chunk.forEach(item => expensiveOperation(item));
    // Yield to the main thread -- allows browser to handle user input
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

// Best -- use scheduler.yield() (Chrome 115+) or requestIdleCallback
async function processLargeList(items) {
  for (const item of items) {
    expensiveOperation(item);
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield(); // Give priority to pending user input
    }
  }
}

// main.js
const worker = new Worker(new URL('./heavy-computation.worker.js', import.meta.url));
worker.postMessage({ data: largeDataset, operation: 'filter-and-sort' });
worker.onmessage = (event) => {
  updateUI(event.data.result); // UI stays responsive during computation
};

// heavy-computation.worker.js
self.onmessage = (event) => {
  const { data, operation } = event.data;
  const result = performExpensiveWork(data, operation);
  self.postMessage({ result });
};

​

6.3 Memory Leaks in SPAs

1. Uncleared event listeners:

// Leak -- listener persists after component unmounts
useEffect(() => {
  window.addEventListener('resize', handleResize);
  // Missing cleanup! handleResize and everything it closes over stays in memory
}, []);

// Fix
useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize); // Cleanup
}, []);

2. Uncleared timers and intervals:

// Leak -- interval runs forever
useEffect(() => {
  setInterval(() => fetchNotifications(), 30000);
}, []);

// Fix
useEffect(() => {
  const id = setInterval(() => fetchNotifications(), 30000);
  return () => clearInterval(id);
}, []);

3. Stale closures holding large data:

// Leak -- the closure holds a reference to a large dataset
function DataProcessor({ dataset }) { // dataset is 50MB
  useEffect(() => {
    const unsubscribe = eventBus.subscribe('update', () => {
      process(dataset); // This closure keeps dataset alive even after unmount
    });
    return () => unsubscribe();
  }, []); // Empty deps -- dataset reference is captured once and never released
}

4. Detached DOM nodes: Components that create DOM elements outside React’s tree (portals, tooltips, direct DOM manipulation) may not clean them up on unmount.

​

7. Asset Optimization

​

7.1 Image Optimization

<picture>
  <!-- AVIF for browsers that support it (best compression) -->
  <source 
    type="image/avif" 
    srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <!-- WebP fallback -->
  <source 
    type="image/webp" 
    srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <!-- JPEG ultimate fallback -->
  <img 
    src="hero-800.jpg" 
    alt="Product hero image"
    width="1200" height="800"
    loading="lazy"
    decoding="async"
  />
</picture>

​

7.2 Font Loading Strategies

<link 
  rel="preload" 
  href="/fonts/inter-var-latin.woff2" 
  as="font" 
  type="font/woff2" 
  crossorigin
/>

​

7.3 Critical CSS and Resource Hints

• <link rel="preconnect" href="https://fonts.googleapis.com"> — Establish the TCP/TLS connection to a third-party origin early. Saves 100-300ms per origin.
• <link rel="preload" href="/critical.css" as="style"> — Tell the browser to download this resource immediately at high priority.
• <link rel="prefetch" href="/next-page.js"> — Download this resource at low priority during idle time.
• <link rel="dns-prefetch" href="https://analytics.example.com"> — Resolve the DNS for this origin ahead of time.

​

8. Performance Budgets

​

8.1 Setting Frontend Performance Budgets

​

8.2 Enforcing Budgets

# lighthouserc.yml
ci:
  assert:
    assertions:
      categories:performance:
        - error
        - minScore: 0.9
      largest-contentful-paint:
        - error
        - maxNumericValue: 2500
      cumulative-layout-shift:
        - error
        - maxNumericValue: 0.1

{
  "size-limit": [
    { "path": "dist/index.js", "limit": "50 KB" },
    { "path": "dist/vendor.js", "limit": "150 KB" },
    { "path": "dist/**/*.css", "limit": "30 KB" }
  ]
}

​

8.3 RUM vs Synthetic Monitoring

​

Part III — Testing & Quality

​

9. Frontend Testing Strategy

​

9.1 The Testing Trophy for Frontend

​

9.2 What to Test (and What NOT to Test)

• User-facing behavior. “When I click ‘Add to Cart’, the cart count increases.”
• Error states. “When the API returns 500, the error message is displayed.”
• Accessibility. “The modal can be closed with the Escape key.”
• Edge cases in business logic. “When the discount exceeds the item price, the total is $0, not negative.”

• Implementation details. Do not test that useState was called with a specific value.
• Third-party library internals.
• Exact snapshot matching of large component trees.
• Pixel-perfect layouts. Use visual regression testing (Chromatic, Percy) instead.

// Good test -- tests behavior from user perspective
test('adding item to cart updates the cart count', async () => {
  render(<ProductPage product={mockProduct} />);
  
  expect(screen.getByText('Cart (0)')).toBeInTheDocument();
  
  await userEvent.click(screen.getByRole('button', { name: /add to cart/i }));
  
  expect(screen.getByText('Cart (1)')).toBeInTheDocument();
});

// Bad test -- tests implementation details
test('calls setCartItems when button is clicked', () => {
  const setCartItems = jest.fn();
  jest.spyOn(React, 'useState').mockReturnValue([[], setCartItems]);
  // This breaks on any refactor and tests React, not your code
});

​

9.3 E2E Testing: Playwright vs Cypress

​

10. Accessibility Engineering

​

10.1 WCAG 2.1 AA — What You Actually Need to Know

1. Color contrast: Normal text must have a contrast ratio of at least 4.5:1. Large text must have at least 3:1.
2. Keyboard navigation: Every interactive element must be reachable and operable with a keyboard.
3. Focus indicators: When an element receives keyboard focus, there must be a visible indicator. Use :focus-visible to show focus rings only for keyboard navigation.
4. Alt text for images: Every <img> must have an alt attribute. Decorative images need alt="".
5. Form labels: Every input must have an associated <label>. Placeholder text is not a label.

​

10.2 ARIA Patterns That Matter

// Modal dialog -- focus must be trapped inside
function Modal({ isOpen, onClose, title, children }) {
  const modalRef = useRef(null);
  
  useEffect(() => {
    if (isOpen) {
      modalRef.current?.querySelector('button, [href], input')?.focus();
      const handleKeyDown = (e) => {
        if (e.key === 'Escape') onClose();
        if (e.key === 'Tab') {
          const focusable = modalRef.current.querySelectorAll(
            'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
          );
          const first = focusable[0];
          const last = focusable[focusable.length - 1];
          if (e.shiftKey && document.activeElement === first) {
            e.preventDefault();
            last.focus();
          } else if (!e.shiftKey && document.activeElement === last) {
            e.preventDefault();
            first.focus();
          }
        }
      };
      document.addEventListener('keydown', handleKeyDown);
      return () => document.removeEventListener('keydown', handleKeyDown);
    }
  }, [isOpen, onClose]);
  
  if (!isOpen) return null;
  
  return (
    <div role="dialog" aria-modal="true" aria-labelledby="modal-title" ref={modalRef}>
      <h2 id="modal-title">{title}</h2>
      {children}
      <button onClick={onClose}>Close</button>
    </div>
  );
}

​

10.3 Focus Management in SPAs

​

10.4 Legal Requirements

• ADA (Americans with Disabilities Act): Major lawsuits: Domino’s Pizza (2019), Target ($6M settlement in 2008).
• European Accessibility Act (EAA): Takes effect June 28, 2025. Requires private sector digital products sold in the EU to meet accessibility standards.

​

11. Design Systems

​

11.1 Token-Based Design

​

11.2 Component API Design

1. Composability over configuration. Prefer <Card><CardHeader /><CardBody /></Card> over <Card headerTitle="..." bodyContent="..." />.
2. Sensible defaults, explicit overrides. A <Button> should look correct with zero props.
3. Consistent prop naming. If <Button> uses variant, so should <Badge>, <Alert>, and <Tag>.
4. Forward refs and spread rest props. Components should forward ref and spread additional HTML attributes.

​

11.3 Versioning and Adoption

​

Part IV — Frontend System Design

​

12. Frontend System Design Interview Patterns

​

12.1 Design a Real-Time Collaborative Text Editor

​

12.2 Design an Infinite Scroll Feed

​

12.3 Design a Complex Form Wizard

​

13. Browser Internals That Matter

​

13.1 The Event Loop

1. Macrotask queue: setTimeout, setInterval, I/O callbacks.
2. Microtask queue: Promise.then/catch/finally, queueMicrotask, MutationObserver.

​

13.2 The Critical Rendering Path

​

13.3 Reflow vs Repaint

/* Bad -- reflow every frame */
.animate-bad:hover { left: 100px; top: 50px; }

/* Good -- composite only */
.animate-good:hover { transform: translate(100px, 50px); }

​

13.4 How V8 Optimizes JavaScript

​

14. Security in the Browser

​

14.1 XSS Prevention

1. Output encoding: React’s JSX auto-escapes by default. dangerouslySetInnerHTML bypasses this.
2. Content Security Policy (CSP): HTTP header restricting script sources. script-src 'self' 'nonce-abc123'.
3. Sanitization: DOMPurify for user-provided HTML.

​

14.2 CSRF, CORS, and Cookie Security

• HttpOnly — Not accessible from JavaScript.
• Secure — Only sent over HTTPS.
• SameSite=Strict — Never sent on cross-site requests.

​

14.3 Third-Party Script Risks

​

Part V — Modern Frontend & Career

​

15. Modern Frontend Trends

​

15.1 Edge Rendering

​

15.2 Islands Architecture

​

15.3 Resumability (Qwik)

​

15.4 WebAssembly in the Browser

​

15.5 AI-Assisted UI Development

​

16. Cross-Chapter Connections

​

16.1 Frontend and API Design

​

16.2 CDN Strategy

​

16.3 Authentication Flows

​

16.4 Frontend Observability

​

Interview Questions Compendium

​

Entry-Level Questions

​

Mid-Level Questions

const { data } = useQuery({
  queryKey: ['search', debouncedQuery],
  queryFn: ({ signal }) => fetch(`/api/search?q=${debouncedQuery}`, { signal }),
  enabled: debouncedQuery.length >= 2,
  placeholderData: keepPreviousData,
});

​

Senior-Level Questions

​

Additional Questions

​

Follow-Up Question Handling

​

Buying Time Gracefully

• “That’s a great question — let me think about the rendering implications for a moment.”
• “Before I answer, are we optimizing for Time to Interactive or Largest Contentful Paint? The solutions are different.”
• “Let me trace through the browser’s behavior step by step…”
• “I want to be precise here rather than give a hand-wavy answer.”

​

Redirecting to Strength

• “I haven’t worked deeply with [framework], but the underlying problem works the same way. In React, I would…”
• “I know the observable behavior is [X], and I’ve used that to [optimization]. The exact V8 internals — I’d want to verify.”

​

Admitting Gaps with Confidence

• “I haven’t hit that edge case in production, but my instinct is [X] because [reasoning]. I’d validate by [investigation step].”
• “That’s at the boundary of my knowledge. What I do know is [related thing], and I’d learn this by [reading the spec / building a minimal repro].”

​

Professional Best Practices Checklist

​

Before — Planning and Setup

• Define rendering strategy (CSR/SSR/SSG/ISR) based on SEO, freshness, and personalization requirements
• Establish performance budget with numeric targets for LCP, INP, CLS, bundle size
• Set up TypeScript in strict mode
• Choose state management strategy by categorizing all state types
• Configure ESLint with accessibility rules (eslint-plugin-jsx-a11y)
• Set up Lighthouse CI and bundle size checks from day one

​

During — Execution

• Test from user perspective using Testing Library queries (getByRole, getByText)
• Lazy-load below-the-fold content and heavy dependencies
• Use semantic HTML first, ARIA second
• Set explicit dimensions on images and video
• Profile before optimizing — use React DevTools Profiler before adding useMemo

​

After — Review and Monitoring

• Monitor Core Web Vitals in production (RUM), segmented by device and geography
• Review error tracking weekly — fix top 3 errors by frequency
• Audit dependencies quarterly for security, unused packages, and bloat
• Run accessibility audits with keyboard and screen reader, not just automated tools
• Track bundle size trends over time

​

When Things Go Wrong

• JS errors in production: Check error tracker for stack trace, affected count, session replay. New deployment regression? Rollback.
• CWV regression: Check CrUX dashboard, compare deployments, audit third-party scripts.
• Blank page: JavaScript error preventing rendering. Check console. Common causes: uncaught promise rejection, failed module import.
• Hydration mismatch: Compare server/client output. Common causes: browser extensions, window checks, timezone differences.

​

Above & Beyond

​

Advanced Techniques

​

Cross-Domain Connections

• Frontend ↔ Distributed Systems: CRDTs, eventual consistency, and optimistic updates are direct applications of distributed systems theory.
• Frontend ↔ Networking: TCP, TLS, HTTP/2 multiplexing, and HTTP/3 QUIC directly inform performance optimization.
• Frontend ↔ Operating Systems: The browser event loop is analogous to an OS scheduler. Web Workers mirror thread offloading.
• Frontend ↔ Product Thinking: Every rendering/performance/accessibility decision is ultimately a product decision.

​

Emerging Trends (2025-2027)

• React Compiler (React Forget): Automatic memoization, eliminating manual useMemo/useCallback.
• TC39 Signals proposal: Native JavaScript reactivity primitive standardizing framework reactivity.
• AI-powered testing: Session replay + AI generating E2E test suites from real user behavior.
• WebGPU: Modern GPU API for compute shaders, ML inference, and graphics in the browser.
• Multi-page app transitions: View Transitions API for cross-document navigations.

​

Recommended Reading

​

Beginner

• web.dev Learn Performance — Best structured introduction to web performance fundamentals.
• React documentation (react.dev) — Genuinely excellent. Start with “Learn React.”
• Testing Library docs — The philosophy section is as important as the API docs.

​

Intermediate

• Patterns.dev by Lydia Hallie & Addy Osmani — Free book covering modern web development patterns.
• Web Performance in Action by Jeremy Wagner — Practical performance optimization.
• Inclusive Components by Heydon Pickering — Accessible component patterns.

​

Advanced

• High Performance Browser Networking by Ilya Grigorik (free) — Deep dive into TCP, TLS, HTTP/2, WebSocket from a browser perspective.
• CRDT resources by Martin Kleppmann — Essential for collaborative features.
• Chrome DevTools Performance docs — The frontend equivalent of learning to read a database EXPLAIN plan.

​

Part VI — Production Frontend Engineering

​

17. Hydration Failures — Diagnosis, Root Causes, and Production Fixes

​

17.1 Common Hydration Failure Patterns

// Causes hydration mismatch
function PostTimestamp({ createdAt }) {
  // Server: formats in UTC. Client: formats in user's timezone.
  return <time>{new Date(createdAt).toLocaleDateString()}</time>;
}

// Fix: render a stable value, then update on client
function PostTimestamp({ createdAt }) {
  const [formatted, setFormatted] = useState(
    // Use ISO format during SSR -- timezone-agnostic
    new Date(createdAt).toISOString().split('T')[0]
  );
  
  useEffect(() => {
    // Client-only: format in user's locale
    setFormatted(new Date(createdAt).toLocaleDateString());
  }, [createdAt]);
  
  return <time dateTime={createdAt}>{formatted}</time>;
}

// Causes mismatch: window does not exist on server
function MobileOnlyBanner() {
  if (window.innerWidth < 768) {
    return <Banner text="Download our app!" />;
  }
  return null;
}

// Fix: defer to client
function MobileOnlyBanner() {
  const [isMobile, setIsMobile] = useState(false);
  useEffect(() => {
    setIsMobile(window.innerWidth < 768);
  }, []);
  return isMobile ? <Banner text="Download our app!" /> : null;
}

​

17.2 Debugging Hydration Failures in Production

​

18. SSR, RSC, and Client Boundary Trade-offs

​

18.1 The Boundary Decision Framework

​

18.2 Common Boundary Mistakes

// Bad: entire page becomes a client component because of one click handler
"use client";
export default function ProductPage({ product }) {
  return (
    <div>
      <ProductDescription product={product} />  {/* 50KB of markdown rendering */}
      <ProductSpecs specs={product.specs} />     {/* Pure display */}
      <AddToCartButton productId={product.id} /> {/* The ONLY interactive part */}
    </div>
  );
}

// Good: only the interactive part is a client component
// app/product/[id]/page.tsx (Server Component -- no directive needed)
export default function ProductPage({ product }) {
  return (
    <div>
      <ProductDescription product={product} />  {/* Stays on server */}
      <ProductSpecs specs={product.specs} />     {/* Stays on server */}
      <AddToCartButton productId={product.id} /> {/* Client component */}
    </div>
  );
}

// components/AddToCartButton.tsx
"use client";
export function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? 'Added' : 'Add to Cart'}</button>;
}

​

18.3 The RSC Mental Model for Senior Engineers

• Server Components can be cached independently from client components
• Server Components can be streamed — the client can start rendering Client Components while Server Components are still executing
• Server Components and Client Components can be interleaved in the tree — a Server Component can render a Client Component child, which can render a Server Component grandchild (via the children prop pattern)

​

19. Frontend Observability — Beyond Error Tracking

​

19.1 The Four Pillars of Frontend Observability

• Error rate spike (> 2x baseline within 15 minutes) — likely a deployment regression
• New error type appearing for > 1% of sessions — likely a new bug
• Error concentrated in a single browser/OS combination — likely a compatibility issue

• Device class (high-end, mid-range, low-end)
• Connection type (4G, 3G, WiFi)
• Geography (CDN edge proximity matters)
• Page type (homepage vs product page vs checkout)
• User cohort (new vs returning, free vs paid)

// Custom performance marks for business-critical interactions
performance.mark('checkout-button-clicked');
// ... async operations ...
performance.mark('checkout-confirmed');
performance.measure('checkout-flow', 'checkout-button-clicked', 'checkout-confirmed');

// Report to RUM provider
const measure = performance.getEntriesByName('checkout-flow')[0];
analytics.track('checkout_duration_ms', measure.duration);

// Propagate trace context in fetch calls
const traceId = crypto.randomUUID();
fetch('/api/products', {
  headers: {
    'x-trace-id': traceId,
    'traceparent': `00-${traceId}-${spanId}-01`,  // W3C Trace Context
  },
});

// Backend correlates this trace with its own spans
// Observability platform (Datadog, Honeycomb) shows the full waterfall

​

19.2 Alerting Strategy for Frontend

​

20. Auth and Session Edge Cases in the Browser

​

20.1 Token Lifecycle Edge Cases

// Tab coordination for token refresh
const channel = new BroadcastChannel('auth');
let isRefreshing = false;

async function refreshToken() {
  if (isRefreshing) {
    // Wait for the other tab to finish
    return new Promise((resolve) => {
      channel.onmessage = (event) => {
        if (event.data.type === 'TOKEN_REFRESHED') {
          resolve(event.data.token);
        }
      };
    });
  }
  
  isRefreshing = true;
  const newToken = await callRefreshEndpoint();
  channel.postMessage({ type: 'TOKEN_REFRESHED', token: newToken });
  isRefreshing = false;
  return newToken;
}

​

20.2 SSR Auth Patterns and Pitfalls

​

20.3 Third-Party Cookie Restrictions

• OAuth redirect flows that rely on third-party cookies for session linking
• Embedded iframes (payment widgets, chat widgets) that need their own cookies
• Analytics that use cross-domain cookies for user identification

​

21. CDN Behavior and Caching Edge Cases

​

21.1 The CDN Mental Model

​

21.2 Caching Strategy by Asset Type

​

21.3 CDN Failure Modes That Break Production

​

22. TypeScript and API Contract Safety

​

22.1 Why TypeScript Matters for Production Frontend

API schema (OpenAPI/GraphQL) -> Generated TypeScript types -> Frontend code -> Runtime validation (Zod/io-ts)

​

22.2 Generated Types from API Schemas

// openapi-typescript generates types from your OpenAPI spec
// api-types.ts (auto-generated, never edited manually)
export interface components {
  schemas: {
    Product: {
      id: string;
      name: string;
      price: number;
      currency: "USD" | "EUR" | "GBP";
      inventory_count: number;
      created_at: string; // ISO 8601
    };
  };
}

// Usage in your fetch layer
import type { components } from './api-types';
type Product = components['schemas']['Product'];

async function fetchProduct(id: string): Promise<Product> {
  const res = await fetch(`/api/products/${id}`);
  return res.json(); // TypeScript trusts this is Product
}

​

22.3 Runtime Validation with Zod

import { z } from 'zod';

const ProductSchema = z.object({
  id: z.string().uuid(),
  name: z.string().min(1),
  price: z.number().positive(),
  currency: z.enum(['USD', 'EUR', 'GBP']),
  inventory_count: z.number().int().nonnegative(),
  created_at: z.string().datetime(),
});

type Product = z.infer<typeof ProductSchema>; // TypeScript type derived from schema

async function fetchProduct(id: string): Promise<Product> {
  const res = await fetch(`/api/products/${id}`);
  const data = await res.json();
  return ProductSchema.parse(data); // Throws ZodError if shape is wrong
}

​

22.4 End-to-End Type Safety Patterns

​

23. Production Debugging Paths

​

23.1 The Universal Triage Framework

​

23.2 Debugging Path: White Page / Blank Screen

1. Check the console. A white page in a React SPA almost always means an uncaught JavaScript error prevented rendering. The error is in the console.
2. Check if HTML was delivered. View page source. If the HTML is present (SSR), the issue is a client-side JS error during hydration or initialization. If the HTML is empty (<div id="root"></div>), the issue is that JS never executed.
3. Check if JS loaded. Network panel — did the main JS bundle return 200? If 404, the deployment deleted old assets while the CDN was still serving old HTML with old bundle references.
4. Check for CSP violations. Console will show “Refused to execute inline script” if a Content Security Policy blocks your scripts. Common after CDN or infrastructure changes that alter script nonces.
5. Check for chunk loading failures. If code-split chunks fail to load (CDN issue, ad blocker intercepting), React’s lazy() throws an error. Without a Suspense error boundary, this crashes the entire app.

​

23.3 Debugging Path: Partial Rendering / Missing Sections

1. Check if the section’s data loaded. Network panel — did the API call for that section succeed? If it returned an error or empty data, the issue is backend.
2. Check if the component rendered. React DevTools — is the component in the tree? If the component is in the tree but invisible, check CSS (display: none, opacity: 0, height: 0, overflow: hidden).
3. Check for error boundaries. If the section’s component threw an error and an error boundary caught it, the section renders the fallback (which might be nothing). Check Sentry for error boundary catches on that route.
4. Check for race conditions. If the section depends on data from a parent component, and the parent’s data arrived after the section’s Suspense timeout, the section might have fallen back to the loading state permanently. Check the waterfall timing.
5. Check feature flags. Is the section behind a feature flag that was accidentally turned off?

​

23.4 Debugging Path: Bundle Size Regression

1. Identify what was added. Run npx source-map-explorer dist/main.js (or @next/bundle-analyzer) on the current and previous builds. Diff the treemaps.
2. Common culprits:
   • A new dependency pulled in a transitive dependency (e.g., adding date-fns but the import syntax pulled the entire library instead of tree-shaking).
   • A dynamic import was accidentally changed to a static import, pulling a lazy chunk into the main bundle.
   • A dev-only dependency (Storybook, test utilities) leaked into the production build.
   • CSS-in-JS library added at the component level that duplicates styles.
3. Fix by category:
   • Wrong import: change to named import from a subpath (import debounce from 'lodash/debounce' instead of import { debounce } from 'lodash').
   • Lost code splitting: verify React.lazy() and dynamic import() are used for route-level components.
   • Dev dependency in prod: check package.json for misplaced devDependencies.
4. Prevent recurrence: Add size-limit to CI with per-chunk budgets. Any PR that exceeds the budget fails the check.

​

23.5 Debugging Path: “Works on My Machine” — Browser-Specific Bugs

1. Check Sentry for browser/OS distribution. Is the error concentrated in Safari 16? Chrome on Android? Samsung Internet?
2. Check for missing polyfills. Features like structuredClone, AbortController.any(), or CSS @container queries are not available in all browsers. Check caniuse.com against your support matrix.
3. Check for Safari-specific behavior. Safari handles Date parsing differently (rejects 2026-04-11 without time zone), has stricter ITP cookie policies, and implements some CSS differently (flexbox gap in older versions).
4. Check for extension interference. Ask the user if they have ad blockers, privacy extensions, or corporate security software. These can block scripts, modify DOM, or intercept network requests.
5. Test in BrowserStack/LambdaTest. If you cannot reproduce locally, use a cloud browser testing service to test the exact browser/OS/version combination.

​

24. Rollout Safety and Experiment Impact

​

24.1 Progressive Rollout for Frontend Changes

​

24.2 Measuring Experiment Impact on Frontend Metrics

• Compare CWV (LCP, INP, CLS) between control and treatment, segmented by device class
• Compare JS error rates between variants — a new feature may work for 99% of users but crash for the 1% on older browsers
• Check for interaction effects with other experiments — two experiments modifying the same page section can create unexpected CLS
• Measure time-to-interactive for the specific feature, not just page-level metrics

​

24.3 Rollback Strategies

​

25. Accessibility Regressions — Prevention and Detection

​

25.1 How Accessibility Regresses

• A developer replaces a <button> with a <div onClick> because they want custom styling. Keyboard and screen reader support vanish.
• A design change reduces contrast from 4.5:1 to 3.8:1. It looks “fine” visually but fails WCAG AA.
• A modal redesign removes the focus trap. Screen reader users can now interact with content behind the modal.
• A dynamic content loader does not announce new content via aria-live. Screen reader users do not know new items appeared.
• A team adds a custom dropdown using <div> elements instead of <select> and does not implement the ARIA listbox pattern.

​

25.2 Automated Accessibility Testing in CI

// .eslintrc
{
  "extends": ["plugin:jsx-a11y/recommended"]
}

// Using jest-axe in component tests
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

test('ProductCard has no accessibility violations', async () => {
  const { container } = render(<ProductCard product={mockProduct} />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

// Playwright with @axe-core/playwright
import AxeBuilder from '@axe-core/playwright';

test('checkout page is accessible', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

• Navigate the entire flow using only keyboard
• Test with VoiceOver (macOS) and NVDA (Windows)
• Test with screen zoom at 200%
• Test with forced colors mode (Windows High Contrast)

​

25.3 Preventing Regressions Organizationally

• Storybook accessibility addon: Every component shows real-time accessibility violations in the Storybook panel. Developers see issues during development, not in code review.
• PR review checklist item: “Does this PR change any interactive element? If yes, has keyboard navigation been tested?”
• Design system as guardrail: If the design system’s <Button> component handles keyboard, focus, and ARIA correctly, individual teams cannot regress by using it. Regressions come from teams building custom components outside the design system.
• Accessibility champions: One engineer per team is designated as the accessibility point-of-contact. They review PRs that touch interactive components and escalate systemic issues.