Stefan Richter, CTO of Freiheit.com, explained this week at the Google Developer Day in Munich, his vision for writing rich internet applications using HTML5 and Google App Engine. In particular, he thinks that it will be -a bit- more difficult to build a client-side component based HTML5 when compared to Server-based page rendering.

In the pre-Web days, thick client application models were based on widgets, events and event handlers which often resulted in complex event chains which lead to maintenance nightmares. In 2-tier Client application models people were even accessing the database directly from the event-handlers. With Server-based page rendering, the complete page is (often) created in one piece, one request and one response at a time.

Stefan explains that with HTML5 "you will have to generate" more and more of HTML code on the client side. One way they have been experimenting with is the use of Google Closure Templates.

Closure Templates are a client- and server-side templating system that helps you dynamically build reusable HTML and UI elements...Closure Templates are implemented for both JavaScript and Java, so that you can use the same templates on both the server and client side.

He also recommends to centralize event-handling and only encapsulate state into custom-widgets when needed.

From a back-end perspective, he asks the question "Do we really need classes and objects to pass data around"? They generate the datastore access code on the server with Clojure Macros. The same data structures are used on the client and the server:

We are using Key/Value pairs as the primary datastructure... I think this is the future of application development. No more impedance mismatch, no more OR mappers, no more transformation steps.

Clojure works internally with Key/Value pairs. We can retrieve them to and from the Google Datastore, and we can send them to the client as JSON.

Stefan suggests to try to go as far as you can, with just "key/value" pairs, and write functional JavaScript code without side-effect to operate on this data.

During his talk he enunciated a series of general principles for the next generation of RIAs:

You Should be able to understand does, just by reading the code

Don't try to write Windows-style Desktop apps inside the browser

Be prepared to render most of your HTML code on the client-side

Don't write JavaScript code in the style of the Java language. Forget Everything you learned by writing Java code.

Plan ahead for offline capabilities [and synching stale data]

You'll need an idea how to cope with concurrent modifications, when it is likely that your users can modify the same data at the same time