Skip to content

Why UI Is Just Another Workload

Jump to bottom
Adrian Burlacu edited this page Feb 6, 2026 · 5 revisions

Why UI Is Just Another Workload

Stark treats user interfaces as workloads for the same reason it treats services as workloads: they are fallible, stateful, and expensive.

One of Stark Orchestrator's unique capabilities is treating browser-based UI applications as managed workloads, just like server-side processes.

UI Is Not Special

Most systems treat UI as sacred.

Stark does not.

UI:

  • allocates resources
  • depends on services
  • can deadlock
  • can crash
  • can become outdated

These are not UI problems — they are workload problems.

So Stark schedules UI the same way it schedules everything else.

Stark OS currently operates UI packages in a trusted mode. All UI packs run with root capabilities. Capability scoping is planned but not enforced.

The Traditional View

Traditionally, frontends and backends are deployed completely differently:

Aspect Backend Frontend
Service Kubernetes, VMs CDN, Static hosting
Versioning Container tags Cache busting
Rollback Redeploy container Purge CDN cache
Monitoring APM tools RUM tools
Orchestration Sophisticated Non-existent

Stark's Unified View

Stark treats all JavaScript workloads uniformly:

                     ┌──────────────────┐
                     │  Pack Registry   │
                     │  (versioned)     │
                     └────────┬─────────┘
                              │
           ┌──────────────────┼──────────────────┐
           ▼                  ▼                  ▼
    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
    │ Node.js Pod │    │ Node.js Pod │    │ Browser Pod │
    │ (API)       │    │ (Worker)    │    │ (UI)        │
    └─────────────┘    └─────────────┘    └─────────────┘

Both server and browser workloads:

  • Are bundled as packs
  • Have semantic versions
  • Can be deployed via CLI
  • Support instant rollback
  • Report status to the orchestrator

Browser Nodes

A browser becomes a node when it:

  1. Loads the browser runtime adapter
  2. Connects to the orchestrator via WebSocket
  3. Registers its capabilities

The browser node then receives pod assignments just like a Node.js node.

Interfaces Are Capabilities

A UI pack does not automatically get control.

Instead, it requests capabilities:

  • visibility into system state
  • the ability to render views
  • permission to trigger actions

The orchestrator decides what is allowed.

This enables:

  • multiple frontends
  • restricted operator views
  • automated or AI-driven interfaces
  • future interaction models (CLI, TUI, voice, etc.)

Rendering Is an Implementation Detail

UI packs describe what they want to present.

The client decides how it is rendered.

This separation allows:

  • different renderers
  • accessibility-first interfaces
  • remote or embedded shells
  • evolution without breaking packs

The UI is not the system.

It is a view into it.

Benefits of Unified Orchestration

1. Consistent Service Model

# Deploy backend
stark pod create --pack api-service --node server-1

# Deploy frontend (same command pattern!)
stark pod create --pack web-ui --node browser-cluster

2. Coordinated Rollouts

Roll out a new version across frontend and backend simultaneously, or in sequence with dependencies.

3. Unified Versioning

Track which UI version is running alongside which API version. Debug issues with precise version knowledge.

4. Browser as Compute

Browsers aren't just rendering clients—they're compute nodes that can:

  • Process data locally
  • Run offline-capable logic
  • Participate in distributed computation

Bundling UI Packs

For web apps to work as self-contained packs:

Requirement Description
Static output Generate static HTML/JS/CSS (no SSR)
No code-splitting Disable dynamic imports
Inline assets Assets as base64 data URIs

Nuxt configuration example:

export default defineNuxtConfig({
  ssr: false,
  nitro: { preset: 'static' },
  vite: {
    build: {
      assetsInlineLimit: 100 * 1024, // 100KB
      rollupOptions: {
        output: {
          inlineDynamicImports: true,
          manualChunks: undefined,
        },
      },
    },
  },
})

See examples/nuxt-pack for a complete example.

Use Cases

Multi-Tenant Dashboards

Deploy different dashboard versions to different customers' browsers.

A/B Testing at Scale

Route percentages of users to different UI pack versions.

Offline-First Applications

Deploy packs that work entirely in the browser, even without network.

Edge Computing

Use browser nodes for distributed computing at the edge.

Failure Is Normal

When a UI pack fails:

  • the system keeps running
  • state is preserved
  • the UI can be restarted
  • another UI can take over

This is not a bug.

It is the design.

The Outcome

By treating UI as a workload:

  • interaction becomes composable
  • management becomes distributable
  • the system becomes explainable while running

Stark does not ask:

"How do we build a dashboard?"

Stark asks:

"How do we make the system observable and interactive by default?"

TODO: Expand Browser Runtime Documentation

Related Topics

Clone this wiki locally