You build a chat prototype on a Saturday. The socket connects. Messages fly. You feel sharp.
Three months later a new project needs live updates and your brain offers nothing useful. Upgrade? Opcode? Ping/pong? You open three tabs and rewatch the same 40-minute tutorial you already finished twice. Same timestamps. Same "oh right" moments. Same blank stare when reconnect logic shows up.
I've done this enough times that I stopped blaming the tutorials. My review habit was the problem.
What sticks and what evaporates
After a few WebSocket projects, some pieces stay. You remember that the client talks over a long-lived TCP connection and that ws:// and wss:// matter the way http and https do. You remember that both sides can send whenever they want, which is why chat demos feel magic the first time.
The rest goes soft fast.
The handshake is the classic leak. You know "there's an upgrade" but can't write the request headers or the 101 Switching Protocols response without looking them up. Same with frames: text vs binary, the fact that control frames exist, why a close frame isn't just hanging up the TCP socket. Ping/pong feels obvious until you have to decide who pings, how often, and what you do when a pong never arrives.
Reconnect is worse. Tutorials show a happy path. Production code needs backoff, a queue for messages that fired while you were offline, and a rule for when to stop trying. Backpressure shows up the first time a client sends faster than the server can process, and you're reading about pause/resume instead of chat demos.
None of that is hard once you've seen it twice. The problem is you see it twice with six months of silence in between, so the second time still feels like the first.
A study loop that actually holds
Skip the "watch twelve videos" plan. Pick one solid walkthrough and one tiny build, then force yourself to retrieve the concepts on a schedule.
One tutorial. Choose a source that covers handshake, frames, ping/pong, and reconnect in one pass. MDN's WebSocket docs plus one long-form guide is enough. Don't collect a playlist. Collect one path you trust.
One small build. A two-client echo room is fine. Add three boring features on purpose: a heartbeat, reconnect with exponential backoff, and a note in the UI when the socket is offline. Those force the bits you always re-Google.
Then re-test yourself. Next day, close the tabs and write from memory: what does the client send in the upgrade request? What is opcode 0x1 vs 0x9? Who should send ping in your design, and why? Wrong answers help. They point you at five minutes of re-reading instead of the whole video.
A week later, quiz again without the notes. Ask for the reconnect sequence out loud. If you stall on "what happens to messages sent during the gap," reopen only that part. Spaced repetition beats a second binge-watch. Rewatching feels familiar; retrieval tells the truth.
Stop rewatching the same forty minutes
The loop falls apart when your notes are a browser history entry and a half-named file called ws-notes.md. You remember a good handshake diagram. Not which minute had it.
When something finally clicks, save the source and a short note in your own words. For a YouTube walkthrough, the save is the video; the note is three lines: "upgrade is a normal HTTP request with Connection: Upgrade and Upgrade: websocket," "ping is opcode 9, pong is 10," "reconnect: wait 1s, 2s, 4s, cap at 30s, flush outbound queue after open." For a blog post, highlight the frame layout section and add why you cared that day ("needed this for the heartbeat bug").
That note is what you re-read later. The video stays the receipt. You should not need to scrub to 17:40 again to recall what a close frame looks like.
If the material is a docs page, same idea: save the URL, keep a short takeaway, file it under a topic you'll actually search, like "websockets" or "realtime." When the next project starts, you pull the takeaways first. Only reopen the long source if a detail is still fuzzy.
Where I park the material now
I got tired of losing tutorial tabs. These days I save the video, docs page, or blog post into Recl. It's a memory app: save links, articles, YouTube, and notes; get an AI summary with a TL;DR and key takeaways; file things under library topics; then get spaced-repetition recall nudges and a weekly quiz on Sunday evening.
For WebSockets that means the MDN page and the one tutorial I trust land in the same library. The summary surfaces handshake and frame points so I can skim before a rebuild. I still add my own three-line note so the "why" stays in my words. Months later, when I half-remember ping/pong rules, I can ask the library and get an answer with sources instead of starting a fresh Google spiral.
There's a share sheet, and a Chrome extension (Ctrl/Cmd+Shift+S, plus right-click save for page, link, highlight, or image, and a YouTube button) when I'm already in the browser. Public shelves live at library.recl.app if you want to browse how others organize saves. Tagline that fits this habit: save what matters, recall it forever.
You don't need an app to learn WebSockets. A dated note and a calendar reminder beat another abandoned bookmark. The point is the habit: capture the bits that evaporate, then make yourself retrieve them before the next realtime feature lands on your desk.
Try this on your next realtime ticket
Before you open a new tutorial, write what you still remember about the handshake and reconnect. Save one good source. Build the tiny echo room with heartbeat and backoff. Quiz yourself tomorrow and again next week.
If the same opcodes feel brand new every quarter, treat the gap between learning and recall as the real bug. Close it on purpose, and the next WebSocket project starts at "reconnect queue" instead of "what was an upgrade again?"
Asutosh Pattanayak built Recl — a memory / second-brain app for saving links, articles, videos, and notes, then actually remembering them.
Top comments (0)