Architecture

Pulsar promotes architectural clarity through explicit composition and long-lived UI objects.

Rather than enforcing a formal pattern like MVC or MVVM, Pulsar provides a small set of primitives that naturally guide applications toward a domain-oriented architecture.

Core Architectural Ideas

• Components represent domains, not UI fragments
• State lives where behavior lives
• Composition is preferred over inheritance
• Explicit data flow over implicit reactivity

Domain-Oriented UI

In Pulsar, components are designed to model meaningful domains within the application, not just visual fragments.

A page, a layout, or even a reusable component should encapsulate its own state, behavior and rendering logic as a cohesive unit.

Explicit Data Flow

Data flows through constructor arguments, method calls and explicit state mutations.

There are no implicit subscriptions, hidden dependencies or auto-wired providers.

• State changes are triggered via morph
• Events are handled by explicit methods
• Cross-component communication is intentional

What Pulsar avoids

• Global implicit state by default
• Framework-managed dependency injection
• Hidden data propagation
• Over-abstraction in the name of reuse

Pulsar does not try to solve architecture for you. It gives you stable, predictable building blocks and lets architecture emerge from composition.