WebSocket Alternatives: SSE, WebTransport, and MQTT Compared

Beyond WebSockets

WebSockets have been the default choice for real-time web communication since 2011. But in 2025, we have better options for many use cases. The key insight is that most "real-time" features are actually server-to-client push, not bidirectional communication.

Server-Sent Events (SSE): The Underrated Champion

SSE is an HTTP-based protocol for server-to-client streaming. It uses a regular HTTP connection, supports automatic reconnection, and works through proxies and firewalls without any special configuration.

// Node.js SSE server
import express from 'express';
const app = express();

app.get('/api/events', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
  });

  // Send heartbeat every 30s to keep connection alive
  const heartbeat = setInterval(() => {
    res.write(':heartbeat\n\n');
  }, 30000);

  // Send events
  const sendEvent = (event, data: object) => {
    res.write('event: ' + event + '\n');
    res.write('data: ' + JSON.stringify(data) + '\n\n');
  };

  // Example: stream deployment progress
  sendEvent('deploy-start', { service: 'api', version: 'v2.1' });
  sendEvent('deploy-progress', { step: 'building', percent: 30 });
  sendEvent('deploy-progress', { step: 'pushing', percent: 60 });
  sendEvent('deploy-complete', { status: 'success', url: 'https://api.example.com' });

  req.on('close', () => {
    clearInterval(heartbeat);
  });
});

// Browser client
const events = new EventSource('/api/events');

events.addEventListener('deploy-progress', (e) => {
  const data = JSON.parse(e.data);
  updateProgressBar(data.percent);
});

events.addEventListener('deploy-complete', (e) => {
  const data = JSON.parse(e.data);
  showNotification('Deployment complete: ' + data.status);
});

// Automatic reconnection is built-in
events. => {
  console.log('Connection lost, reconnecting automatically...');
};

SSE advantages over WebSockets:

• Uses standard HTTP (works with all proxies, CDNs, and load balancers)
• Automatic reconnection with last-event-ID
• Simpler server implementation (no upgrade handshake)
• Works with HTTP/2 multiplexing
• EventSource API is simpler than WebSocket API

SSE limitations:

• Server-to-client only (no client-to-server messages)
• Text-based only (no binary data)
• Limited to ~6 connections per domain in HTTP/1.1 (not an issue with HTTP/2)

WebTransport: The Next Generation

WebTransport is a new protocol built on HTTP/3 (QUIC) that provides reliable and unreliable, ordered and unordered, bidirectional communication. It is the future replacement for WebSockets.

// WebTransport client
const transport = new WebTransport('https://example.com:4433/game');

await transport.ready;

// Reliable bidirectional stream (like WebSocket)
const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
const reader = stream.readable.getReader();

await writer.write(new TextEncoder().encode('player-move:x=10,y=20'));

const { value } = await reader.read();
console.log(new TextDecoder().decode(value));

// Unreliable datagrams (like UDP, for real-time games)
const dgWriter = transport.datagrams.writable.getWriter();
await dgWriter.write(new Uint8Array([0x01, 0x02, 0x03]));

// Read incoming datagrams
const dgReader = transport.datagrams.readable.getReader();
while (true) {
  const { value, done } = await dgReader.read();
  if (done) break;
  handleGameState(value);
}

WebTransport advantages:

• Multiplexed streams (multiple independent streams, no head-of-line blocking)
• Unreliable datagrams (perfect for games, video, real-time sensor data)
• Built on QUIC (faster connection establishment, better mobile performance)
• No head-of-line blocking (unlike WebSocket over TCP)

WebTransport limitations:

• Requires HTTP/3 server support
• Browser support is still growing (Chrome and Edge, Firefox partial)
• Server libraries are less mature
• More complex API than WebSocket or SSE

MQTT: The IoT Standard

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol designed for constrained networks and IoT devices.

# Python MQTT publisher
import paho.mqtt.client as mqtt
import json

client = mqtt.Client(client_id="sensor-001", protocol=mqtt.MQTTv5)
client.tls_set()
client.username_pw_set("device", "secret")
client.connect("mqtt.techsaas.cloud", 8883)

# Publish sensor data
while True:
    payload = json.dumps({
        "temperature": read_sensor(),
        "humidity": read_humidity(),
        "timestamp": time.time(),
    })
    client.publish(
        "sensors/building-a/floor-2/room-201",
        payload,
        qos=1,  # At least once delivery
        retain=True,  # New subscribers get last value
    )
    time.sleep(10)

// JavaScript MQTT subscriber (Node.js or browser via WebSocket)
import mqtt from 'mqtt';

const client = mqtt.connect('wss://mqtt.techsaas.cloud:8884');

client.on('connect', () => {
  // Subscribe with wildcard
  client.subscribe('sensors/building-a/#', { qos: 1 });
});

client.on('message', (topic, message) => {
  const data = JSON.parse(message.toString());
  console.log('Topic: ' + topic + ', Temp: ' + data.temperature);
});

MQTT advantages:

• Tiny overhead (2-byte minimum header)
• Quality of Service levels (0: fire-and-forget, 1: at-least-once, 2: exactly-once)
• Retained messages (new subscribers get the last value immediately)
• Last Will and Testament (detect disconnected devices)
• Wildcard subscriptions (sensors/+/temperature, sensors/#)

Comparison Table

Decision Framework

Is communication server-to-client only?
├── Yes → SSE (simplest, most reliable)
└── No → Is latency critical (sub-10ms)?
    ├── Yes → Is unreliable delivery OK?
    │   ├── Yes → WebTransport datagrams
    │   └── No → WebTransport streams or WebSocket
    └── No → Is it IoT / many devices?
        ├── Yes → MQTT
        └── No → WebSocket (most compatible)

Real-World Architecture Example

At TechSaaS, our monitoring stack uses SSE for the dashboard:

Containers → Promtail → Loki → Grafana SSE → Browser Dashboard
Uptime Kuma → SSE stream → Status Page
CI/CD Runner → SSE events → Deployment Progress UI

For most web applications, SSE handles 80% of real-time needs without the complexity of WebSockets. Use WebSockets when you truly need bidirectional communication (collaborative editing, chat). Save WebTransport for when you need unreliable datagrams (games, live video). Use MQTT when you have constrained devices publishing sensor data.