Aral Balkan

I just read that Patrick Mineault thinks that SWX is a bad idea. Although I have the utmost respect for Patrick and I love and support his work, I respectfully disagree with him. SWX is a good idea and here's why.

(I started responding to Patrick's post in the comments on his blog but it got too long so I'm posting it here instead.)

The followering are the main points Patrick makes in his post, along with my counter-points:

Now my first point is that SWX reinvents the wheel, and for no good reason. Let's list out the various ways to do asynchronous data communication in Flash. We have LoadVars, XML, Remoting, JSON, SOAP, XML-RPC, and PHPObject. One solution seems more than enough for this very simple tasks; adding another one to these 7 seems like a complete waste of time.

I remember when Flash Remoting came out that, for a long time, people would make the same argument against it: Why do we need another way to exchange data? Why did they re-invent the wheel? And the answer is the same now as it was then: We need it because the existing methods do not meet the needs of certain people.

If we were to accept Patrick's argument at face value, there would be no reason to go beyond LoadVars and we could throw XML, Remoting, JSON, SOAP, XML-RPC and PHPObject away, labeling all of them as redundant. After all, as I mentioned in my talk at the LFPUG last night, the core concept at the heart of building data-driven applications is a glorified form of automated copy and paste. We are moving information around from one place to another. In place of trucks, we use pipes to move our data. But it's transportation, not rocket science. So anything you can do with Remoting you can do with XML and LoadVars. Based on this argument, Remoting, XML, JSON, SOAP etc. all re-invent the wheel. But that's not true. Each has its specific strengths, weaknesses and use-cases. As does SWX.

Of course, it wouldn't be if in fact SWX gave some mighty good advantages over all the other solutions. To my knowledge, however, the only positive advantage to using SWX is the ability to use getBytesLoaded and getBytesTotal, which isn't available, in, say, Remoting.

SWX does have several mighty good advantages over all of the other solutions, above and beyond giving you the ability to display a determinate progress indicator as mentioned by Patrick. (If that was the only advantage, as much as I like determinate progress bars, I surely would not have invested as much time and effort into creating this as I have!)

Here are just a few advantages I can think of off the top of my head that SWX has over other methods:

• It's simpler to use.
• Data is deserialized twice only as opposed to four times.
• You don't have to learn a new API and can reuse your existing knowledge.
• It is useful in mobile applications with limited processing power
• The final downloadable bundles of SWX will contain everything you need to get up and running (you don't need to buy or download additional tools).

I want to elaborate on some of the above points, starting with the advantage of having two deserialization steps instead of four. To illustrate the point, I'll use the model that Patrick presents in his article on Clearing the FUD on amfphp’s speed versus JSON and XML (which is quite ironic since I'm clearing the FUD about SWX here!) In it, Patrick accurately states the following:

In most any RPC model, there are the following steps:

• Serialization of the request on the client-side
• Uploading of the message to the server
• Deserialization of the request on the server-side
• Dispatching on the server-side
• Serialization of the response on the server-side
• Downloading of the message to the client
• Deserialization of the message on the client-side

In most any RPC model, that is, except SWX. Let's look at how the above list looks in SWX.

Steps in SWX:

• Serialization of the request on the client-side
• Uploading of the message to the server
• Deserialization of the request on the server-side
• Dispatching on the server-side
• Serialization of the response on the server-side (i.e., assembly of the SWX SWF)
• Downloading of the message (i.e., SWF) to the client
• Deserialization of the message on the client-side

Straight off the bat, we remove the deserialization of the request on the server as the PHON object that is sent over is evaled, following security checks. The big advantage, however, is that we also remove the deserialization step on the client side because your Flash client is receiving a native SWF. There is no deserialization. The moment the SWF is loaded, it is ready for you to use. Just access the data structure and you're off.

Among other things, this means that there's no equivalent of the Flash Remoting Mystery Time. Once the SWF is loaded, the data structure is immediately available for you to use. Any sort of deserialization on the Flash client is going to use up processor cycles and SWX, by design, is the least processor intensive method possible since it is SWF bytecode and that's as native as you get in Flash.

Of course, time will tell how SWX compares with the other options in terms of performance, etc. but my gut tells me that a fully optimized SWX will compare very favorably indeed. It is, of course, not fair to compare it on these grounds currently as we are at a very early alpha release (think: one step removed from a proof of concept) and it is currently not optimized in any way. Most importantly, though, SWX is not in a pissing contest with other formats. It is one alternative, it is simple, and it has very valid use cases. In fact, one of the first things I am planning to do is to show people how SWX can be used alongside Amfphp and the single-package distributions of SWX will actually include Amfphp (I love Amfphp, Patrick, you know that!)

If you look at the sample code on the webpage . . . The first thing you'll notice is that dataHolder is a movie clip on Stage. That means that either you must place this empty movie clip on stage manually, or you have to use createEmptyMovieClip first. Of course, if you do the latter, you have to think about depths and whatnot. The second thing you'll notice is that there is an onEnterFrame. I thought the whole reason we dropped the use of onEnterFrame for polling a movie clip is that we had all sorts of crazy issues with that, including the difference between 0 and 4 loaded bytes.

I think Patrick is missing the point here. The key thing here is that Flash developers understand movie clips and know how to work with them. That sample code is purposefully simplistic. Of course, I will be releasing utility classes that abstract that away from you if you want to use a highler level API but the important design consideration here is that you *don't* have to learn a new API to use SWX. That's the beauty of it. You can use your existing Flash knowledge to easily create data-driven applications. And for those of you who *want* to have a higher-level interface, you'll have one. But it won't be forced on you.

Also, there is nothing wrong with using an enterFrame handler. The initial states (negative, etc.) tell you the various states that the load process is in and are actually very valuable for presenting accurate status information (is it waiting for data, receiving it, etc.) And, of course, you *can* display a determinate progress bar when you start loading the data. Apart from the usability advantages of doing so, it's just plain cool!

The third point is that the PHON serialization that is used relies on a prototype hack . . . So we hack toString in Array, Object and even (gasp!) String. I am not even to bother to expand as to the myriad ways in which I think this is a bad approach, but you can imagine the argument.

Ah, I just knew that people would get stuck at this point

Just to make it perfectly clear: The PHON serialization in SWX does *not* rely on a prototype hack. The current alpha of SWX happens to contain the automatic PHON serializer as the only option. I just didn't have the time to also release an alternative utility class that doesn't rely on extending the prototype object.

As I mentioned in my talk at the London Flash Platform User Group yesterday, this automatic workflow is very cool but you would be right to have concerns about object pollution if you use this method. Whether or not this will be a problem depends on your application. For simple apps, it should be fine. But if you're uncomfortable with it (or if you're using the toString() methods of the Object, Array or String classes for other purposes in your application), then you won't have to use the automatic PHON serialization method and you can use a manual method instead. That will involve one extra line of code:

org.swxformat.PHP.serialize(dataHolder.data);

To say that PHON serialization in SWX *relies* on a prototype hack is incorrect. The automatic PHON serialization workflow happens to be the only one I had time to implement in time for the initial launch. The manual method will follow very shortly (in fact, I think I'll get it into the next release.)

The fourth issue with this hack approach is that it is not going to work in AS3, either in Flex or in Flash 9. For one thing because you can't hack prototype, for another because the AS3 bytecode is different from the AS2 bytecode.

The current workaround to using SWX with AS3/Flex 2/Flash 9 is to use LocalConnection. In fact, this is what the SWX Analyzer (which is a Flex 2 application) does. However, this is far from ideal. I haven't even looked into how SWX may be implemented in AS3 at the moment but it is on the roadmap. Patrick is correct in that it will require a re-write of the PHP-based SWF assembler to use AS3 bytecode but there is nothing in it that is inherently impossible. And, as I outlined above, nothing in SWX relies on a "prototype hack".

SWX also had the disadvantage of being impossible to debug in Charles or ServiceCapture. Aral did a nice job with his Flex debugger, but why bother when you have native tools in your hands that do the job really really well.

I fail to see how having a free, built-in debugging tool can be perceived as a disadvantage. Surely, Patrick means that SWX has an *advantage* here!

When working with Flash Remoting, you need to purchase a separate tool to debug your application. Both Charles and ServiceCapture are commercial applications that you have to pay for and purchase separately.

Charles costs $50 for a single user license, and ServiceCapture costs $34.99.

SWX with the built-in SWX Analyzer, in contrast, costs $0.

(And it comes in the box so you get everything you need in one download.)

On a personal note, I found Charles to be highly annoying when I was evaluating it. Both the cumbersome interface and the constant "buy me now" nagging in the evaluation version. However, I do love ServiceCapture and I've bought multiple licenses for it over the years. It is far more than a remoting debugger (although it is wonderful for that purpose) and there is no reason why you cannot use ServiceCapture alongside SWX for its other features, such as the very useful network bandwidth throttling feature.

I could go on: SWX doesn't have anything for batched calls, or for typed objects, and I can hardly see how it could be put to use on a serious RIA.

It's true that SWX doesn't have batched calls, typed objects (yet) and that it may not be your first choice for a "serious RIA". But it's not for "serious RIAs". In fact, I'm fucking sick of "serious RIAs" and look forward to using SWX in fun projects that are in no way serious

You might argue that SWX is not meant to be used in RIAs, it's better for smaller projects, but that's why we have LoadVars and XML. Honestly I really don't see the point.

The whole idea behind SWX is that it is far easier to use than both LoadVars or XML that it is in a different class altogether when it comes to simplicity.

With LoadVars, you need to serialize your data into some custom format and then deserialize it yourself. This is a lot of useless plumbing code that no one should have to write. I had to write routines to deserialize complex arrays before but that was in Flash 5 when we had no other choice. Life is way too short for you to spend it writing this sort of useless code. All it does is bloat your application and take time away from actually creating your application and having fun with it.

XML. Where should I start? Have you ever worked with XML in Flash. It's not pretty is it? Until E4X in AS3, using XML in Flash was akin to pulling teeth without anesthetic. Another helping of firstChild, lastChild, bastardChild anyone? No, I didn't think so. Of course some people used helper classes that mixed in object-style look-up functionality to XML structures but how many people, really, even knew about these. In my experience, very few. Many people I see end up converting the XML structure into an object structure and then using that. Umm, but that's exactly what you get with SWX without doing any work whatsoever -- a native Flash object, as complex as you like, delivered to you piping hot in a tasty SWF shell!

SWX offers a huge advantage over both LoadVars and XML: simplicity. And the fact that you don't have to worry about serialization and deserialization.

In conclusion, I just want to state that SWX definitely has valid use cases: They're just not the same as those for Amfphp.

SWX, first and foremost, is built with an overriding focus on simplicity. It may be 2007 but, unfortunately, we still don't have an intuitively simple way to create data-driven apps in Flash. The closest thing we have is remoting (and I'd argue, Amfphp is the simplest one to get up and running with) but too many developers are still afraid to dive into the depths of even that. With SWX, you don't need to know anything new to get the advantages of Remoting without the extra hassle.

If you're building a mashup, or a FlashLite 2 application, take a look at SWX. If you want to have fun with Flash and create data-driven applications without the hassle of learning new APIs and downloading extra classes and all that unnecessary stuff, then SWX may be the right choice for you.

Like anything new technology, it will take a little time for it to mature. As I've mentioned in several places, it is currently not optimized in any way so this really isn't the time to be running benchmarks on it with other, mature technologies that have been around for ages.

SWX is growing and changing daily and I hope you will be part of its story. Pretty soon it will be up and running and getting up to all sorts of mischief and then we'll really start having some fun!

Don't forget that SWX is a tiny, new-born baby right now. It just opened its eyes to the world yesterday. Let's give it a chance instead of trying to strangle it in its cradle.