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

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

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

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.

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

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.

Building complex event chains

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

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

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“.

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.

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

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!

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.

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.

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.

1. User Experience

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?

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

2. User Interface

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!

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

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.

3. Accessing backend services

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

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.

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

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.

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

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

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

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.

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.

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.

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.“

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.

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

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.

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

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.“

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.

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

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

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

http://www.hackers-with-attitude.com	4304
http://lanyrd.com	237
http://paper.li	84
http://www.redditmedia.com	46
http://www.sanketj.com	37
http://www.clojure.cz	29
http://www.python.rk.edu.pl	23
http://crossdiver.tumblr.com	12
http://static.slidesharecdn.com	9
http://translate.googleusercontent.com	9
http://sanketspace.blogspot.com	8
http://sometimes-clojure.blogspot.com	7
http://j-reference.blogspot.com	7
http://www.gaecupboard.com	4
http://us-w1.rockmelt.com	4
http://www.onlydoo.com	2
http://members.webs.com	2
https://lanyrd.com	1
http://webcache.googleusercontent.com	1
http://j-reference.blogspot.fr	1
http://www.mashme.tv	1
http://www.slideshare.net	1
http://mezura.com.br	1
http://ingoool.tumblr.com	1
http://www.iweb34.com	1
http://j-reference.blogspot.ca	1

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

by Stefan Richter on Nov 09, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

26 Embeds 4,833

Statistics

Writing HTML5 apps with Google App Engine, Google Closure Library and Clojure — Presentation Transcript