Why Proto UI

A team maintaining both React and Vue applications may need to fix a Switch’s keyboard handling, disabled behavior, or change notifications in two component implementations. A later technology migration brings the same responsibilities back again.

The knowledge worth maintaining together often lives in these details: which operations should change state, what users must perceive, and when the application should receive a notification. Proto UI aims to preserve the parts that hold across technologies so later implementations can reuse and test them.

Mature component libraries already reduce this repetition. Headless libraries, for example, centralize state, keyboard interactions, and accessibility handling. If your ecosystem reliably covers your needs, continuing to use those libraries is entirely reasonable. Proto UI explores whether that knowledge can remain executable and maintainable beyond its original technology boundary.

• Maintaining several Web stacks. You want to share corrections to component behavior and verify them in each application.
• Building a long-lived component library or design system. You want interaction definitions to accumulate beyond the lifetime of the current framework, instead of reconstructing them with every migration.
• Filling a component gap in your ecosystem. First check whether the official prototype libraries and target Adapter cover it; missing coverage still requires prototype or adaptation work.

These situations indicate where reuse may be valuable. Actual benefits depend on component coverage, host capabilities, and integration cost. Adding an Adapter does not automatically make every Prototype usable; each combination still needs verification.

A shared definition may reduce divergence among behavior implementations, but it also introduces maintenance responsibilities. Debugging may require distinguishing an incomplete interaction definition, an incorrect Adapter mapping, and an application integration problem.

The target Host’s input, focus, rendering, and accessibility capabilities still need to be connected correctly. Reusing a definition can concentrate some work, but cannot remove every host difference or verification cost in advance.

If you only need mature components in one framework and existing options meet your needs, the additional abstraction may offer limited benefit. Even with several stacks, check current coverage before deciding how much to invest.

A useful starting point before deciding on a library-wide migration is to:

1. Choose a component relevant to your application in UI Libraries and inspect its API and examples.
2. Follow Quick Start to integrate it into an existing page.
3. Check the input methods, state notifications, styling, and accessibility behavior you depend on. If you plan to use several frameworks, verify each target environment.
4. Record integration and debugging costs, and whether it reduces work you would otherwise repeat, before expanding adoption.

A getting-started path is available for the stable 0.2.0 release, while the project remains in v0. Website demos, repository development, and a published version may have different capabilities. Evaluate the version you actually install with your target Adapter.

Continue to How It Works for the division of responsibilities between Prototype and Adapter. For the reasoning behind this direction and where it might fail, start with the whitepaper preface.