Design Constraints

Constraints that shape the system

The previous chapters have already discussed:

• why components can be understood as protocols
• how prototypes organize interaction relations through information flows
• why prototype boundaries cannot be split arbitrarily
• how execution semantics constrain how prototypes come to stand over time
• why prototypes must enter hosts through a translation layer

The next question is:

why did Proto UI not make itself into an infinitely open abstraction system?

This article discusses:

• which design constraints Proto UI accepts on purpose
• how those constraints affect prototypes, syntax, and the translation layer
• why these constraints are not temporary compromises, but conditions for the system to remain valid in the long run

Any system that tries to describe GUI in a protocolized way will quickly face a temptation:

now that abstraction has started, should more and more problems also be absorbed into the core layer?

That direction looks natural, but it is usually also the easiest way to lose boundaries.

Because once a system tries to express everything, it will quickly start taking on all of this at once:

• detailed differences in platform capabilities
• engineering habits of each host
• all kinds of local implementation conveniences
• the personal writing preferences of authors
• higher-level business orchestration and UI organization problems

At that point, abstraction still exists, but it is no longer stable.
It starts looking more and more like an expanding engineering interface, rather than a migratable and verifiable protocol foundation.

Proto UI never intended from the beginning to swallow every GUI problem into the core layer.
It cares more about something else:

preserving the most critical interaction semantics without losing boundaries.

That is the starting point of its design constraints.

Many engineering decisions in Proto UI ultimately collapse into the same priority order:

semantic consistency > User experience > Maker experience > prototype Author experience

This does not mean the later items do not matter.
It only means that when these goals conflict, Proto UI chooses in this order.

The first priority is this:

whether the same prototype still remains the same interactive subject across different adaptation results.

This determines whether Proto UI can still be called a protocol layer at all.
If semantic consistency is sacrificed, then however good later experiences are, what remains is only a set of separate implementations that are merely “related” to one another.

After semantic consistency, Proto UI prioritizes the end user’s experience.

That includes:

• whether interaction is stable
• whether the fidelity of feedback is high enough
• whether performance is acceptable
• whether the real experience inside the host feels natural

Proto UI does not treat “protocol-correct” as something that only needs to hold on paper.
It must ultimately land in interaction quality that users can actually feel.

Only after that comes the experience of the Maker.

Here, Maker means the person or system consuming Proto UI artifacts inside a host.
This layer cares about:

• whether components fit the usage habits of host developers
• whether results generated by an Adapter or Compiler are easy to integrate
• whether the way of using them feels natural enough

It matters, but it still yields to the first two layers.

Last comes the development experience of the prototype author.

Proto UI certainly cares about whether prototype syntax is writable, readable, and maintainable.
But when author experience conflicts with the earlier layers, Proto UI does not automatically prioritize authors.

That is why some Proto UI constraints look relatively strict.
Some restrictions are not there because no more convenient writing style exists,
but because a more convenient style would more easily damage the more important goals in the earlier layers.

One of Proto UI’s first principles is:

a prototype must describe an interactive subject.

That means a prototype cannot be just an arbitrary fragment of structure, and it cannot be only a local template fragment in a visual tree.
It must always point to an interactive subject that can actually stand.

From this premise, many Proto UI constraints become easier to understand.

For example:

• a prototype acts on the current prototype itself by default
• once a substructure takes on independent information-flow responsibility, it must be split
• certain syntax capabilities are not opened to structures that still remain inside the parent prototype

On the surface these look like tightening writing freedom.
In reality they protect the answer to “who exactly is this prototype describing?” from being scattered away in the code.

Proto UI aims to stabilize interaction semantics at the component layer,
not to take over the organization of the final UI.

That means Proto UI does not proactively take on, by default:

• the business integration layer
• final composition among prototypes
• framework-level scheduling for complex scenarios
• higher-level UI organization problems unique to each host

Proto UI does allow logic reuse at the prototype layer,
for example by merging another piece of prototype logic into the current prototype.
That kind of reuse is closer to hook calls or inheritance. It handles the absorption of logic capabilities, not the structural composition of the final UI.

But how prototypes are assembled into a complete interface, how they enter concrete business, and how they are scheduled in more complex scenarios
returns to the host side by default.

This boundary is not accidental.
It corresponds to Proto UI’s judgment about its own position:

Proto UI is trying to do components, not final UI.

The community can certainly continue to build more complete framework capabilities on top of Proto UI,
but that is not what the official Proto UI project is prioritizing at the moment.

Some Proto UI boundaries are not only principles written in explanations.
They are also reflected in choices about syntax capabilities.

For example, Proto UI does not, by default, give authors the ability to let a substructure take on a complete independent set of information-flow responsibilities before splitting it out.
That means prototype boundaries are not only a writing style maintained by self-discipline. They are constrained directly during writing.

This approach narrows expression freedom,
but it also reduces another class of more expensive problems:

• boundaries of interaction responsibility quietly dissolve into the code
• prototypes degrade back into a structural assembly system
• it becomes less and less clear who the same prototype is actually describing

Proto UI’s direction here is explicit:
fix boundaries first, then consider how to improve expression efficiency within them.

Proto UI currently has another strong tendency:

the protocol layer prefers serializable expression by default.

This constraint does not only serve the current implementation.
It mainly prepares the way for later translation, verification, and more static artifact generation.

If the protocol layer accepted a large amount of non-serializable default semantics too early, such as:

• arbitrary functions
• platform objects
• host-exclusive references
• runtime values that cannot migrate stably

then it might feel more convenient in the short term,
but in the long run the protocol layer would immediately lose several important properties:

• harder to analyze
• harder to verify
• harder to compile
• harder to migrate stably into new hosts

So Proto UI does not completely deny the existence of those capabilities.
It simply does not treat them as the primary semantics of the protocol layer by default.

This constraint makes current expression look more restrained,
but what it buys is larger future translation space and a more stable long-term evolution path.

The same tendency also appears in host-specific capabilities.

Proto UI can acknowledge that many capabilities are important,
but importance does not automatically mean all of them should enter the core main axis.

Some capabilities:

• are naturally highly host-dependent
• are hard to migrate across platforms
• lack stable comparability across different hosts

These are better isolated as strongly host-related capabilities,
rather than entering the core protocol layer directly.

The host flow is a typical example.
It certainly matters, but it is also closer to the host itself and more easily pulled along by the concrete realities of specific platforms.
Proto UI’s way of dealing with this is not to deny its value,
but to place it in a more cautious position.

This makes the core layer look more restrained,
but it also keeps Proto UI’s cross-host main axis more stable.

Taken together, all these constraints protect the same thing:

Proto UI does not want the boundaries of its abstraction to slowly melt away for the sake of engineering convenience.

Without these constraints, Proto UI could certainly become more flexible:

• prototypes could nest more freely
• substructures could take on local interaction more freely
• the protocol layer could accept host-specific capabilities more quickly
• prototype authors might also find it more convenient to write

But the cost would also be obvious:

• prototype boundaries would become blurry
• the protocol layer would become harder to verify
• migratability would gradually decline
• the translation layer would be forced to accept increasingly mixed inputs
• the idea of “the same prototype” would become harder and harder to sustain

Proto UI’s design constraints exist to avoid that slide.

These constraints can easily give the impression:

is Proto UI simply choosing a more conservative path?

If you only look at the surface form, it can feel that way.
But what is really happening here is not “we cannot do it yet, so we are holding back.” It is:

to keep the protocol layer valid in the long run, some boundaries need to be protected first.

Proto UI can of course gradually relax some constraints in the future,
and it can accept more capabilities once engineering conditions are mature enough.
But it does not want to pull too much real-world complexity directly into the core layer before the abstraction has stabilized.

So the restraint here is not retreat.
It is a choice about sequence:

• make the protocol layer stand first
• then decide which boundaries are worth expanding

To keep the main thread clear, this article does not continue into:

• formal specification clauses
• concrete engineering implementation details
• host capability matrices
• milestone plans for specific versions

These topics will continue in the Specifications and Engineering sections.

If these design constraints are already in place, then the next focus is no longer:

what does Proto UI want to express?

It becomes:

how are these boundaries actually carried down into formal specifications and engineering implementation?

You can keep reading according to your goal:

• If you want to clarify boundaries and common questions, go to FAQ
• If you want to read the formal contract, go to Specifications / Introduction
• If you want to understand how the implementation layer carries these principles, go to Engineering / Introduction
• If you already want to participate in building prototypes or adapters, go to Ecosystem / Introduction