Server Sent Events（SSE）实用场景及相较于setInterval+Ajax的优势问询

Great question! I get where you're coming from—when you first dive into SSE, it's easy to box it into just "high-frequency data updates" but it’s actually a great fit for a bunch of other scenarios where server-initiated communication makes more sense than constant client polling. Let’s break down the key use cases:

• Event-driven real-time updates (no wasted polling)
  Your comment example is perfect here. Instead of having the server periodically query the database (which wastes resources when there are no new comments), SSE lets the server push updates the moment a new comment is saved. Users see new content instantly, and you eliminate all those unnecessary database checks and empty Ajax responses that come with setInterval(). It’s "push" instead of "beg"—way more efficient.

• Low-bandwidth or resource-constrained environments
  Every setInterval() + Ajax combo involves opening a new HTTP connection (complete with handshake, headers, and connection teardown) for every request. SSE uses a single persistent HTTP connection, so after the initial handshake, only the actual data is sent back and forth. This cuts down on bandwidth usage drastically, which is a huge win for mobile users or anyone on a slow network.

• Simpler code for persistent subscriptions
  Managing setInterval() gets messy fast: you have to handle failed requests, avoid overlapping pending requests, and manually implement retry logic. SSE does all this out of the box—if the connection drops, it automatically tries to reconnect. Your code stays clean and focused on handling updates, not connection management. Here’s a quick example:

  const commentStream = new EventSource('/live-comments');
  commentStream.onmessage = (e) => {
    const newComment = JSON.parse(e.data);
    // Add the comment to your page
  };
  

  Compare that to writing all the retry, debounce, and error-handling logic for an Ajax-based polling system—night and day.

• One-way server-to-client communication
  If you don’t need two-way communication (like chat apps do), SSE is lighter than WebSocket. Use cases like news alerts, system notifications, real-time analytics dashboards, or stock price updates only need the server to send data to clients. SSE handles this with minimal overhead, no need to deal with WebSocket’s more complex framing and handshake process.

• Ordered, sequential updates
  SSE guarantees that messages arrive in the order the server sends them, since it’s built on a single persistent connection. With setInterval() + Ajax, network delays can cause requests to finish out of order, forcing you to add extra logic to sort updates. This is critical for things like real-time log streaming or step-by-step process updates where sequence matters.

To sum it up: SSE shines whenever you need the server to initiate updates, rather than the client repeatedly asking for data. It’s not just about "updating multiple times per second"—it’s about efficient, event-driven communication that’s easier to maintain and kinder to your server and users’ bandwidth.

内容的提问来源于stack exchange，提问作者DonJoe