With CloudBrowser, we are asking what the effect of this design choice on application development would be. We see a number of key benefits:
CloudBrowser shares a number of properties with ZK (and similar server-centric frameworks), such as avoiding client-side code and keeping a representation of the user interface server-side, using a document abstraction. Our work on CloudBrowser was inspired by extensive experience using ZK.
A key difference is that CloudBrowser does not have a page composition phase and that it does not create a separate 'Desktop' instance for each visitor. This means that users can visit the page as often they like, without having to recompose the page. ZK does not provide any support for remembering a Desktop's state except what the application developer chooses to store in session (or application) state. When a new Desktop is created, the application developer must retrieve that state and influence the page composition logic appropriately. Note that the absence of a page composition phase does not mean templating can't be used when a CloudBrowser instance is loaded.
A second key difference is that CloudBrowser performs a strict 1:1 mapping between server-side elements and client-side DOM. As a result, styling is much simplified; CSS style rules that refer to classes, ids, and hierarchy apply. Problems like these don't occur.
CloudBrowser is much simpler on the client-side, because it doesn't support direct access/manipulation of layout attributes. It also does not provide higher-level components (though these can be built using readily available client-side libraries such as jQuery plugins or Bootstrap/JS.