Building a Real-Time Hardware Platform in the Browser with WebBluetooth and WebSerial

Introduction

Most enterprise hardware platforms still rely on native desktop applications, proprietary drivers, or manual data entry workflows. We wanted to simplify that experience entirely.

Our goal was straightforward:

  • Connect physical lab devices directly to the browser
  • Stream telemetry in real time
  • Eliminate manual calibration workflows
  • Avoid native desktop applications entirely

To achieve this, we built a browser-based platform using the WebBluetooth and WebSerial APIs.

The result was a system capable of streaming telemetry from physical calibration devices directly into a web application with minimal setup for the end user.

Why We Avoided Native Applications

Native applications create friction everywhere:

  • Installation and update complexity
  • Platform-specific bugs
  • Driver compatibility issues
  • Enterprise IT restrictions
  • Difficult deployment cycles

We wanted users to:

  1. Open the web application
  2. Connect their device
  3. Start streaming data immediately

Modern browser APIs made that possible.

High-Level Architecture

The platform architecture looked roughly like this:

The browser became the central integration layer between:

  • Physical lab devices
  • Internal APIs
  • Real-time telemetry pipelines
  • Enterprise workflows

Choosing Between WebBluetooth and WebSerial

Different devices exposed different communication interfaces.

WebBluetooth

WebBluetooth worked well for modern wireless instruments where portability mattered more than throughput.

However, we encountered several constraints:

  • Device discovery inconsistencies
  • Browser support differences
  • Connection instability on certain operating systems
  • Limited debugging visibility

WebSerial

WebSerial became the preferred option for high-frequency telemetry devices because of its reliability and throughput.

Most enterprise lab hardware still exposes serial interfaces internally, making WebSerial surprisingly practical.

Streaming Real-Time Telemetry

The devices continuously emitted structured telemetry payloads containing:

  • Sensor readings
  • Calibration metadata
  • Device state
  • Measurement status
  • Timing information

A simplified streaming loop looked like this:

async function streamTelemetry(port: SerialPort) {
  await port.open({ baudRate: 115200 });

  const reader = port.readable?.getReader();

  while (true) {
    const { value, done } = await reader!.read();

    if (done) break;

    const decoded = new TextDecoder().decode(value);

    handleTelemetry(decoded);
  }
}

The real challenge was not reading the data.

The difficult part was handling unreliable real-world hardware behavior.

Problems We Had to Solve

Device Disconnects

Devices disconnected constantly.

Sometimes because of:

  • Loose cables
  • USB power issues
  • Browser permission resets
  • Faulty firmware
  • OS-level serial interruptions

We built automatic reconnection flows and state recovery logic to make the experience resilient.

Large Telemetry Payloads

Some devices emitted large JSON payloads at high frequency.

This introduced problems like:

  • Browser memory pressure
  • Rendering bottlenecks
  • Backpressure handling
  • Event loop blocking

We eventually introduced:

  • Batched processing
  • Incremental parsing
  • Worker-thread offloading
  • Buffered transport queues

Real-Time UI Rendering

Rendering telemetry at device frequency caused the UI to become unusable.

Instead of rendering every incoming event, we implemented throttled rendering pipelines.

const updateUI = throttle((telemetry) => {
  renderTelemetry(telemetry);
}, 100);

This dramatically improved browser responsiveness.

Security Considerations

Direct hardware access inside the browser introduces unique security concerns.

We enforced:

  • Explicit user permission prompts
  • Device allowlists
  • Session-scoped access
  • Secure API transport
  • Audit logging for device interactions

One important advantage of browser-based permissions is that users maintain visibility into connected devices.

The browser sandbox also reduced several risks commonly seen in native integrations.

Lessons Learned

Browsers Are More Capable Than Most Teams Realize

Modern browsers can now handle workflows that traditionally required native applications.

For many enterprise scenarios, browser APIs are already “good enough.”

Hardware Is Unpredictable

The software stack was often more reliable than the physical devices themselves.

Designing for unstable hardware became more important than optimizing ideal-case performance.

Real-Time Systems Need Backpressure Handling

Without buffering and throttling, telemetry systems quickly overwhelm the frontend.

A stable streaming pipeline matters more than maximum throughput.

What I Would Improve Today

If rebuilding the system today, I would:

  • Move more processing into Web Workers
  • Introduce binary telemetry protocols where possible
  • Add better offline buffering
  • Improve observability around device failures
  • Build a dedicated telemetry replay system for debugging

Final Thoughts

WebBluetooth and WebSerial are still relatively underused in enterprise applications, but they unlock interesting possibilities for hardware-heavy workflows.

For us, they enabled a significantly simpler deployment model:

  • No installers
  • No native updates
  • No custom drivers
  • Faster onboarding
  • Reduced operational overhead

Most importantly, they allowed physical lab devices to behave like first-class web citizens.

That fundamentally changed how users interacted with the platform.