Get-it-all-at-once vs watch-it-arrive. Same speed underneath — wildly different feel.
01 · the scene
"It works. So why does it feel broken?"
The my-day coach chat replied correctly every time. But the user typed, then stared at a frozen screen for several seconds, then the whole answer appeared at once. Nothing was wrong — and it felt like the app had hung.
my-day — coach chat — first version
user: "help me plan my morning" [ ...8 seconds of nothing... ] coach: "Sure — let's start with..." ← whole answer, all at once // correct answer. feels like it froze.
Neill51% · the terrain
"The reply was right, so I thought we were done. But as a user it felt dead — eight seconds of a frozen screen reads as 'broken,' even when it's working perfectly."
Claude49% · the execution
"That's a delivery choice, not a quality bug. We were waiting for the whole answer, then showing it. Stream it word-by-word instead and the exact same response feels instant. I should've reached for streaming from the start for chat."
02 · the why
Two ways to deliver the same answer.
A normal REST call sends a request and waits for one complete response — you get nothing until everything's ready. Streaming (Server-Sent Events, SSE) keeps the connection open and pushes the answer in pieces as they're generated — which is how a chatbot's reply appears word by word. Here's the key: the actual speed is identical. The perceived speed isn't. For AI chat, waiting 8 seconds for a full answer feels broken; streaming the same answer feels alive.
▣
REST
all at once
Ask, wait, receive the whole thing. Great when you need the complete result before you can do anything — a saved record, a file.
▶
Streaming / SSE
piece by piece
The connection stays open and the answer arrives as it's made. The user sees motion immediately.
◔
Perceived speed
the real lever
Same total time. Words appearing now feels instant; a frozen wait for the same words feels dead.
The model: REST is a sealed package delivered to your door — you wait, then it's all there. Streaming is someone reading you the letter as they write it — you're engaged the whole time even though the letter takes just as long to finish. Knowing the difference tells you which UX to ask for: stream anything a human waits on and reads (chat); use plain REST when you need the whole result before acting (save, fetch a file).
03 · predict it
The chat answer is correct but feels frozen for 8 seconds. The fix?
Same model, same answer, same total time. The problem is purely how it feels. What do you change?
Not it. A pricier model or a spinner doesn't fix the core feel, and shortening answers degrades the product. The lever here is delivery, not speed or length.
Exactly. The problem isn't speed — it's that the user stares at nothing until the whole answer lands. Streaming shows the answer arriving word by word: identical total time, but it feels alive. That's why chatbots type at you.
04 · the walkthrough
From frozen to flowing, in four frames.
REST: request → long wait
step 1Plain REST asks and waits. For a long answer, the user sees a frozen screen until it's all done.
switch to a stream
step 2Ask for a streaming response (SSE). The connection stays open instead of returning one final blob.
tokens arrive in pieces
step 3The answer is pushed piece by piece as it's generated — the UI appends each chunk as it lands.
words appear live
step 4Same total time, but the user sees it typing immediately. Feels instant. Use plain REST only when you need the whole result first.
05 · prove it · gate
Teach it back to unlock the payoff.
Same rule as always: answer it right, or the module isn't done.
Streaming and REST take the same total time. So why stream a chatbot's reply?
// one correct answer unlocks Module 13
Not the load-bearing reason. The total time doesn't change — that's the whole point. Think about what the user experiences while they wait.
That's it. Same speed, different feel. Streaming trades "stare at nothing, then everything" for "watch it arrive" — and perceived speed is what the user actually judges. Use REST when you need the complete result before acting; stream anything a person waits on and reads. Module unlocked. ↓
the durable idea
Same answer, same total time — delivery decides the feel. Stream what a human waits on and reads; use plain REST when you need the whole result before you can act on it.
06 · factory payoff
⊘ locked — pass the teach-back to claim this piece of the factory
The streaming reader that makes chat feel alive.
A real client-side snippet that consumes a streaming (SSE) response and appends each chunk to the screen as it arrives — the exact pattern behind my-day's coach chat — alongside the plain-REST version so you can see the one difference that flips "frozen" to "typing." Plus a one-line rule for when to use which.