views:

197

answers:

2

I've been experimenting with Adobe Flex recently. Being a long-time server-side web app developer, I'm faced with difficulties that I last experienced when I dabbled in Java Swing development a long time ago. It mainly revolves around the flow of control between my code and the framework's code. Most things are asynchronous as to not freeze the UI.

So, I'm looking for all the seasoned developers out there who have seen it all to put into words the shifts in thinking required to make the transition from traditional web apps to RIAs.

Update: Moved the distracting parts to another question.

+2  A: 

There's two models I'm seeing in the market right now:

  • Blended UI. The server is still involved in the UI construction effort, but a lot of it is offloaded to javascript. This is how a lot of the javascript toolkits work (except dojo, extjs, ...).
  • Separated concerns. The server is treated as a data storage and synchronization method only. The app runs entirely client-side, possibly even with local storage. This is how flex works.

I think we're going to be migrating towards the second model, because it means that you don't have to track UI state on the server, which dramatically simplifies the architecture. I've been toying with ExtJS and Flex, and the development experience is a lot like building a desktop app, only without the fancy drag-and-drop IDE's. It's hard to think of large differences between a three-tier desktop app and a web app in this fashion.

So my advice would be: stop thinking you're building web apps, always put into doubt whether something belongs on the server, because in the new model it often won't. Also, use gears or the browser cache effectively, because if your app is client-side, downloading all that code every time will be too slow.

Joeri Sebrechts
Thanks. Good point about Gears having a LocalServer versus Flex. But I think this is where AIR comes in - then you don't have to download the app every time. Gears is really the equivalent of AIR, not Flex. Both AIR and Gears require downloading a runtime and then execute downloaded applications.
thvo
Good point about air, I guess it differs from gears in viewpoint. Air aims to pull the app out of the browser, gears aims to augment the browser. The question is: do you want to be browser-based?
Joeri Sebrechts
True. But in the long-run this question will matter less. I don't consider Chrome to be another browser. I consider Chrome(plus Gears, which is built-in) a runtime for applications, like AIR. So the question is, which runtime do you use: AIR, or Chrome+Gears.
thvo
A: 

Two pieces of advice:

  • Your server should never ever trust anything given to it by the client. Like any web app, data originating on the client can be compromised.
  • Visualise. That's the real (perhaps only) benefit of RIA: the ability to give rich interactive visualisations of data, that can be mixed in interesting ways. Make the most of it.
GaryF
Thanks. Of course, server-validation is a must; RIAs are not about getting rid of this. In fact, if you look at SOFEA, it's all about data validation down to the data interchange, via XML. RIAs, are all about putting all of the presentation logic on the client, e.g. the screen flow.
thvo