A stateless server generates declarative directives and sends them to the client in response to a request. The client applies the directives to the existing DOM, including DOM changes, event handling, and actions. Subsequent events are sent back to the server, which generates new directives.
┌──────────────────────┐ ┌────────────┐ ┌───────┐ │ Pusa │──directives──▶│ Pusa │──── content ───▶│ │ │ Backend │ │ (Frontend) │ │ DOM │ │ directives=f(events) │◀───events─────│ │◀─── events ─────│ │ └──────────────────────┘ └────────────┘ └───────┘
The frontend operates based on directives. The backend selects the required DOM elements in focus and performs actions on them, including content changes, element creation or removal, and style modifications. Thus, control resides on the backend, while the actual execution remains on the frontend.
When the page loads, the browser loads the DOM content, the Pusa JS core, and the initial directives.The frontend sends browser events (such as click, blur, focus, keypress, mousemove), attributes and properties of the event element, and the current page URL to the backend.
Based on the received data, Pusa-Back determines the controller, executes the payload, and generates a set of response commands.
Upon receiving the response, Pusa-Front executes the commands, modifying the DOM content and producing visual effects.
Pusa is intended for implementing multi-level web interfaces with extensive user and administrative functionality.
Pusa shifts part of the workload from the frontend to the backend and increases the frequency of server exchanges. The increased request frequency is compensated by reducing the processing load for each request thanks to Pusa’s internal architecture. The backend does not perform "heavy" DOM operations but generates instructions exclusively for the frontend.
Pusa does not use JS code outside the base framework but requires JS to be enabled in the browser to implement functionality.
Interactive applications that actively use onmousemove generate a significant stream of events. Pusa has buffering and closure mechanisms that allow handling multiple events, such as mousemove, without increasing server load. However, if each event requires processing with Pusa logic, it is not the optimal solution. Example: custom JS code is required when developing the core of online graphic editors.
If the application requires using third-party JS scripts, they must be loaded in the browser. Pusa provides a mechanism for using external JS scripts.
Pusa minimizes the need for frontend JS development, thus eliminating the need to coordinate API calls between the backend and frontend. The absence of custom JS resolves REST serialization issues, removing the need for tools like gRPC, etc. Components are limited to the backend and do not spread to the frontend.
The client-side JS application in the browser is compact and stable. Pusa conceptually enhances security because backend application code is not accessible externally.
Sending events to the server provides the full scope of user actions for SEO analysis.
Initial page load time is minimized for the user.