-
The server serves static files (a minimal HTML boilerplate and a client JS script
client.mjs
) and starts a WebSocket server. -
The client connects to the WebSocket server as soon as possible.
-
For each new connection, the server renders the component and sends the full "virtual DOM" to the client through the WebSocket.
-
When the user interacts with the generated DOM, the client invoke the corresponding callback of the component by sending a message through the WebSocket.
-
The component changes its state accordingly.
-
The server compares the new "virtual DOM" generated by the component with the previous one, and sends a patch to the client.
-
Very few JS code is sent to the browser (only a minimal framework to handle the server communication and DOM patching).
-
As the JS client side code is generic (= can be made into a separate dependency), the whole app can be written in any programming language.
-
All of the memory and CPU intensive tasks are run on the server, so the client can be very light.
-
Instead of doing the initial rendering when the client is loaded, it could be trivially done on the server (instead of serving
index.html
). -
With a bit of engineering, deployment of a new codebase could be done with a simple WebSocket reconnection and the interface can be refreshed with a "virtual DOM" patch. Since there is no logic in the client side, there is no need to download any new JS file or doing a full page refresh.
git clone https://gist.github.com/BenoitZugmeyer/5f86ce6f4775deda0d77dffdeb781d03 ws-framework
cd ws-framework
npm ci
npm start