CloudBrowser is a way of rethinking how we write HTML-based Rich Internet Applications, also referred to as AJAX applications. Put simply, the key idea behind CloudBrowser is to keep the entire application, including its data model, (DOM Level 2/3 and JavaScript-based) controller logic, and (HTML-based) view server-side, and use the client-side browser as a (dumb) display device, or thin client, similar to how an X Server displays a remote X client's graphical user. CloudBrowser instances live on a server, and client browsers can connect and disconnect at will, and it is also possible for multiple users to connect to the same instance, which yields a natural co-browsing ability.
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 is implemented in CoffeeScript/JavaScript using the Nodejs infrastructure and the many libraries existing for it. As a result, the application developer finds a familiar environment, both in terms of language as well as with respect to event-based execution semantics.
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.
Check out: