Challenge 2: Justify a Technology Choice — Possible Solution
====================================================================

SCENARIO: A multiplayer browser card game with in-game chat, rooms per
game table, and reconnection support for players on flaky Wi-Fi.

RECOMMENDATION: Socket.IO

JUSTIFICATION (using this chapter's comparison table)
------------------------------------------------------
- Interoperability: All clients are browsers running the game's own
  JavaScript front end — there's no requirement to talk to a non-JS
  client, a different language's WebSocket library, or any third-party
  service that "just uses raw WebSocket." Socket.IO's interoperability
  limitation (client and server both need to be Socket.IO) simply isn't
  a real cost here, since nothing outside this application needs to
  connect to it.

- Reconnection: This is explicitly called out in the scenario — "flaky
  Wi-Fi" players need to reconnect smoothly. Socket.IO's automatic
  reconnection with backoff is precisely the built-in feature this
  requirement calls for; building the equivalent by hand on raw ws would
  mean re-implementing a whole reconnection/backoff strategy that
  Socket.IO already provides for free.

- Rooms/namespaces: "Rooms per game table" maps directly onto Socket.IO's
  built-in room system (socket.join("table-7"), io.to("table-7").emit(...)).
  This is exactly the kind of bookkeeping Chapter 3 did by hand with a
  Set and manual filtering — here, needing MULTIPLE independent rooms
  (one per table, not just one global broadcast) makes the built-in room
  system considerably more valuable than in a single-room toy example.

- Message overhead: Socket.IO's slightly higher per-message overhead is a
  real cost, but for a turn-based or lightly-paced card game (as opposed
  to, say, a twitch-reaction competitive shooter needing every possible
  millisecond), it's not a meaningful drawback compared to the
  development time saved by not hand-rolling reconnection and rooms.

- Fallback transport: A bonus for this scenario specifically — some
  players may be on networks (corporate Wi-Fi, restrictive routers) where
  a raw WebSocket handshake occasionally fails; Socket.IO's automatic
  long-polling fallback keeps those players connected without any extra
  application code, where raw ws would simply fail to connect for them.

WHY THIS WORKS AS A DECISION
-----------------------------
None of raw ws's actual advantages (broader interoperability, lower
overhead, fewer dependencies) apply meaningfully to this scenario — there
is no non-browser client to support, and the overhead difference doesn't
matter for this kind of gameplay. Meanwhile, TWO of Socket.IO's specific
built-in features (reconnection, rooms) map almost one-to-one onto
requirements stated directly in the scenario. This is the core skill the
chapter is testing: not "which technology is generally better," but
"which one's actual trade-offs match this specific situation's actual
requirements."