Open a browser, click a link, and the current page is replaced by the next one. Despite decades of progress in web technologies, this interaction model has remained largely intact. Inside a browser tab, user interaction is still fundamentally sequential.
This structure dates back to the earliest days of the web. Browsers were designed to render and replace documents, not to manage multiple active tasks simultaneously. While desktop operating systems evolved to support multitasking through concurrent windows and processes, browsers retained a document-centric model.
As web applications became more complex, developers adapted within those constraints. Single-page applications reduced reloads, and client-side frameworks introduced richer interactivity, but the underlying assumption remained: one primary view governs interaction at any given time.
A newer class of browser architectures is now exploring alternatives to that model.
An architectural approach to multi-view interaction
Floating Forms is a patent-pending browser architecture developed by ProBuilt Software that replaces the idea of a single dominant page with multiple concurrent, stateful views inside the same browser session.
Rather than routing all interaction through a single view hierarchy, the architecture allows independent views—such as forms, data grids, and lists—to coexist and remain interactive at the same time. Each view maintains its own state and lifecycle without requiring page replacement or modal overlays.
From an implementation perspective, this introduces challenges that traditional browser applications tend to avoid:
- State synchronization: Each view maintains independent state while remaining consistent with shared data models. Changes in one view must propagate predictably without forcing re-renders or navigation events in others.
- Event handling: User interactions are scoped to individual views, requiring event routing that avoids conflicts or unintended side effects across concurrent interfaces.
- Isolation within a single process: Unlike desktop applications that rely on operating-system-level process isolation, browser-based systems must manage logical isolation at the application layer.
- Performance tradeoffs: Keeping multiple live views active increases memory and event-processing overhead, requiring careful lifecycle management to avoid degradation.
This approach differs from conventional single-page applications, which typically centralize state and serialize interaction through a dominant view, even when UI components appear modular. It also differs from models such as Web Workers, which support background execution but do not natively enable multiple concurrent interactive views.
Implementation context: enterprise workflow software
ProBuilt has implemented this architecture in a browser-based ERP system designed for accounting, sales, and operational workflows. The system is structured to allow users to work across multiple functional areas at once, rather than moving through strictly sequential screens.
ERP environments place particular demands on consistency and concurrency, as users often reference and update related data across different contexts. In this case, the system serves as an implementation context for how a multi-view architecture can be applied to complex workflows inside the browser.
The ERP itself is not positioned as a benchmark or validation mechanism, but as a practical environment in which the architectural model is applied under everyday use.
Design implications and tradeoffs
Removing the one-page constraint changes how browser-based software can be structured. Interfaces can be designed around persistent context rather than navigation flow, allowing users to reference information without interrupting active tasks.
At the same time, multi-view architectures introduce new design considerations. Developers must decide how many concurrent views are practical, how to manage cognitive load, and how to balance flexibility with clarity. Sequential interaction models still make sense for many use cases, and multi-view interaction is not universally appropriate.
The broader implication is not that browsers must behave like desktop operating systems, but that the page no longer has to be the sole organizing principle.
A shift in assumptions, not predictions
The significance of architectures like Floating Forms lies in what they demonstrate is technically possible within the browser environment, rather than in predictions about adoption or market outcomes.
For most of the web’s history, single-view interaction has been treated as an inherent limitation of browser-based computing. Approaches that support concurrent, stateful views suggest that this constraint is architectural rather than fundamental.
Whether and where such models are adopted will depend on use case, tooling, and developer priorities. What is clear is that strictly linear interaction is no longer the only viable design path for browser-based applications.
