Info

Why "Nebula"

NebulaKit is designed around authored composition rather than generated structure. Instead of hiding application architecture behind high-level abstractions, it encourages developers to build interfaces directly from a small set of predictable primitives and orchestration components. The goal is not to minimize JSX at all costs, but rather produce application code that remains understandable, compositional and resistant to entropy as projects grow.

Authored NebulaKit applications tend to share several structural characteristics:

Composition remains visible

NebulaKit favors explicit composition over hidden orchestration. Layout, grouping and structure are usually authored directly through primitives such as Box, Flex, Grid and Text. Components are intentionally built on top of one another using the same vocabulary exposed publicly to the user.

Authored layout typically stays visible

<Flex flexDirection="column" rowGap="sm">  <Section heading="Account">    <Form>      ...    </Form>  </Section></Flex>

Rather than replacing layout concepts with semantic aliases everywhere, NebulaKit preserves the underlying mental model of the web platform. This keeps authored UI predictable and easier to reason about over time.

Abstractions compress behavior, not structure

NebulaKit intentionally avoids introducing abstractions purely to reduce repeated JSX. Repeated layout or repeated visual structure alone is usually not enough reason to create a new component. Higher-order abstractions are expected to emerge primarily from repeated behavioral orchestration.

For example:

  • toggling password visibility

  • coordinating overlay behavior

  • handling accessibility mechanics

  • synchronizing async interaction state

are strong candidates for reusable abstractions.

Meanwhile small presentation-specific patterns are usually expected to remain local to the application itself. This keeps the framework smaller while allowing applications to evolve their own domain language naturally.

Applications own orchestration

NebulaKit components typically own rendering mechanics and accessibility behavior, while applications remain responsible for workflow orchestration.

For example:

  • Dialog manages focus, layering and dismissal behavior

  • Select manages dropdown interaction and keyboard navigation

  • Button manages interaction states and visuals

But applications still explicitly control:

  • navigation flow

  • async actions

  • overlay coordination

  • routing decisions

  • business workflows

This separation keeps application behavior visible instead of hiding it behind framework-specific APIs.

Responsive behavior stays explicit

Responsive behavior is authored directly through responsive props instead of separate CSS files or generated utility classes.

Typical authored responsive code

<Grid  gridTemplateColumns={{    base: '1fr',    md: 'repeat(2, 1fr)',    xl: 'repeat(4, 1fr)',  }}  gap="sm"/>

NebulaKit intentionally preserves familiar layout concepts such as flexbox, grid, spacing and sizing instead of replacing them with framework-specific DSLs. Developers are still expected to understand the underlying concepts of the platform itself. NebulaKit reduces implementation friction, not platform literacy.

Local abstractions are encouraged

NebulaKit encourages applications to create their own lightweight local abstractions when repeated patterns become stable within a project. Small application-specific wrappers are preferred over framework-level expansion when the abstraction:

  • belongs to a single product area

  • represents domain semantics

  • does not introduce reusable behavioral infrastructure

This helps prevent abstraction creep inside the framework itself while keeping authored application code clean and maintainable.

NebulaKit favors long-lived product interfaces

NebulaKit is strongest when building structured application interfaces such as:

  • dashboards

  • admin panels

  • settings pages

  • onboarding flows

  • CRUD interfaces

  • authenticated application shells

  • documentation systems

  • internal tools

The system prioritizes:

  • explicit structure

  • compositional clarity

  • responsive predictability

  • architectural consistency

  • resistance to entropy

over ultra-short syntax or highly abstracted visual DSLs.

As applications grow, the authored code is expected to remain readable, editable and structurally obvious rather than increasingly magical or framework-driven.

The resulting codebase

Most NebulaKit applications naturally converge toward:

  • visible composition

  • explicit responsive behavior

  • primitive-first layout

  • restrained abstractions

  • local orchestration ownership

  • predictable architectural structure

The resulting code typically remains close to standard React mental models while reducing the amount of CSS infrastructure, styling coordination and UI orchestration developers need to build repeatedly across projects.