The common approach to build a web UI today is to break it to the server and client-side and connect them with some kind of remote API. Often, these two sides even use different programming languages, dependency management, and build tools. This all introduces a lot of accidental complexity. Any change made on the client-side potentially needs to be reflected on the API and the server-side. Isn't it sounds like developing and supporting effectively two applications instead of one?
An server-state web application lives on the server-side and abstracts the client-side. The browser acts more like an equivalent of a terminal for Unix X Window System, a thin client. After loading an initial page HTML, it only feeds events to the server and updates the presentation to the incoming diff commands.
A developer's experience may feel similar to creating a desktop application UI in reactive style with HTML and CSS. Or like creating a React application with direct access to its backend data.
1 comment
[ 3.1 ms ] story [ 14.3 ms ] threadAn server-state web application lives on the server-side and abstracts the client-side. The browser acts more like an equivalent of a terminal for Unix X Window System, a thin client. After loading an initial page HTML, it only feeds events to the server and updates the presentation to the incoming diff commands.
A developer's experience may feel similar to creating a desktop application UI in reactive style with HTML and CSS. Or like creating a React application with direct access to its backend data.