This is the second post in Problems Cotomy Set Out to Solve. This continues from HTML and CSS as One Unit . Business systems are form-first by nature. Most screens follow the same rhythm: input → submit → reflect. Yet the implementation of that rhythm is still handled on a per-screen basis, as if it were a local feature.
Cotomy started by questioning that assumption.
The Reality of Form-Centered Systems
In business UI, almost every screen is a form. The differences between screens are in what they send, not in how they should be sent. Despite that, submit logic is often rewritten on every page. The result is a fragmented system protocol.
Most business systems also have many entities because the target domain itself is broad. Once that happens, CRUD operations multiply quickly. The same entity often appears in different screens depending on actor, use case, or operation context. A single master may end up with separate create, edit, approval, search, and maintenance screens, each shaped a little differently, but all still based on the same form-centered interaction model.
What Traditional Form Submit Gets Wrong
Classic form submit patterns repeatedly create the same failures:
accidental re-submits after refresh or back navigation, UI state loss tied to page transitions, inconsistent user feedback across screens, and duplicated logic that differs slightly from page to page.
More importantly, most CRUD submit flows are already shaped by the form definition itself. The program logic around them should mostly be the same: collect values, submit, lock appropriately, handle failure, and reflect the result. This flow is not application-specific. It is a system-level behavior.
But once teams move toward jQuery-style AJAX, the place where this logic lives often shifts into event handlers. The structure is then recognized through click callbacks and per-page scripts rather than through the form or page as a clear unit. Perhaps part of why this felt wrong to me came from my background with Windows Forms, where the screen unit remained easier to see. Even so, I think the mismatch is real: event-driven submit code tends to obscure the form as the actual operational boundary.
I remember struggling with this directly when I was developing with jQuery. I was already used to object-oriented development, so I wanted to bring that same kind of structural clarity into the screen model. But browser-side JavaScript at the time made that awkward too. The language and browser environment were not yet comfortable for writing this kind of code in a clear object-oriented style.
AJAX Did Not Fix the Structure
AJAX became the default, but the structure stayed the same. Each screen still has its own submission code, and the behavior diverges:
loading states stay inconsistent, error handling diverges, double-submit protection varies, and post-success updates remain ad hoc.
AJAX undeniably made richer UI easier because it created room to insert more processing before and after the request. Partial refresh, local validation feedback, and screen updates all became more practical. In that sense, AJAX was better for building interactive business screens.
But that did not solve the previous problem. The transport changed, yet the form-centered behavior was still not treated as one shared structure. AJAX changed the transport, not the protocol.
The Core Problem
Form submission is not a feature. It is a shared protocol. In business systems, this protocol is closer to an operation model than a simple HTTP exchange, which is why treating it as per-screen fetch logic leads to structural drift. Here, runtime means the controlled entry point where UI intent becomes a server-side operation and where state transitions are allowed to happen. One part of that drift is conceptual. The main function of the screen is often an entity update, and that intent is clearly visible in the UI. Yet the implementation is reduced to one event handler somewhere in the page script, so the screen becomes harder to follow as a screen. The operation is central in meaning, but peripheral in structure.
The usual reaction is to write the flow explicitly for each screen so the logic becomes easier to see again. But then the same submission behavior starts spreading across many pages with small variations. That is a different form of failure, and I think it comes from the same root cause: the implementation flow has drifted away from the semantic structure of the feature itself.
The boundary should be understood clearly: the UI expresses intent, the form submission path carries that intent through a defined protocol, and the server owns the authority to perform the operation.
That means the responsibilities should be split like this:
validation should stay a screen responsibility, submission flow should be runtime-structured, UI lock during submit should be handled through runtime hook points, error handling should follow a runtime-defined structure, and response reflection should use a defined extension point.
The runtime should own the flow so the system remains coherent. Cotomy formalizes this as a runtime-level submission protocol rather than per-screen logic (see Cotomy Reference – Forms Basics ).
Why It Matters More in Business Systems
Business systems scale by adding screens, not replacing them. The risk of inconsistent submission behavior grows with every new form. When the UI is operated by humans at scale, small inconsistencies turn into costly mistakes.
The deeper issue is not only duplication. It is that the operational meaning of the screen becomes harder to see. A user sees “register,” “update,” or “approve” as one business action. But the implementation may be scattered across page-specific callbacks, AJAX branches, and small local exceptions. Once that happens repeatedly across many entity screens, the system stops feeling like a coherent set of business operations and starts feeling like a collection of unrelated scripts.
That disconnect matters more in business systems because the same operational shape appears again and again. If the structure for submit is not shared, developers must keep reconstructing the same intent from local code. The cost is not just more lines of code. It is slower understanding, weaker confidence during change, and more opportunities for one screen to quietly behave differently from another.
Consistency in submission flow is not a convenience. It is a precondition for operational safety.
Cotomy’s Position (Without Implementation Detail)
Cotomy centralizes form submission flow in the runtime layer. Screens define what to send. The runtime defines a unified submission flow. That structure allows consistent lock strategies and response reflection patterns to be implemented at the form level. The protocol is shared, not reinvented.
This matters because it restores the structure to the same level where the user and the developer both recognize the screen. The form remains the unit of operation. Screen-specific intent stays in the screen. The repeated mechanics of submit, lock, error handling, and reflection move into the runtime where they can stay consistent across forms.
That does not remove local behavior. It puts local behavior in the right place. The screen still owns its fields, validation, and meaning. The runtime owns the submission protocol that keeps those screens coherent as a system. Cotomy treats form handling as one runtime path rather than as submit code scattered across individual screens.
Common Misreadings
This is not an AJAX debate or a UX polish topic. It is a structural safety discussion for business UI.
AJAX can still be the right transport for richer interaction. The question here is not whether requests should be asynchronous. The question is whether form submission is treated as a shared operational model or left as page-level glue code.
Problem Series
This article is part of the Cotomy Problem Series, which examines recurring structural failures in business UI design.
Series articles: HTML and CSS as One Unit , Form Submission as Runtime, Screen Lifecycle and DOM Stability , Form State and Long-Lived Interaction , API Protocols for Business Operations , Runtime Boundaries and Operational Safety , UI Intent and Business Authority , and Binding Entity Screens to UI and Database Safely .
