Choosing WebSockets for Fittrack's Realtime Dashboard — Lessons from the Prompt API Debate

Last week I shipped a realtime dashboard for my open-source fitness app, Fittrack. It was the culmination of months of work on the feature/realtime-dashboard branch. But the decision to use WebSockets wasn't automatic — and it came with trade-offs I had to think through carefully.

Then I read about Mozilla's opposition to Chrome's Prompt API on Hacker News. The controversy isn't about the same tech, but the underlying principle is identical: when one vendor controls an API, developers lose.

The Real-Time Dashboard That Almost Wasn't

Fittrack lets users log workouts, track progress, and now view live metrics during exercise. For the realtime dashboard, I needed server-pushed updates — heart rate, reps, elapsed time — without the user refreshing the page.

I evaluated three options:

• Polling: Simple but wasteful. Every few seconds the client asks "anything new?" even when nothing changed.
• Server-Sent Events (SSE): Great for one-way updates, but I needed bidirectional communication (user can pause the workout from the dashboard).
• WebSocket: Full-duplex, standardized, and supported everywhere.

WebSocket won. The WebSocket API is a W3C standard, implemented in every modern browser. I didn't have to worry about Chrome dropping support or adding proprietary extensions.

How WebSockets Made It Simple

The server-side code, using the ws library in Node.js, is surprisingly lean:

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Client connected');

  ws.on('message', (message) => {
    const data = JSON.parse(message);
    // Handle commands like pause, resume
    if (data.type === 'pause') {
      // broadcast to all clients in this session
      wss.clients.forEach((client) => {
        if (client.readyState === WebSocket.OPEN) {
          client.send(JSON.stringify({ event: 'paused' }));
        }
      });
    }
  });

  ws.send(JSON.stringify({ event: 'connected', message: 'Live dashboard active' }));
});

On the client, I used the native WebSocket object:

const ws = new WebSocket('ws://localhost:8080');

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.event === 'heartRate') {
    updateHeartRate(data.value);
  }
};

No libraries, no polyfills. It just works.

The Prompt API Controversy

While I was polishing the dashboard, a Hacker News thread (actually the Mozilla story, but I'll link to the correct one) caught my eye: Mozilla's Opposition to Chrome's Prompt API.

Chrome proposed a new API that lets websites prompt users with AI-generated content — but only on Chrome. Mozilla opposed it, arguing it's not based on open standards and would fragment the web.

The parallels where striking. If I had built Fittrack's realtime feature around a Chrome-only API (like the now-deprecated navigator.share without fallback), users on Firefox or Safari would be locked out.

What Open Standards Mean for Builders

Open standards aren't just a philosophical nice-to-have. They are a practical necessity for any project that wants to reach a broad audience.

• Portability: My WebSocket code runs on any server (Node.js, Deno, even Python). The client works in every browser.
• Longevity: WebSockets have been around since 2011. They aren't going away.
• Community: When I hit a bug, I found answers on MDN, Stack Overflow, and in the ws library's issues — not a single-vendor forum.

Contrast that with a hypothetical Prompt API scenario: if Chrome decides to change the API or limit it to certain contexts, developers are stuck. They have to either fork a polyfill or migrate users to a different solution.

I learned this lesson the hard way years ago when I relied on navigator.mediaDevices.getUserMedia without checking for fallbacks. Now I always test for API support before shipping.

Takeaway

Building Fittrack's realtime dashboard with WebSockets was a deliberate choice rooted in standards. The Prompt API controversy reminded me that every time we pick a proprietary API, we risk excluding users and creating technical debt. Open standards are the foundation of a web that works for everyone — including my future self maintaining that code.