XtermOrchestrator was born from the chaos of MultiTerminals. After building a monolithic multi-terminal app, it became clear that the orchestration logic -- how terminals are laid out, created, destroyed, and coordinated -- deserved to be its own module.
This is a pure abstraction layer. It does not render terminals or manage windows. It decides where terminals go, when they are created, and how layout transitions happen. Think of it as a tiling window manager's brain, extracted into a reusable library.
Layout Management
Split views, grid layouts, focused mode, and tabbed arrangements. Switch between layouts while preserving terminal state.
Split Views
Horizontal and vertical splits with draggable dividers. Recursive splitting creates complex arrangements from simple primitives.
Session Persistence
Serialize and restore complete terminal arrangements. Close the browser, reopen, and pick up exactly where you left off.
Orchestrated Creation
Terminals are not spawned ad-hoc. The orchestrator decides placement, sizing, and lifecycle based on layout rules and policies.
- 01 Orchestration patterns are universally useful. The same split-tree algorithm that arranges terminals works for panels, editors, dashboards. Extracting it into a library was the right call -- the pattern transcends its original use case.
- 02 Layout algorithms are a rabbit hole. Binary split trees seem simple until you handle edge cases: minimum sizes, proportional resizing on container change, removing a node from a deep tree without collapsing siblings.
- 03 The abstraction layer is the product. MultiTerminals was 15 MB because it mixed orchestration with rendering. XtermOrchestrator is 120 KB because it only does one thing. This project proved that the clean abstraction boundary was where the real value lived.
- 04 Serialization reveals your architecture. If you cannot serialize and restore your state to JSON, your state management is tangled. Building session persistence forced every layout decision to be explicit and reproducible.