AjaxWorld: Michael Galpin
The networked application pattern: an emerging RIA design pattern
blog.
Traditional web application: sends a request, application server does a bunch of stuff, server returns HTML. Bad.
Networked application = good. Make a request to a web server or CDN. static content. Sends back an application - code - to run in the browser. App uses various frameworks, but code runs on client. Now app makes request to app server, server sends back data.
Why? one reason: architecture. 1998 - hello world, presentation and app on server. 2003: ajax presentation spread between server and client. 2006: RIA - presentation on client only. Another reason: performance. non-varying content can be cached at the network edge. Saves money (cpu power, less bandwidth used). Mobility - app can be rehosted on other servers, or on the desktop (Air).
What about Ajax? send request, get html+js, use framework on client, send xhr, get back ?x. If ?x is html, can be complex. May need additional javascript, css, etc. If ?x is data only, we end up duplicating the presentation code between the app server and the client-side JS. “Ajax is hack”
Solution: JS widget kits, e.g. dojo, extend js, jquery, etc? Given a better abstraction for making changes on the client. Good points: functional language (JS inspired by scheme); frameworks (make JS object-oriented); lots of choices. Bad: browsers (cross-browser inconsistencies, many browsers); DOM APIs; mix-n-match (can we mix, say, extend and jQuery without name collisions). Ugly: javascript is really slow; cross-domains (no good solution for secure cross-site scripting); ref count garbage collection (can get reference cycles which block gc).
Solution: GWT? Write in Java, compile into javascript, abstraction for Ajax calls. Good: supports OOP; static typing; produces killer Javascript; tool support (e.g. Java debuggers). Bad: supports OOP (it’s not for everyone); static typing (duck typing more flexible); killer Javascript (easy to debug when it’s Java code, hard to debug when translated to Javascript). Ugly: it’s still Javascript (see above)
Solution: Flex? Good: MXML (declarative); ActionScript (ECMAScript, OO,
inheritance); Flash engine good for graphics; tool support; browser
independence; fast evolving (75% penetration of new Flash player version in six
months); good for polished UI’s; support for developer/designer collaboration
workflow; speed (static typing allows better optimisation); better GC; support
for cross-domain scripting using declarative policy file (crossdomain.xml).
Bad: licence costs; hard to find experienced developers.
Also consider MS Silverlight. MS looked at Flex, kept the best bits and fixed the obvious problems. JavaFX – good for 3d API’s. Both Silverlight and JavaFX have questions over deployment/penetration.
Acronyms: SOUI (service-oriented UI), SOFEA (service oriented front-end architecture)
Question (by me): “doesn’t DOM-manipulation a la Ajax integrate better with the browser model (bookmarks, history, copy-paste, etc)? Answer: not really. Flex has lots of API support for browswer integration [I didn’t manage to note down the long list of things it can do]. All RIA’s have some difficulty with the history model of page-based browsing, though there are workarounds.
Summary: entertaining speaker with a nice summary of the features of the languages. Clear which solutions he was advocating! I would have liked a bit more on the architecture of the networked-application, though that was probably asking too much for talk this long. Will check out his blog to see how much of that is covered there.