KOS vs Traditional Web Applications – A Conceptual Overview

KOS UI applications represent a fundamentally different approach to web application development, designed specifically for real-time device control and monitoring in embedded IoT environments. This guide explores the key conceptual differences between KOS applications and traditional web applications.

The Core Philosophical Difference

Traditional Web Applications

Traditional web applications are primarily document-centric and request-response oriented. They follow patterns established for content delivery and user interaction in a client-server model where:

  • State lives in multiple places: Browser state, server state, database state
  • Communication is initiated by the client: User actions trigger requests
  • Updates are manual: User must refresh or trigger actions to see changes
  • Data flows in one direction: Client requests → Server responds

KOS Applications

KOS applications are event-driven and device-centric. They create digital twins of physical hardware where:

  • State is centralized: Backend is the single source of truth
  • Communication is bi-directional: Device state changes push to UI automatically
  • Updates are real-time: UI automatically reflects physical device changes
  • Data flows continuously: Physical Device ↔ Backend ↔ UI Model ↔ React Components

Key Conceptual Differences

1. Source of Truth Philosophy

Traditional Web Apps:

  • Multiple sources of truth (client state, server cache, database)
  • Data consistency challenges between client and server
  • Manual synchronization through API calls

KOS Applications:

  • Single source of truth: the physical device state managed by backend
  • Browser is purely a visualization layer
  • Automatic synchronization through event streams

2. State Management Approach

Traditional Web Apps:

  • Component-level state (useState, useReducer)
  • Application-level state (Redux, Zustand, Context)
  • Manual state synchronization across components

KOS Applications:

  • Model-centric state that mirrors device capabilities
  • Reactive properties that automatically update UI
  • Event-driven state changes from device interactions

3. Communication Patterns

Traditional Web Apps:

  • RESTful APIs with request-response cycles
  • Manual polling for updates
  • Optimistic UI updates with rollback

KOS Applications:

  • WebSocket topic subscriptions for real-time updates
  • Event-driven communication reflecting device state changes
  • UI automatically reflects actual device state (no optimistic updates)

4. User Interaction Model

Traditional Web Apps:

  • User interactions directly modify application state
  • Form submissions and button clicks drive data changes
  • Immediate feedback through client-side state updates

KOS Applications:

  • User interactions send commands to physical devices
  • Async operations with progress tracking through Futures
  • Feedback comes from actual device state changes, not assumptions

The Mental Model Shift

From Web Pages to Device Interfaces

Traditional web development thinks in terms of pages, forms, and user workflows. KOS development thinks in terms of device capabilities, physical constraints, and operational state.

Instead of asking “What does the user want to do?”, KOS developers ask “What can this device do?” and “What is its current state?”

From Client-Server to Device-Twin

Traditional apps manage the gap between client and server state. KOS apps manage the gap between physical reality and digital representation.

The UI becomes a window into the device’s actual state and capabilities, rather than a separate application that happens to interact with a backend.

From Request-Response to Event-Stream

Traditional web apps use a “pull” model – the client requests data when needed. KOS apps use a “push” model – device state changes are automatically delivered to the UI.

This eliminates the class of bugs related to stale data and reduces the need for complex cache invalidation strategies.

The Result: Different Types of Applications

Traditional Web Apps Excel At:

  • Content management and presentation
  • User-driven workflows and data entry
  • Complex business logic and data relationships
  • Multi-user collaboration

KOS Apps Excel At:

  • Real-time device monitoring and control
  • Industrial automation interfaces
  • IoT device management
  • Reactive dashboards that mirror physical state

The KOS Model Layer: Not Just for UI

Models as Independent Layer

A crucial distinction in KOS architecture: KOS models are not UI artifacts. They form a separate, independent layer that:

  • Runs in the browser but exists independently of any UI framework
  • Represents device state regardless of how (or if) it’s visualized
  • Can be consumed by different presentation layers (React, Vue, vanilla JS, or no UI at all)
  • Provides a consistent API for accessing device capabilities

Backend Developer Friendly

KOS models use TypeScript with decorators specifically to appeal to backend developers who:

  • Write the backend services that KOS models communicate with
  • Understand device capabilities better than frontend developers
  • Are comfortable with Java-like patterns (decorators, dependency injection, lifecycle methods)
  • Can model device behavior without needing UI expertise

Example: Backend Developer Creates Model

const PROP_DEVICE_ID = createPropKey<TemperatureControllerModel>("deviceId");
@kosModel({ modelTypeId: "temperature-controller", singleton: false })
export class TemperatureControllerModel {
  deviceId!: string; // The specific device this model controls
  @kosTopicHandler({
    topic: `/device/temperature/${PROP_DEVICE_ID}/reading`,
  })
  handleTemperatureUpdate(reading: TemperatureReading): void {
    // Backend dev understands device protocol
    this.currentTemperature = reading.celsius;
    this.validateOperatingRange();
  }
  @kosFuture
  setTargetTemperature(target: number): Future<void> {
    // Backend dev knows the device API
    return this.sendCommand("/device/temperature/set-target", { target });
  }
}

Frontend Developer Consumes Model

function TemperatureDisplay() {
  const tempController = useKosModel(TemperatureControllerModel, "zone-1");
  // Frontend dev just uses the model's API
  return (
    <div>
      <span>Current: {tempController.currentTemperature}°C</span>
      <button onClick={() => tempController.setTargetTemperature(22)}>
        Set to 22°C
      </button>
    </div>
  );
}

Models Can Exist Without UI

KOS models can run independently for:

  • Background device monitoring (no UI needed)
  • Device automation (models coordinate devices directly)
  • Data collection (models aggregate device data)
  • System integration (models expose device APIs to other systems)

Still Using React, But Differently

When you do use React with KOS, the relationship changes:

Traditional React:

  • Components manage their own state
  • Effects handle side effects and data fetching
  • Props and context pass data between components

KOS + React:

  • Models (created by backend devs) manage device state
  • React hooks connect to models, not manage state
  • Components (created by frontend devs) focus purely on presentation
  • Effects in models handle device-related side effects

The React layer becomes thinner and more focused on visualization, while the KOS model layer handles the complex logic of device interaction and state management.

Next Steps

This overview establishes the foundational differences. The following guides explore specific aspects:

  • Model-First Architecture: How KOS structures applications around device capabilities
  • Event-Driven Communication: Real-time patterns for device state synchronization
  • State Management Philosophy: Centralized truth vs distributed state
  • React Integration: How React components connect to KOS models
  • Separation of Concerns: Clean boundaries between device logic and presentation

Understanding these concepts helps developers make the mental shift from traditional web development patterns to the KOS approach of creating digital twins of physical devices.