This is the talk I gave at the Google Developer Day 2010 in Munich. The room was crowded. All seats were taken. People were sitting in front of the "stage" and still lots of people were standing in the back. So there was lots of interests in Clojure Programming on Google App Engine. Thanks Google for having us here! :)

1. Writing HTML5 apps with Google
App Engine, Google Closure
Revised v4Presenter
Library and Clojure
Stefan Richter, Founder & CTO of freiheit.com

2. How many people are here in
this talk because of:
- Google AppEngine
- Google Closure Library
- Clojure

3. So let‘s talk a bit now about
why I think it is more difficult to
build a client-side component-
based HTML5 app in
comparison to rendering
complete HTML pages on the
server.

4. „I believe that the more you
know about the past, the
better you are prepared for the
future.“
-Theodore Roosevelt

5. Before the first internet boom,
people built desktop apps
often like this:
Just put some widgets into a
window, fill out the event
handlers and „bam“, there you
have a maintenance hell.

6. Building
complex
event
chains

7. The widgets/components send
events between each other.
They catch events, execute
some code which maybe fires
even more events.

8. In 2-Tier Client-
Server apps,
people were
even accessing SQL Rows
the database
directly from the
event handlers.

9. The IDE industry was built
completely around this
programming model. Just take
some components and wire
them together by using
events. They dreamed about
„software factories“ and
„component markets“.

10. But it was not that easy.
Code like this is very difficult
to maintain and understand:
Soon you‘ll end up with very
complex event chains, which
are maybe not understood
anymore just by reading the
code.

11. So my very first rule is:
„You should be able to
understand what your
application does just by
reading the code.“

12. Maybe you are surprised now,
because this seems so
obvious.
But: JavaScript makes it very
easy for us to write Callback-
Functions. So it is very easy to
take this approach too far!

13. With Server-based HTML
apps, you are rendering the
complete page in one piece.
One request and one
response at the time. In this
moment, you don‘t have to
think much about different
threads of execution.

14. One side-note about GWT:
GWT makes GUI programming
inside the browser much easier,
but it doesn‘t take the burden
away from you to structure your
application in the right way.

15. For the HTML5 client of
TheDeadline, we first thought
about the User-Experience (UX),
then how we wanted to generate
the User-Interface (UI) and then
how the UI should communicate
with the underlying backend
services.

16. 1. User Experience

17. In a browser, with CSS3 and
JavaScript, you can build much
richer user interactions than with
the classical WIMP approach.
So why use a traditional Widget
set instead of building a custom-
made user-interaction?

18. Here comes my second rule:
„Don‘t try to write Windows-
style Desktop apps inside the
browser.“

19. 2. User Interface

20. With HTML5, you will have to
generate more and more of
the HTML code on the client-
side. One way to do it is to use
a client-side template system.
We took Google Closure
Templates, because you can
use them on the server, too!

21. Here comes my third rule:
„Be prepared to render most
of your HTML code on the
client-side.“

22. We try to do as much page-
rendering on the client-side as
we can, only encapsulating
state into custom-widgets
when needed.
And we try to centralize the
event-handling as much as
possible with our event-db.

23. 3. Accessing backend services

24. User-Events
TheDeadline HTML5 UI (rendering)
Data-Access
Notification
(Key/Value Pairs)
event-db API
HTML5: Local Storage API
Browser
XHR/JSON Notification
Google App Engine
Datastore

25. From the Google Datastore to
the JavaScript User-Interface:
We are using Key/Value Pairs
as the primary datastructure in
TheDeadline.
I think, that this is the future of
application development.

26. No more „impedance mismatch“.
No more Object-Relational
mappers.
No more transformation steps
between different incompatible
„formats“ like database rows,
XML, (serialized) objects

27. Do we really need classes/objects
to pass data around?
There are many flavors of the
object-oriented paradigm.
Compare Smalltalk, CLOS or
JavaScript to Java. Or see how
Clojure brings the advantages of
OOP to a non-OOP programming
language with protocols.

28. Let‘s see how we are doing this
in TheDeadline.

29. We generate the datastore
access code on the server with
Clojure Macros.

30. With the macro-generated
functions, we can create new
todos.

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

32. The next slide is from my
keynote today. It shows the way
we write functional code on both
the client- and the server-side.
We are using exactly the same
data-structures in two different
languages.

34. Simple fictitious example:
{todo: „@responsible@xyz.com please check
the #homepage“}
This might be transformed by a function into this before
saving:
{todo: „@responsible@xyz.com please check
the #homepage“, tags: [„homepage“],
responsible-id: 4711, owner-id: 1337}
In your programs, you are transforming, folding and
passing around data all the time. If your programming
language can handle this syntactically, you might not need
classes most of the time.

35. This brings us to my fourth
rule:
„Don‘t write JavaScript code in
the style of the Java language.
Forget everything you learned
by writing Java code.“

36. So no complex class
hierarchies. JavaScript wasn‘t
made for this.
Try out how far you can go
with just key/value pairs and
write functional JavaScript
code without side-effects to
operate on this data.

37. By the way: This is much
easier to test, too!

38. Our event-db has some more
advantages: You can write
apps that the user can run
offline. You‘ll need this for
mobile HTML5 apps.

39. This is why my fifth rule says:
„Plan ahead for Offline
capabilities. But be aware, that
users maybe try to sync stale
data.“

40. Therefore my sixth rule:
„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
and this could cause problems.“

41. We are versioning all changes.
But we don‘t store the version
data. We store the operations
that changed the data.
Nice side-effect: Perfect real-
time statistics about the usage
of your system.

42. I think we are coming to the end
of my talk.
Even if you don‘t share my
opinions, maybe it made you
think. My ideas are evolving,
and changing, too. Interested?
Follow me on Twitter:
@smartrevolution

43. Some more rules:
7. You need push notifications.
8. Key/Values != ER-Model
9. Log client-side exceptions to
the server.

44. 10. Have fun! Build your dreams!
+ =
App Engine Clojure TheDeadline
TheDeadline:
http://www.the-deadline.com
Corporate Blog:
http://www.hackers-with-attitude.com
Corporate WebSite:
http://www.freiheit.com