DEV Community: Tiago

Why JavaScript String Length Lies to You

Tiago — Wed, 18 Feb 2026 16:27:19 +0000

If you've ever truncated a string in JavaScript and ended up with garbled characters or broken emoji, you've encountered one of the language's most subtle gotchas: JavaScript strings don't work the way most developers assume they do.

Consider this innocent-looking truncation function:

function truncate(str, maxLength) {
  return str.slice(0, maxLength);
}

This works fine for basic ASCII text. But pass it a string containing emoji — "Hello 👋 world" — and slice at the wrong position, and you might end up with a corrupted character that displays as � or breaks downstream systems entirely.

To understand why, we need to distinguish between three concepts: code points, code units, and grapheme clusters. JavaScript's most familiar string APIs — .length, indexing, .slice() — operate on code units, but developers often expect them to correspond to the visual units they see on screen. They frequently don't: what appears as a single character might be stored as two, four, or even more code units internally.

How Text Is Represented in Unicode

Code Points

A code point is Unicode's abstract representation of a character. The Unicode Standard assigns a unique number — ranging from 0 to 0x10FFFF — to every character, symbol, and control sequence. The letter "A" is code point U+0041. The emoji "😀" is code point U+1F600. The regional indicator symbol for "G" is code point U+1F1EC.

Code points are the logical unit of text. When we think about "characters" in human terms, we're usually thinking at the grapheme cluster level — what we perceive as a single visual character — though a grapheme cluster can consist of multiple code points, as we'll see shortly.

Code Units

A code unit is the minimal bit combination used to represent a single unit of encoded text in a particular encoding scheme. Different encodings use different code unit sizes: UTF-8 uses 8-bit code units, UTF-32 uses 32-bit code units, and UTF-16 — the encoding JavaScript uses internally — uses 16-bit code units.

Here's where the complexity begins. The Unicode codespace extends to 0x10FFFF (over 1.1 million possible code points), but a 16-bit code unit can only represent values from 0 to 0xFFFF (65,536 values). This means UTF-16 cannot represent every code point with a single code unit.

Whether a code point can be encoded as a single UTF-16 code unit depends on its position in the codespace:

The Basic Multilingual Plane (BMP) — Code points U+0000 to U+FFFF. These fit in a single 16-bit code unit. This includes most common characters: Latin alphabets, Cyrillic, Greek, Chinese, Japanese, Korean, and many symbols.
Supplementary Planes — Code points U+10000 to U+10FFFF. These require two 16-bit code units, called a surrogate pair. This includes emoji, mathematical symbols, historic scripts, and rare CJK characters.

A surrogate pair consists of a high surrogate (U+D800 to U+DBFF) followed by a low surrogate (U+DC00 to U+DFFF). These ranges are reserved specifically for this purpose — they don't represent any characters on their own.

For example, the emoji "😀" (U+1F600) is encoded in UTF-16 as the surrogate pair \uD83D\uDE00.

Grapheme Clusters

A grapheme cluster is what users perceive as a single visual character — the smallest unit of text that a human reader would identify as a distinct character. Unicode Standard Annex #29 defines the rules for determining grapheme cluster boundaries.

The critical insight is that a grapheme cluster can consist of multiple code points. Some examples:

Flag emoji — The 🇬🇧 flag is two code points: Regional Indicator Symbol Letter G (U+1F1EC) followed by Regional Indicator Symbol Letter B (U+1F1E7). When adjacent, they render as a single flag.
Skin tone modifiers — The 👋🏽 waving hand with medium skin tone is two code points: the base emoji (U+1F44B) followed by a skin tone modifier (U+1F3FD).
ZWJ sequences — The 👨‍👩‍👧 family emoji is five code points: man, Zero-Width Joiner, woman, ZWJ, girl. The ZWJ (U+200D) tells rendering systems to combine them into a single glyph.
Combining marks — The character "é" can be represented either as a single precomposed code point (U+00E9) or as two code points: "e" (U+0065) followed by a combining acute accent (U+0301).

What JavaScript Actually Does

JavaScript strings are sequences of 16-bit values. The ECMAScript specification is explicit about this — it defines a String value as "a finite ordered sequence of zero or more 16-bit unsigned integer values." In practice, JavaScript treats these values as UTF-16 code units — methods like codePointAt() decode surrogate pairs accordingly.

This design decision has cascading consequences across the entire string API.

Length Counts Code Units

The .length property returns the number of code units, not characters:

"hello".length; // 5 — five code units, five code points
"😀".length; // 2 — two code units, one code point
"👨‍👩‍👧".length; // 8 — eight code units, five code points, one grapheme
"🇬🇧".length; // 4 — four code units, two code points, one grapheme

Indexing Returns Code Units

Bracket notation and .charAt() return individual code units:

"hello"[0]; // "h"
"😀"[0]; // "\uD83D" — the high surrogate, not a valid character
"😀"[1]; // "\uDE00" — the low surrogate, not a valid character

Slice Operates on Code Units

The .slice() and .substring() methods use code unit indices:

"hello".slice(0, 2); // "he" — works as expected
"😀😀".slice(0, 2); // "😀" — accidentally correct (two code units = one emoji)
"😀😀".slice(0, 3); // "😀\uD83D" — corrupted: complete emoji + orphan surrogate

Why This Causes Real Bugs

When you naively truncate user-generated content — say, for a preview or database field limit — you risk:

Visual corruption — Orphan surrogates display as the replacement character (�) or, depending on the font, as empty boxes or nothing at all.
Broken emoji — A flag like 🇬🇧 sliced in the middle becomes two separate regional indicators that may render as boxed letters or not render at all.
Encoding failures — Some systems reject strings containing orphan surrogates. Protocol buffers, for instance, require valid UTF-8, and an orphan surrogate cannot be validly encoded in UTF-8 (surrogates are not valid Unicode scalar values).
Character count mismatches — If your UI shows "12/100 characters" but counts code units while displaying graphemes, users will be confused when some emoji count as 2 or 4 or 8.

Safe Truncation Strategies

Code Point-Safe Truncation

If you need to preserve code points (avoiding orphan surrogates), spread the string into an array:

function truncateCodePoints(str, maxCodePoints) {
  return [...str].slice(0, maxCodePoints).join("");
}

truncateCodePoints("😀😀😀", 2); // "😀😀" — two code points

The spread syntax uses the string's Symbol.iterator, which iterates by code point rather than code unit. Surrogate pairs are kept together.

However, this still doesn't handle grapheme clusters. Flag emoji and ZWJ sequences will still be split:

truncateCodePoints("🇬🇧🇫🇷", 2); // "🇬🇧" — works because each flag is exactly two code points
truncateCodePoints("🇬🇧🇫🇷", 3); // "🇬🇧🇫" — split the French flag, shows GB flag + unpaired F indicator
truncateCodePoints("👨‍👩‍👧", 3); // "👨‍👩" — split the family, rendering varies by platform

Grapheme-Safe Truncation

For proper grapheme cluster handling, use Intl.Segmenter:

function truncateGraphemes(str, maxGraphemes) {
  const segmenter = new Intl.Segmenter("en", { granularity: "grapheme" });
  const segments = [...segmenter.segment(str)];
  return segments
    .slice(0, maxGraphemes)
    .map((s) => s.segment)
    .join("");
}

truncateGraphemes("🇬🇧🇫🇷", 1); // "🇬🇧" — one grapheme cluster
truncateGraphemes("👨‍👩‍👧👨‍👩‍👧", 1); // "👨‍👩‍👧" — one grapheme cluster
truncateGraphemes("Hello 👋🏽", 6); // "Hello " — six graphemes (the space counts)
truncateGraphemes("Hello 👋🏽", 7); // "Hello 👋🏽" — seven graphemes

Intl.Segmenter has been available in all major browsers since April 2024 (Baseline Newly available) and in Node.js since v16.

Key Takeaways

JavaScript strings are sequences of UTF-16 code units. The .length property, indexing, and methods like .slice() all operate on code units — not code points or grapheme clusters.

This mismatch between JavaScript's internal representation and human intuition about "characters" is a frequent source of bugs. Any code that assumes .length returns the number of visible characters, or that slicing at an arbitrary index produces valid text, is potentially broken for input containing emoji, combining marks, or any other text where a single visual character spans multiple code units or code points.

The safest approach is to treat strings as opaque sequences when possible, use [...str] iteration when you need code point access, and reach for Intl.Segmenter when you need to match user-perceived character boundaries.

This article was inspired by Attio's engineering blog post about a production bug caused by naive string truncation.

Frontend Coding Challenge — Chat-Like Interface (Part 2)

Tiago — Tue, 10 Feb 2026 13:03:23 +0000

This is Part 2 of a two-part series. Part 1 covered requirements analysis, architecture decisions, and sending messages.

Now we need to wire up the jump links: clicking "Jump to First" or "Jump to Last" should scroll that message into view and highlight it for 1 second.

Scrolling to a Specific Message

We already implemented messageRefs, a Map storing refs to each message element. The same Map that powers auto-scroll also enables jumping to any message:

const jumpToMessage = (id: number) => {
  messageRefs.current.get(id)?.scrollIntoView({ behavior: "smooth" });
};

Since we're using 0-based IDs (matching array indices), the first message has ID 0 and the last has ID messages.length - 1:

<div className="jump-links">
  <button onClick={() => jumpToMessage(0)}>Jump to First</button>
  <button onClick={() => jumpToMessage(messages.length - 1)}>Jump to Last</button>
</div>

Adding the Highlight

When we jump to a message, we also need to highlight it:

const jumpToMessage = (id: number) => {
  messageRefs.current.get(id)?.scrollIntoView({ behavior: "smooth" });
  setHighlightedId(id);
};

The CSS from Part 1 already handles the visual:

.message.highlighted {
  background: #fff3cd;
}

The Timeout

The highlight should disappear after 1 second. A first attempt:

const jumpToMessage = (id: number) => {
  messageRefs.current.get(id)?.scrollIntoView({ behavior: "smooth" });
  setHighlightedId(id);

  setTimeout(() => {
    setHighlightedId(null);
  }, 1000);
};

This works for a single click, but has a problem: if the user clicks "Jump to First" and then "Jump to Last" within a second, both timeouts are scheduled. The first timeout will clear the highlight prematurely.

We need to cancel the previous timeout when starting a new one. A ref can hold the timeout ID:

const highlightTimeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null);

const jumpToMessage = (id: number) => {
  messageRefs.current.get(id)?.scrollIntoView({ behavior: "smooth" });
  setHighlightedId(id);

  if (highlightTimeoutRef.current !== null) {
    clearTimeout(highlightTimeoutRef.current);
  }

  highlightTimeoutRef.current = setTimeout(() => {
    setHighlightedId(null);
  }, 1000);
};

Now clicking a new jump link cancels the previous timeout, and only the latest highlight will clear after 1 second.

Cleanup on Unmount

If the component unmounts while a timeout is pending, the callback would still fire and call setHighlightedId(null) on an unmounted component. In React 18+ this is silently ignored, but it's still a wasted call — and in older React versions it produced a warning. A cleanup effect prevents this:

useEffect(() => {
  return () => {
    if (highlightTimeoutRef.current !== null) {
      clearTimeout(highlightTimeoutRef.current);
    }
  };
}, []);

The empty dependency array means the effect body runs once after the initial render, and the returned cleanup function runs on unmount.

Requirements Checklist

All requirements are now implemented:

✓ Display 9 hardcoded messages on load
✓ Send messages via button click
✓ Empty messages cannot be sent
✓ List scrolls to bottom on new message
✓ Jump links scroll to first or last message
✓ Jumped-to message is highlighted
✓ Highlight disappears after 1 second
✓ Only one message highlighted at a time
✓ Auto-focus input on load (nice-to-have)
✓ Send with Enter key (nice-to-have)

What We'd Improve

We could consider the following improvement points in order to deliver more robust, production-ready code:

Extract components — Separate concerns into focused components with clear props.

Handle empty state — If this component were extended to support message deletion, we'd want to show an empty state and disable the jump buttons when there are no messages. The messageRefs Map already handles deletion cleanly via the callback ref's null branch.

Accessibility — Move focus to the target message after jumping, and use an aria-live region to announce new messages to screen readers.

Final Code

App.tsx

import { useState, useRef, useEffect } from "react";
import "./App.css";

const initialMessages = Array.from({ length: 9 }, (_, i) => ({
  id: i,
  text: `Message ${i + 1}`,
}));

function App() {
  const [messages, setMessages] = useState(initialMessages);
  const [highlightedId, setHighlightedId] = useState<number | null>(null);
  const [inputValue, setInputValue] = useState("");

  const messageRefs = useRef<Map<number, HTMLDivElement>>(new Map());
  const highlightTimeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null);

  useEffect(() => {
    const lastId = messages.length - 1;
    messageRefs.current.get(lastId)?.scrollIntoView({ behavior: "smooth" });
  }, [messages]);

  useEffect(() => {
    return () => {
      if (highlightTimeoutRef.current !== null) {
        clearTimeout(highlightTimeoutRef.current);
      }
    };
  }, []);

  const handleSend = () => {
    const trimmed = inputValue.trim();

    if (!trimmed) {
      return;
    }

    setMessages((prev) => [...prev, { id: prev.length, text: trimmed }]);
    setInputValue("");
  };

  const jumpToMessage = (id: number) => {
    messageRefs.current.get(id)?.scrollIntoView({ behavior: "smooth" });
    setHighlightedId(id);

    if (highlightTimeoutRef.current !== null) {
      clearTimeout(highlightTimeoutRef.current);
    }

    highlightTimeoutRef.current = setTimeout(() => {
      setHighlightedId(null);
    }, 1000);
  };

  return (
    <div className="app">
      <div className="jump-links">
        <button onClick={() => jumpToMessage(0)}>Jump to First</button>
        <button onClick={() => jumpToMessage(messages.length - 1)}>Jump to Last</button>
      </div>

      <div className="message-list">
        {messages.map((message) => (
          <div
            key={message.id}
            ref={(node) => {
              if (node) {
                messageRefs.current.set(message.id, node);
              } else {
                messageRefs.current.delete(message.id);
              }
            }}
            className={highlightedId === message.id ? "message highlighted" : "message"}
          >
            {message.text}
          </div>
        ))}
      </div>

      <form
        onSubmit={(e) => {
          e.preventDefault();
          handleSend();
        }}
        className="input-area"
      >
        <input
          autoFocus
          type="text"
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          placeholder="Type a message..."
        />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

export default App;

App.css

.app {
  max-width: 400px;
  margin: 0 auto;
  padding: 16px;
}

.jump-links {
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
}

.message-list {
  height: 300px;
  overflow-y: auto;
  border: 1px solid #ccc;
  padding: 8px;
}

.message {
  padding: 8px;
  margin-bottom: 8px;
  background: #f5f5f5;
  border-radius: 4px;
  transition: background-color 0.3s ease;
}

.message.highlighted {
  background: #fff3cd;
}

.input-area {
  display: flex;
  gap: 8px;
  margin-top: 16px;
}

.input-area input {
  flex: 1;
  padding: 8px;
}

Wrapping Up

This exercise demonstrates a common pattern in live coding challenges: balancing correctness with pragmatism. The shortcuts we took were deliberate, and we can articulate why we'd do things differently given more time. The key is knowing the difference between "good enough for a demo" and "production-ready" — and being able to explain both.

Previous: Part 1 — Understanding the Requirements and Basic Structure

Frontend Coding Challenge — Chat-Like Interface (Part 1)

Tiago — Tue, 03 Feb 2026 16:41:13 +0000

This is the first of two posts where I walk through a hypothetical frontend live coding challenge from the perspective of the interviewee, focusing on not just the code, but the reasoning that leads to it.

The Challenge

Build a chat-like interface with a scrollable message list, an input field, a send button, and two "jump to message" links.

Constraints

The only constraint is that we must use React.

Requirements

Display 9 hardcoded messages on load
User can type a message and click "Send" to append it to the list
Empty messages cannot be sent
The list scrolls to the bottom when a new message is added
Links above the list allow jumping to the first and last messages
Clicking a link scrolls that message into view and highlights it
The highlight disappears after 1 second
Only one message can be highlighted at a time

Nice-to-have

Auto-focus the input on page load
Send messages with Enter key

Going through the Requirements

Before writing any code, it's worth carefully reading each requirement and checking whether its implementation is obvious. Some of these have hidden implications.

"Display 9 hardcoded messages on load"

Straightforward. We need initial data, which can be simple strings or objects with IDs. Since we'll need to highlight specific messages later, giving each message a stable identifier makes sense.

"The list scrolls to the bottom when a new message is added"

This tells us something about the UI structure. For a container to scroll vertically, its computed height must be less than the height of its content, and it needs to have overflow-y: auto or overflow-y: scroll. If the container grew to fit its content, there would be nothing to scroll to. This means we're building a fixed-height scrollable area — a layout decision implied by this requirement.

"Links allow jumping to the first and last messages"

The jump links target the first and last messages in the list. We'll need a way to scroll a specific message into view, which means either storing refs or using DOM queries.

"The highlight disappears after 1 second"

This requires a timeout. Timeouts in React components need cleanup on unmount to avoid unnecessary work. We'll need useEffect with a cleanup function, or a ref to track and cancel the timeout.

"Only one message can be highlighted at a time"

If we click "Jump to Last" while the first message is still highlighted, the first message's highlight should disappear immediately. This means highlighted state should be tracked centrally (not per-message), and we should cancel any existing timeout when a new highlight starts.

Ambiguities

Some things are left to interpretation:

Message structure — Are messages just strings, or do they have metadata like timestamps or authors? The requirements don't specify. We'll use objects with id and text to keep things extensible without overcomplicating.

Styling specifics — No mockup is provided, so exact colors, spacing, and layout are open to interpretation.

Scroll behavior — Should scrolling be instant or smooth? Smooth scrolling provides visual continuity, helping the user track which message was jumped to. scrollIntoView supports this via { behavior: "smooth" }.

Mental Model

Before writing code, here's how the component tree and state will likely look:

<App>
  <JumpLinks />          // "Jump to First | Last"
  <MessageList>          // scrollable container
    <Message />          // repeated for each message
    <Message />
    ...
  </MessageList>
  <MessageInput />       // input + send button
</App>

State lives in App:

messages — array of message objects
highlightedId — which message is highlighted (or null)
inputValue — controlled input state

Environment Setup

We're free to use whatever we want. For a quick React setup, Vite requires minimal configuration and gives us a working React + TypeScript project with fast hot module replacement in seconds:

npm create vite@latest chat-interface -- --template react-ts

TypeScript is optional, but the autocompletion and type checking help catch errors early, and Vite's template requires no additional setup.

Architecture Decisions

With the requirements understood, the next step is deciding how to structure the code.

Component Structure

The mental model suggested extracting JumpLinks, MessageList, Message, and MessageInput as separate components. For a production codebase, this separation makes sense — each component has a single responsibility, and they're independently testable.

For a live coding exercise, there's a trade-off. More components means more boilerplate, more props to pass, and more opportunities for wiring mistakes. A pragmatic approach is to keep everything in a single App component initially, and extract components only if the file becomes unwieldy or if extraction simplifies the logic.

State Shape

We need to track three things:

const [messages, setMessages] = useState(initialMessages);
const [highlightedId, setHighlightedId] = useState<number | null>(null);
const [inputValue, setInputValue] = useState("");

messages — An array of message objects. Each message needs an id (for keying and highlighting) and text (the content). Starting with 9 hardcoded messages:

const initialMessages = Array.from({ length: 9 }, (_, i) => ({
  id: i,
  text: `Message ${i + 1}`,
}));

Using the array index as the ID is fine here. We're not reordering or deleting messages, so there's no risk of key collisions. When adding new messages, the next ID is simply the array length (i.e., the next available index).

highlightedId — The ID of the currently highlighted message, or null if none. Storing this centrally (rather than a highlighted boolean on each message) makes it trivial to ensure only one message is highlighted at a time. We could track this as "first" | "last" | null since those are our only jump targets, but using the actual message ID is no more complex and would scale naturally if requirements expanded to include additional jump targets.

inputValue — The controlled input value. This could be an uncontrolled input with a ref, but with a controlled input the value always reflects React state, making validation and transformation straightforward. The performance difference is negligible for a single text field.

The Layout Constraint

As noted earlier, the scroll requirement implies we need a fixed-height scrollable container. For simplicity, we can give the message list a fixed height directly:

.message-list {
  height: 300px;
  overflow-y: auto;
}

The rest of the layout — jump links above, input below — stacks naturally as block elements.

CSS Approach

Options for styling in React without external libraries:

Inline styles — JavaScript objects, no separate files
CSS file — Traditional stylesheet, imported into the component
CSS Modules — Scoped class names, supported by Vite out of the box

Vite's template includes an App.css file, so we'll use that. We can also delete index.css and remove its import from main.tsx — Vite's default styles may interfere with our layout, and starting with a blank slate is simpler than debugging style conflicts.

Initial Scaffold

We'll replace Vite's boilerplate with our scaffold:

import { useState } from "react";
import "./App.css";

const initialMessages = Array.from({ length: 9 }, (_, i) => ({
  id: i,
  text: `Message ${i + 1}`,
}));

function App() {
  const [messages, setMessages] = useState(initialMessages);
  const [highlightedId, setHighlightedId] = useState<number | null>(null);
  const [inputValue, setInputValue] = useState("");

  return (
    <div className="app">
      <div className="jump-links">
        <button>Jump to First</button>
        <button>Jump to Last</button>
      </div>

      <div className="message-list">
        {messages.map((message) => (
          <div key={message.id} className={highlightedId === message.id ? "message highlighted" : "message"}>
            {message.text}
          </div>
        ))}
      </div>

      <div className="input-area">
        <input
          type="text"
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          placeholder="Type a message..."
        />
        <button>Send</button>
      </div>
    </div>
  );
}

export default App;

And the corresponding CSS:

.app {
  max-width: 400px;
  margin: 0 auto;
  padding: 16px;
}

.jump-links {
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
}

.message-list {
  height: 300px;
  overflow-y: auto;
  border: 1px solid #ccc;
  padding: 8px;
}

.message {
  padding: 8px;
  margin-bottom: 8px;
  background: #f5f5f5;
  border-radius: 4px;
  transition: background-color 0.3s ease;
}

.message.highlighted {
  background: #fff3cd;
}

.input-area {
  display: flex;
  gap: 8px;
  margin-top: 16px;
}

.input-area input {
  flex: 1;
  padding: 8px;
}

This renders a functional layout with all the visual elements in place. Nothing is wired up yet — the buttons don't do anything, and the Send button doesn't add messages — but the structure is there, and we can verify the scroll container works by inspecting it in the browser.

Sending Messages

With the scaffold in place, we can start wiring up functionality.

The Send Handler

When the user clicks "Send", we need to:

Ignore empty input
Create a new message object
Append it to the messages array
Clear the input
Scroll to the bottom

const handleSend = () => {
  const trimmed = inputValue.trim();

  if (!trimmed) {
    return;
  }

  setMessages((prev) => [...prev, { id: prev.length, text: trimmed }]);
  setInputValue("");
};

The trim() call handles inputs that are only whitespace. Using prev.length for the ID works because IDs are 0-indexed (matching array indices) and we never delete messages — IDs will always be unique and sequential.

Note the functional update form setMessages((prev) => ...). This pattern derives the next state from the previous state, rather than from the messages variable captured in the closure. In this specific case it doesn't matter — user-initiated clicks can't race — but it's a good habit. If handleSend were called programmatically in quick succession, the closure-based version could produce duplicate IDs because each call would read the same stale messages value.

Auto-Scroll to Bottom

After adding a message, the list should scroll to show it. We also need refs to scroll specific messages into view for the jump links. A single data structure handles both: a Map storing refs to each message element by ID.

const messageRefs = useRef<Map<number, HTMLDivElement>>(new Map());

To populate the Map, we use callback refs. When you pass a function to ref instead of a ref object, React calls it with the DOM element when the element mounts and with null when it unmounts. With inline functions, React detects that the function identity changes on each render; when this happens, it calls the old callback with null, then the new callback with the element. This sounds problematic, but it's safe here because message.id is stable for each element — even if the old callback runs its delete logic, it deletes the correct key, and the new callback immediately re-adds it:

{
  messages.map((message) => (
    <div
      key={message.id}
      ref={(node) => {
        if (node) {
          messageRefs.current.set(message.id, node);
        } else {
          messageRefs.current.delete(message.id);
        }
      }}
      className={highlightedId === message.id ? "message highlighted" : "message"}
    >
      {message.text}
    </div>
  ));
}

Now we can scroll any message into view by its ID. For auto-scroll, we want to scroll to the last message whenever the list changes. Calling scrollIntoView right after setMessages won't work because React batches state updates and commits them to the DOM after the render cycle completes — the new message won't be in the DOM yet.

We need useEffect to run after the render:

useEffect(() => {
  const lastId = messages.length - 1;
  messageRefs.current.get(lastId)?.scrollIntoView({ behavior: "smooth" });
}, [messages]);

This runs whenever messages changes. Since IDs are 0-indexed and sequential, messages.length - 1 gives us the last message's ID.

One subtlety: this effect also runs on initial render with the 9 hardcoded messages. With behavior: "smooth", users see an animated scroll on page load. Whether that's desirable is a UX judgment call — some would prefer behavior: "instant" for the initial render, or skipping the scroll entirely. For a timed exercise, the current behavior is acceptable and doesn't contradict the requirements.

Simplifying with a Form

The nice-to-have list mentions auto-focusing the input and sending with Enter. There's a simple approach that addresses both: using a <form> element gives us Enter key submission for free, and the autoFocus attribute removes the need for a ref and effect:

<form
  onSubmit={(e) => {
    e.preventDefault();
    handleSend();
  }}
  className="input-area"
>
  <input
    autoFocus
    type="text"
    value={inputValue}
    onChange={(e) => setInputValue(e.target.value)}
    placeholder="Type a message..."
  />
  <button type="submit">Send</button>
</form>

This is also more semantic — we're submitting a form, not just clicking a button.

Current State

Here's the full component with sending and scrolling implemented:

import { useState, useRef, useEffect } from "react";
import "./App.css";

const initialMessages = Array.from({ length: 9 }, (_, i) => ({
  id: i,
  text: `Message ${i + 1}`,
}));

function App() {
  const [messages, setMessages] = useState(initialMessages);
  const [highlightedId, setHighlightedId] = useState<number | null>(null);
  const [inputValue, setInputValue] = useState("");

  const messageRefs = useRef<Map<number, HTMLDivElement>>(new Map());

  useEffect(() => {
    const lastId = messages.length - 1;
    messageRefs.current.get(lastId)?.scrollIntoView({ behavior: "smooth" });
  }, [messages]);

  const handleSend = () => {
    const trimmed = inputValue.trim();

    if (!trimmed) {
      return;
    }

    setMessages((prev) => [...prev, { id: prev.length, text: trimmed }]);
    setInputValue("");
  };

  return (
    <div className="app">
      <div className="jump-links">
        <button>Jump to First</button>
        <button>Jump to Last</button>
      </div>

      <div className="message-list">
        {messages.map((message) => (
          <div
            key={message.id}
            ref={(node) => {
              if (node) {
                messageRefs.current.set(message.id, node);
              } else {
                messageRefs.current.delete(message.id);
              }
            }}
            className={highlightedId === message.id ? "message highlighted" : "message"}
          >
            {message.text}
          </div>
        ))}
      </div>

      <form
        onSubmit={(e) => {
          e.preventDefault();
          handleSend();
        }}
        className="input-area"
      >
        <input
          autoFocus
          type="text"
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          placeholder="Type a message..."
        />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

export default App;

The jump links still don't work, and highlightedId isn't being set anywhere — but the messageRefs Map is ready to support them.

That's next.

Next: Part 2 — Jump, Highlight & Final Code

Why Does React Use a Virtual DOM?

Tiago — Mon, 26 Jan 2026 10:48:55 +0000

If you've spent any amount of time with React, you've probably heard of the Virtual DOM (or VDOM for short) as well as some version of this claim:

React uses a Virtual DOM because direct DOM manipulation is slow.

A catchy if hand-wavy explanation. Also a bit misleading.

The DOM isn't slow in the way people usually mean — JavaScript can execute DOM mutations very quickly. What's expensive is what the browser has to do after you mutate the DOM. React's Virtual DOM exists to manage those costs.

The DOM Is Not Just a JavaScript Object Tree

Although the DOM feels like a normal JavaScript object tree, it is not. DOM nodes are host objects, provided by the browser, implemented in native code (C++ in most browser engines).

When you change a DOM node, you're not just mutating memory owned by the JavaScript engine. You're interacting with the browser's rendering engine, which maintains a lot of additional state behind the scenes: layout information, CSS resolution, paint layers, accessibility data, and event handling metadata.

So when you do something as simple as:

element.textContent = "Hello";

you're signaling to the browser that the visual output of the page may have changed. That signal is where the real cost begins.

A DOM mutation can force the browser to do some or all of the following:

Recalculate styles
Recompute layout (reflow)
Repaint pixels
Re-composite layers on the GPU

These steps are typically far more expensive than the JavaScript that triggered them, and they can cascade: a change in one part of the DOM may affect layout elsewhere.

The browser is smart and uses heuristics to limit the scope of invalidation, but determining what's affected still requires work. The cost isn't the mutation itself — it's the invalidation and recalculation of rendering state.

Why Many Small DOM Updates Are a Problem

Browsers naturally batch rendering work: they wait until JavaScript execution completes before running the rendering pipeline. But "batched" doesn't mean "free" — the more mutations the browser has to process, the more rendering work it has to do.

Consider a naive approach to declarative UI: every time state changes, tear down a chunk of the DOM and rebuild it from scratch. The browser would recalculate styles, recompute layout, and repaint for an entire subtree, even if only a single text node actually changed. The mutations themselves are cheap, but the rendering work they trigger scales with the number of nodes affected.

The problem gets worse when DOM reads enter the picture. If you read a layout property (like offsetHeight) after modifying the DOM, the browser must calculate layout immediately to return an accurate value — it can't defer the work to the end of the task. This is called forced synchronous layout. Do this repeatedly — write, read, write, read — and the browser is forced to recalculate layout on every read, even though only the final state matters. This pattern is known as layout thrashing.

Experienced developers learned to work around both problems: reuse DOM nodes instead of replacing them, batch writes together, cache reads, and carefully order operations. It worked, but it was brittle and easy to get wrong.

React's Virtual DOM formalizes this discipline.

What the Virtual DOM Actually Is

React's Virtual DOM is a tree of plain JavaScript objects. It has no connection to layout, styles, or rendering. You can create it, throw it away, and compare it freely without triggering any browser rendering work. Only after it computes the final desired UI does it touch the real DOM.

This indirection allows React to do three important things:

Batch updates — Multiple state changes are grouped into a single DOM commit.
Avoid unnecessary writes — If a piece of UI didn't change, React doesn't touch the corresponding DOM node.
Minimize observable mutations — The browser sees only the smallest required set of changes, not every intermediate state.

In other words, the Virtual DOM reduces total work by shielding the browser from noise.

Why Diffing Is Usually Cheaper

All the Virtual DOM operations (creating trees, comparing them, throwing them away) are plain JavaScript work. The expensive part is what happens when changes reach the browser's rendering pipeline.

React trades extra JavaScript work for a reduction in browser rendering work. For most applications with non-trivial UI complexity, that trade is a net win.

This also explains why React can afford to re-run component functions so often. React distinguishes between the render phase (calling component functions to produce a Virtual DOM description) and the commit phase (applying changes to the real DOM). The expensive browser work only happens during the commit phase, once React knows exactly what needs to change.

The DOM is not "slow" in an absolute sense. Modern browsers are extremely fast, and for small or simple applications, direct DOM manipulation can be perfectly fine, or even faster than React.

The Virtual DOM shines when:

Updates are frequent
State changes are complex
You want predictable, maintainable UI updates at scale

React's real contribution isn't raw performance. It's making efficient DOM usage the default, instead of something developers have to constantly think about.

A more precise way to phrase the original claim would be:

React uses a Virtual DOM because committing only the necessary changes to the real DOM keeps expensive browser rendering work to a minimum.

The Virtual DOM exists to ensure the browser only sees the final, minimal set of changes that matter.

Beyond the Virtual DOM

The Virtual DOM was React's answer to a real problem, and it worked well enough to shape how a generation of developers thinks about UI. But it's not the only answer.

The core insight — that you need to minimize unnecessary DOM mutations — can be achieved through different mechanisms. While React builds a tree, diffs it, and patches the real DOM, other frameworks skip the intermediate tree entirely by tracking exactly which pieces of state affect which parts of the UI.

This alternative approach is often called fine-grained reactivity, and its most common implementation uses signals.

What Are Signals?

A signal is a reactive primitive: a container for a value that notifies subscribers when it changes. The key insight is that if the framework knows precisely which DOM nodes depend on which pieces of state, it can update only those nodes directly when state changes — without diffing an entire tree representation of the UI.

Consider a counter. In a signal-based system, when the count value changes, the framework doesn't re-run the entire component or diff a tree. It updates only the specific text node displaying the count, because it tracked that dependency when the UI was first created.

This inverts the React model. In React, a state change re-renders the component and its entire subtree by default, then diffs the result to find what changed. Signal-based frameworks track dependencies upfront and update only what's affected, without re-running component functions.

Tradeoffs

Neither approach is inherently superior. The Virtual DOM and fine-grained reactivity represent different points in a design space, optimizing for different concerns.

Virtual DOM diffing offers a simple mental model: describe what the UI should look like given the current state, and let the framework figure out the DOM updates. This makes reasoning about your application straightforward. The cost is the overhead of re-running component functions and comparing trees on every state change — work that happens even when the output is identical. For most applications this overhead is negligible, and React provides mechanisms to skip re-rendering subtrees when their inputs haven't changed.

Fine-grained reactivity avoids the overhead of diffing a full tree representation on every update. For simple value changes, updates go directly to the affected DOM nodes. List updates still require some form of reconciliation, but the work is scoped to the list itself rather than the entire component subtree. The tradeoff is a different mental model: instead of writing render functions that re-run on every state change, you're wiring up reactive primitives that persist and update in place.

Both approaches produce applications that are fast enough for the vast majority of use cases. The differences tend to matter at the margins — very large component trees, very frequent updates, or very constrained devices.

Choosing an Approach

The existence of VDOM-less frameworks doesn't invalidate React's approach. React's ecosystem, tooling, and community remain substantial advantages. The Virtual DOM model is well-understood, well-documented, and works well for a wide range of applications.

What these alternative approaches demonstrate is that the Virtual DOM is a solution, not the solution. Understanding that distinction — knowing why React chose its approach and what the alternatives optimize for — makes you a more informed developer, regardless of which framework you use.