You can edit almost every page by Creating an account. Otherwise, see the FAQ.

Pusa WEB

From EverybodyWiki Bios & Wiki



Script error: No such module "Draft topics". Script error: No such module "AfC topic".

Pusa WEB without JS — is the concept of client-server web applications, without the need for development in JavaScript for Frontend. Browser and DOM elements control is executed on the Backend. The architecture style REST with MVC is respect. DOM processing ramains on the Frontend and is managed by the Backend without any reflections. The concept and the PHP framework are published under the aGPL.v3 licence.

Key Features[edit]

Pusa implements the following principles:

  1. DOM events handling executes on server side (Backend) by client side (Frontend) requests.
  2. Backend generates instructions for Frontend based on request conditions only.
  3. The specification of the instructions is limited by the protocol and does not require modification for the task of the application.
  4. The backend does not check the result of executing instructions.

Bases of working with DOM[edit]

Frontend generates a list of focused DOM elements based on Backend commands. All actions with the DOM, including changing content, creating deleting elements, changing css, are performed only on focus elements. So the Backend is controling DOM and the hard work is left to the Frontend. The concept allows you to exclude development in JS, while storing state on the Backend is not required.

Client-server circle interaction[edit]

Comparison of client-server interaction schemes. Standard REST distributes application code between Front and Back. Pusa REST leaves work with the DOM on the Frontend side and moves control to the Backend. No components are added. Not a REST performs the function but requires DOM reflection on the Backend.

On page load, the browser loads the basic DOM content and the Pusa JS core.

The Frontend dispatches events (e.g. click, blur, focus, keypress, mousemove, e.t.c.), attributes and properties of the event element, the current page URL, and GET and POST parameters on the backend.

Based on the received Pusa-Back data, the controller executes the payload and generates a response with directives.

Upon receiving a response, Pusa-Front executes commands, modifying the DOM and producing visual effects.

Advantages[edit]

Pusa eliminates the need for JS development for the Frontend, and therefore does not require API negotiation between Backend and Frontend. The lack of JS solves the problem serialization of the REST, eliminating the need for tools like gRPC and so on. MVC components are limited to Backend, and not redistributable to Frontend.

The client JS browser application is compact (6 KB in production) and stable. This conceptually improves security, because the Backend application code is not externally accessible.

Directing events to the server represents for SEO the entire scope of user actions for analysis.

The page load time is reduced for the user. The time to open the first page is minimal as there is no massive JS loading.

Specifics[edit]

Pusa shifts part of the load from the Frontend to the Backend, and increases the frequency of exchange with the server. The frequency of calls is compensated by the decrease in the load from the execution of each request due to the internal architecture of Pusa. The backend does not do the "heavy" work with the DOM, but generates only instructions for the Frontend.

Pusa does not use JS code outside of the main framework, but does require JS to be included on the Frontend side for functionality.

Limitations[edit]

Interactive applications, which are based on canvas and onmousemove, generate a significant stream of events. Pusa has call buffering and closure mechanisms to handle multiple events, such as mousemove, without increasing server load. However, if it is necessary to process each event with the execution of Pusa logic, it is not an optimal solution. Example: JS code is required when developing the core of online graphics editors.

If the application requires the use of third-party JS scripts, they must be loaded into the browser. Pusa provides a mechanism for using external JS scripts.

PHP Implementation[edit]

At the time of publication, Pusa is implemented in PHP 7.2 with the main transport is AJAX via XMLHttpRequest. The source code is provided at gitlab. The fully functional container is available via Docker as part of Ubuntu, PHP, Nginx. The main goal of the implementation is to demonstrate the Pusa concept in the most simple ways.

The implementation includes:

  • Creation and support of many web projects on one host;
  • Cross-project inheritance of source code and content;
  • Multilingual support for text and graphic content;
  • Ability to implement custom controllers in the MVC paradigm;
  • The ability to interact with the clipboard, multimedia objects, address bar, console, css and others;
  • CLI interface;
  • Demonstration examples.

Pusa directives form a linear structure through chained method calls. Loops and conditions are not required in most cases.

public function Init()
{
    return $this
    -> Debug( TPusaCore::DEBUG_ON )
    -> Event( 'Main', 'Popstate', 'popstate', TPusaCore::TARGET_WINDOW )
    -> DOMBody()
    -> DOMTemplate( 'Main.html')
    -> DOMSelect( 'Menu' )
    -> DOMSelect( 'Action')
    -> Event( 'Main', 'Item' )
    -> Popstate();
}

Pusa's DOM manipulation code is more concise than vanilla JS.

/* Pusa PHP */
$this->DOMBody()->DOMSelect('MyClass')->DOMContent('Content');
/* JavaScript */
let l=document.getElementsByClassName('MyClass');for(let i=0;i<l.length;i++){l.innerHHTML='Сontent'};

History[edit]

Core server libraries began to take shape in 2004 with a series of holding projects using the Microsoft product line. Subsequently, they were combined into a Catlair mono-core based on MSSQL, in which both Backend and Frontend were present. Codebase support on Microsoft products became impossible in 2014. The project has been migrated to Linux using MySQL in the basic version. The software tools used and the coordination of individual tasks between the Backend and Frontend required a reduction.

A decrease in development tools and heaving the low-level device coding experience led to the creation of Pusa in 2019. It was based on the perception of the browser as a hardware black box with no backward interaction. This made it possible to implement the directive principle of transmitting commands in response to a request. The need for optimizing the infrastructure determined the development of Pusa on the minimum available equipment. Performance is achived through scalability.

From February 2021 to November 2021 code of Pusa was separated out in the project published in 11.06.2021 under the licence aGPL.v3.

Plans[edit]

It is planned to publish the CRUD API for MySQL based on PHP.

Further development will focus on creating an Enterprise version with the Pusa protocol over WebSocket without abandoning AJAX, separating out the CRUD API for Postgress, MSSQL, as well as implementing Pusa in languages in order of priority:

The next plan is to implement a mobile application development platform using the Pusa protocol by embedding it in the browser API. This goal will allow us to fully implement the basic concept of the Web without JS.

External links[edit]


This article "Pusa WEB" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Pusa WEB. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.