BT

Writing HTML5 Applications with Google App Engine, Google Closure Library and Clojure

by Jean-Jacques Dubray on Nov 09, 2010 |

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
  • You need push notifications
  • Log client-side exceptions to the server

The Deadline application was created following these principles.

Is HTML5 (and the Cloud) changing the architecture and programming models of RIAs? Are developers and architects ready to make the jump? What do you think?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Clojure in Deadline by Werner Schuster

BTW here's an interview with Stefan Richter on the Clojure part of TheDeadline and on using Clojure on AppEngine:
www.infoq.com/articles/deadline-clojure-appengine
It's from earlier this year, when the project was launched.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT