Skip to content

Why it Exists

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

Why This Exists — The Stark Manifesto

Stark exists because orchestration stopped at the backend, and operating systems stopped at the device.

Modern systems are split in an unnatural way:

  • Backends orchestrate compute, but treat UI as an afterthought
  • Operating systems manage UI, but have no concept of distributed workloads
  • Dashboards observe systems, but do not participate in them

Stark rejects that split.

Stark is built on the idea that orchestration is the kernel, not an add-on — and that UI is a workload, not a privileged snowflake.

This document explains the motivations and problems that Stark Orchestrator was designed to solve.

The Core Idea

In Stark:

  • Everything runs as a pack
  • Packs are scheduled, restarted, and observed uniformly
  • UI, monitoring, management, and compute are peers
  • Failure is expected, isolated, and recoverable
  • State is observable, not hidden behind abstractions

There is no "control plane UI" bolted on top of the system.
There is no special process that is allowed to never fail.

If something deserves to exist, it should be schedulable.
If something can fail, it should be restartable.
If something is important, it should be observable.

The Problem

Modern JavaScript applications face several challenges:

1. Fragmented Service Stories

Deploying the same logic to multiple environments requires different toolchains:

  • Docker/Kubernetes for servers
  • CDN + bundlers for browsers
  • Different CI/CD pipelines for each

Stark unifies this with isomorphic packs that deploy anywhere.

2. No Browser-Native Orchestration

While Kubernetes excels at server orchestration, there's no equivalent for browser-based workloads. Browsers are treated as dumb clients, not managed compute resources.

Stark treats browsers as first-class nodes in your cluster.

3. Operational Complexity

Setting up Kubernetes for simple JavaScript workloads is overkill. You need:

  • Container registries
  • YAML manifests
  • Ingress controllers
  • Service meshes

Stark provides Kubernetes-like power with JavaScript-native simplicity.

4. Version Management Hell

Rolling back a service often requires:

  • Rebuilding containers
  • Updating manifests
  • Redeploying through CI/CD

Stark enables instant rollbacks because all versions are already stored.

The Vision

Stark Orchestrator envisions a world where:

  1. Code is code - JavaScript/TypeScript bundles are first-class deployables
  2. Browsers are nodes - Client devices participate in your compute fabric
  3. Operations are simple - One CLI, one API, one mental model
  4. Reactivity is built-in - State changes propagate automatically

Core Design Decisions

Why Supabase?

Supabase provides:

  • PostgreSQL with Row Level Security (RLS)
  • Built-in authentication
  • Real-time subscriptions
  • Easy local development

This gives Stark a robust foundation without reinventing databases and auth.

Why Vue Reactivity?

Vue's @vue/reactivity package provides:

  • Fine-grained reactivity primitives
  • Works in Node.js and browsers
  • No virtual DOM overhead
  • Composable and lightweight

This enables reactive state management across the entire system.

Why WebSockets?

WebSocket connections provide:

  • Bi-directional communication
  • Low latency for real-time updates
  • Persistent connections for nodes
  • Push-based pod assignments

What Stark Is NOT

  • Not a replacement for Kubernetes - Use K8s for container orchestration
  • Not a serverless platform - Pods run on persistent nodes
  • Not a build system - Use Vite/Rollup for bundling (we integrate with them)

Stark is not trying to replace traditional operating systems.
Stark is not Kubernetes in JavaScript.
Stark is not a UI framework with a backend bolted on.

Those systems solve adjacent problems.

Stark exists because no existing system treats orchestration, execution, and interaction as the same problem.

So Stark does.

What Stark Is Exploring

Stark exists to explore a different axis of system design:

  • Operating environments that are distributed by default
  • Interfaces that are composable services
  • Systems that can explain themselves while they are running

This is not about adding more dashboards.
This is about removing the distinction between the system and how you interact with it.

In One Sentence

Stark treats orchestration as an operating system primitive and user interfaces as first-class workloads.

TODO: Expand This Section

Learn More

Clone this wiki locally