Single Page Interface (SPI) is a web design paradigm which promotes any web site and web application can fully run into the same page with no reload, preserving SEO, back/forward buttons (history navigation in general). SPI solves many problems of page based navigation and provides a richer user experience, the SPI paradigm is already mainstream for web applications… why not for WEB SITES? The Single Page Interface Manifesto shows some technical ideas of how to achieve this objective for web sites.
- Because of server-centric approaches need tons of server memory because visual state is managed in server, affordable for web applications but not for web sites.
- Nice visual changes driven by mouse movements and timed visual changes (usually opacity changes): just cool manipulations of class and style attributes of elements. Yes, this kind of visual effects cannot be processed in server, a nice JS library may be very useful here, but do these visual effects imply full client-centric approach?
The second reason, server-centric needs tons of memory, is harder to deny.
Alternatively we can follow a server-centric approach.
Server-centric SPI web sites is a topic very new and almost orphan in web technology, is very hard to find a technology able to provide enough flexibility for web sites, back/forward friendly and SEO compatible.
Very hard to find but not impossible, ItsNat has been for a while specialized in this kind of emerging paradigm applied to web sites and applications.
When I was developing this demo web site I was very careful with server memory, I applied the best techniques provided by ItsNat to save server memory:
- Caching static HTML zones: if a zone is static, that is, no rendering with some kind of dynamic data is required, this zone can be declared as cacheable in templates (page and fragment templates), cached zones are missing in the DOM server because they are shared between users in markup form (not DOM), ItsNat automatically sends this cached zones to the client when required.
- Use of global user defined listeners/events to avoid clickable elements to be reflected in server DOM registering a mouse click listener for any of them (the simpler pure server-centric approach in ItsNat).
In spite of previous techniques some states were server consuming, for instance the TV LCD List, this list must be rendered in server with data extracted from a (simulated) database. Because this markup zone is rendered with dynamic data cannot be static, so it cannot be cached in spite of using user defined events for links to show product details.
Sometime later I realized this TV model list is not going to be used in server after rendering in server and sent to the client, this DOM subtree is fully replaced later when a new different page state is loaded.
What if I remove DOM subtrees, no longer going to be used, only in server to save memory? Then ItsNat v1.1 best feature was born, as of this version you can manually remove DOM subtrees when they become static after some use with a simple method call. The same client DOM zone remains untouched and now can be freely modified with no problem of client-server desynchronization.
Disconnection is reversible, just add a new node to the parent node of the disconnected zone and the client is back in sync with server or call to this method.
This new feature was applied to the demo, the resulting web site is mainly stateless and in the same time server-centric and Single Page Interface.
You can find a simple demo of this feature here.
Release Notes of ItsNat v1.1