shaun smith

BTW - Swiz 1.0 can handle independent view instances as well:
http://swizframework.org/files/examples/1.0.0-a...

Ha! Yes, now it can. And not a moment too soon!

Nice example - you mentioned that AMF is not a good coice for the web and used JSON - can you elaborate. Be interested in insights.

I've been meaning to write up a fat post on that very topic, but I'm kind of bored by the idea at the moment =)

AMF is good for "internal", "enterprise" apps where we can afford to send fresh copies of the data with every request. And it's good for dealing with really large datasets - it is a binary format after all.

But for a web system to withstand huge traffic everything that is cacheable must be cached. AMF often turns out to be a pretty poor fit for this exact reason.

JSON over http, on the other hand, is actually a very good format format for public facing web apps. Here's why:

Http can be cached easily, at the client (browser), at many points along the network, and on the server. Often this means that we don't even have to process the request, let alone send a full response. The cheapest thing we can do is on a computer, or across a network, is nothing at all. Http allows us to do that.

If an app has to load a lot of data, but most of that data changes infrequently, the app will be much more responsive if it can take advantage of client/network/server caching. And, in my experience, most apps have exactly that data usage pattern: we browse through large numbers of lists and documents. Sure, those lists and documents change, but most of the time they stay the same.

AMF doesn't work like that. Every request you make is unique, requires a full round-trip on the network, and must be fully processed on the server and client. Most of the time this is completely unnecessary, placing undue strain on all three tiers. So it really doesn't matter that the binary format is "lightweight", it is going to be infinitely slower than a cached resource.

When you view data as a resource things become much cleaner and easier to cache. A chunk of data is no different to an image. If it hasn't changed, don't bother sending it across the network. Http offers a couple of mechanisms to make this really easy. We need to take advantage of that.

AMF enables class mapping. This seems awesome at first - no parsing on the client, yay - but I can guarantee that you'll spend a LOT of your time keeping two separate type systems in sync. I need to go into much greater details here, but essentially I don't think that it's worth the effort.

Thinking about this some more - RIA clients are (can be) stateful so the client can store the data as long as needed. So caching requirements at the network level is reduced. Looking at James Wards' Census demo app for Flex (http://www.jamesward.com/census/) there is large time a penalty for transcoding (server) and parsing (client) formats - running the tests the transfer time for Ajax/JSON was slightly actually slighty less than for AMF, but the total time for AMF was significantly less (50%).

Thanks again for insights - all to easy to accept things until someone like yourself raises a point than makes one think/ask about it.

Thanks Shaun - good and valid points.