Aral Balkan

Patrick Mineault maintains, after my post SWX: A good idea that SWX is still a bad idea. I still disagree. This is going to be my last post on the subject because it appears that we are just going to have to agree to disagree on this one and I would rather spend my time improving SWX and doing fun stuff with Flash rather than justifying the existence of my latest open source project.

In his post, Patrick states:

SWX is quite clever, but the implementation is not going to yield any net benefits for the community

I disagree strongly. SWX is quite clever thanks, but it wasn't merely an intellectual exercise for me. It was born out of the very real need that I felt for a simpler way to create data-driven applications in Flash. This is a real need that I have and I am sure that others share this need. As such, by fulfilling this need, SWX *is* going to benefit the community. For other benefits of SWX, see my previous post (SWX: A good idea) in which I outline the advantages of SWX on a more technical level.

As for my statement that SWX is a hack, I stand by that, and I think other people agree.

Patrick is right. SWX *is* a hack and I thank him for the compliment.

So what is a hack, actually?

According to the Merriam-Webster Online Dictionary, a hack is "a usually creative solution to a computer hardware or programming problem or limitation". Yes, SWX is definitely a hack.

And I hope it gets Flash developers to hack -- "to write computer programs for enjoyment" as the word means as a verb -- and to create more hacks.

SWX is meant to make it easier for you to hack even if you don't have a degree in computer science. I thought that was the whole idea behind Flash in the first place! Where did we lose our way?

Patrick mentions that there are other people who agree with him. The "other people" currently appears to be comprised of a one Theo Hultberg who states in a blog post titled On SWX that SWX "is not worth a second look". Fair enough -- we are all entitled to our opinions and the number of looks we give things -- but then he proceeds to demonstrate a lack of understanding of how SWX works and simultaneously questions my word by stating:

partly because of the questionable implementation of the client side deserializer (which may or may not be just a temporary version")

If Mr. Hultberg had actually read the documentation for SWX -- instead of hastily shutting his eyes to avoid a second look at something new and different -- he most likely would have known that one of the key features of SWX is that there is no client-side *deserializer* as your data loads in a SWF so what he meant to say was *serializer* in the quote above.

I have already promised that there will be a manual serializer and Mr. Hultberg has no basis to question my integrity by stating that I "may or may not" deliver on this.

Unfortunately, it gets worse from there as Mr. Hultberg succeeds in the questionably-enviable accomplishment of managing to personally insult me *and* question my competence as a programmer in a single sentence:

I wouldn’t hire people who wrote code that looked like that, and I sure wouldn’t use their frameworks.

I hate to say it but it appears that Ludditism is alive and well and living in the Flash community.

Making a public comment that contains such a generalization can only make you appear like a fool.

Mr. Hultberg, you couldn't *afford* to hire me in your wildest fantasies, much less reality, so the first part of your statement is a moot point. Secondly, your statement assumes that there is one use (and one use only) for Flash and that is to build large enterprise Rich Internet Applications. That couldn't be further from the truth if it had been catapulted to the end of the galaxy by an electron accelerator. Unfortunately, however, it does show us the ugly face of elitism that I myself have been guilty of perpetuating to a certain degree without ever meaning to.

Before I go into detail on this, let's just state for the record a fact that bears repeating:

You do not need to be a computer scientist to make amazing Flash stuff and to have fun with Flash.

And, furthermore, there's nothing wrong with having *fun* with Flash. And there's nothing wrong with hacking something together quickly and experimenting.

Do not let the fear of writing "bad code" or not architecting something "perfectly" ever stop you from doing things. There is no such thing as "perfect" in what we do. It's all part of a learning process and you have to be prepared (or even look forward to) building things, throwing them away and starting again. Knowledge of design patterns and good practices is very important when working on large applications that have long lifetimes and are maintained on by multiple developers. But that's not the only use-case for Flash (in fact, I'd argue that that's not even the main use-case for Flash.)

If anyone tells you the opposite, you should be well within your rights to tell them to kindly remove the baseball ball that they must have accidently sat on because it can't be good for their health and is probably going to make it uncomfortable for them to read the thick Java manual they carry around to hide their insecurities.

I love design patterns and I am genuinely passionate about application architecture and development processes. In fact, I consult about this regularly with enterprises of all sizes -- it's what I do for a living. But I am aware that Flash has a wide range of applicability -- everything from linear animations to banner ads to games -- and that preaching a One-Size-Fits-All approach based on the merits of a single workflow and methodology above all others is a fatally-flawed, fundamentalist position to defend.

Looking at Mr. Hultberg's About page, you see that in the past he was "a Java web application developer" who "studied software engineering". It goes on:

My aim is to introduce proper system architecture and object oriented design to the ActionScript community, something that I find is lacking.

Let me tell you who Mr. Hultberg is with that statement: He is the white man come to educate the natives with the Word of the Lord.

Hallelujah, brother -- thou shalt be saved from the sins of Flash by the cleansing light of Java!

You see, Flash developers are an ignorant bunch who live simple lives. They don't know about design patterns and wouldn't know a Mixin from a Front Controller if one was to hit them in the face on a windy afternoon. In fact, it's a miracle they ever get anything done. They must be saved from themselves. But don't worry, because *civilization* has come to the Flash platform as Mr. Hultberg and his merry band of Evangelical Java bishops bring us the truth of The Light.

WTF?

Who died and elected you Pope, Mr. Hultberg?

(I have to point out here that I have nothing against Java developers in general -- or any other developers, really. I've developed in Java myself and I've used and continue to use a variety of programming languages and technologies -- each of which has its own use cases, advantages and disadvantages. It is the elitist attitude I am describing here that certain developers have that I find harmful.)

I have a feeling that people like Mr. Hultberg would love to see Flash become Java because that's what they know. Sometimes when you only have a hammer, everything looks like a nail. But Flash is not Java. It has its own essence and that essence is beautiful. Instead of trying to repress its true nature, we should find creative ways of letting it shine. I've seen too many Flash projects jeopardized because important design decisions were made by Java developers. I've seen frameworks created that try to mimic or recreate Java in Flash. Heavy, scary frameworks that scare away Flash developers. Unfortunately, many Flash developers are intimidated by these people who pass themselves off as "real programmers" because they have server-side programming expertise.

Flash, however, is not a server-side technology and your server-side development knowledge will not transfer to it verbatim. In fact, the actual complexity of server-side systems, for 90% of what makes up a web application, is much lower than the complexity of the client.

On the server side, you build interfaces that talk to other computers. They talk in pre-determined, unchanging protocols. Things are predictable, you can unit test them to death. On the client side, however, you are building interfaces that talk to a human: An unpredictable, complex creature that may just be scratching his balls with one hand as he uses your lovingly crafted interface with the other while simultaneously devoting 73% of his attention to Carmen Electra's rack in the trailer of I Want Candy that's blaring on his TV screen. (In no way is this based on personal experience -- I don't even watch TV!)

Is it any surprise that building usable user interfaces contains far greater inherent complexity than getting two computers (or two computer programs) to talk? Is it any surprise that, given the attitudes of certain "real programmers", the complexity, effort and expertise involved in creating user interfaces is underestimated time and again? Is it any surprise, then, that we have such a high failure rate for projects in our industry?

Flash is a client-side technology and there is a wealth of specialized client-side knowledge that Flash developers have that server-side developers do not. It is often the case that Flash developers will respect the work that server-side programmers perform but it is rare for that respect to be mutual. And the only reason for it not to be is because of a certain elitist superiority complex in these people, coupled with a dangerous ignorance of Flash.

It may surprise Mr. Hultberg to know that I've built my share of large enterprise RIAs. I started doing so in Flash 5 when Branden Hall, Keenan Keeling, Charlie Cordova and myself built the Flash front-end to a virtual school. We had to write our own event dispatching systems, components, etc. -- all things that were later added natively to Flash MX. I've been around, Mr. Hultberg and something tells me I've been doing Flash for a little longer than you have, so read on.

With each version of Flash, we have been moving further and further away from the simplicity that made Flash such an approachable tool. The Flash IDE was never meant to be a tool for building enterprise applications. Unfortunately, before Flex, it was the only major IDE available for the Flash Platform and Macromedia tried to make it do everything. In the process, it began to struggle to do anything particularly well. Animators were left behind (I know animators that still use Flash 5 because it supports their workflow better), designers were snubbed (do you remember the removal of Script Assist in Flash MX 2004) and all for what? So we could appear more "grown up". And what did Macromedia take as a grown up role model? Nothing if not the heaviest, most bulky, over-hyped and under-delivering programming language I know: Java.

(And by I know, I really do mean I know Java and I have developed server-side applications using J2EE.)

Yes, they tried to make Flash look more like Java to attract Java developers and it worked. Many prominent voices were quick to declare that with ActionScript 2, ActionScript had finally become a "true" object-oriented programming language. That's the biggest crock of uninformed bullshit ever. Classes are syntactic sugar in ActionScript 2 -- everything gets pre-compiled down to ActionScript 1. ActionScript is a *prototype-based* language and has always been object-oriented. You do not need to look like Java to be object-oriented. You do not need the compile-time concept of *classes* to be *object*-oriented. In fact, you could argue (and rightly so) that a language that only has objects (not classes) is *more* object-oriented.

In fact, this misconception continues today with ActionScript 3. Java developers are sometimes quick to hold AS3 to their chests as their own. AS3 couldn't be less like Java if Java lost 400lbs in 30 days by eating nothing by Subway sandwiches. AS3 is an optionally-typed *dynamic language*. In essence, it is far closer to Python or Ruby than Java. Don't let the syntax fool you.

Thankfully, the release of Flex meant that Flash could drop the burden of being the primary RIA tool for the Flash Platform (alongside all its other roles.) Starting with Flash 8, we have begun to see it focus more on some of the core areas that had fallen into neglect and I hope that this trend continues in future releases as well.

You know what the ironic thing is? I have spent the last three or four years talking about best practices, pattern-based development and development processes at conferences around the world. The framework I wrote that Mr. Hultberg says he wouldn't use (based not on its own merits but on the sample code he skimmed for SWX) is Arp and it is being used around the world by people whom I would consider to be cornerstones of the Flash community -- some of the best developers I know. And I do believe that an understanding of design patterns and best practices is essential when working in teams and on large projects. But they can also be harmful if not presented correctly. Let me tell you how:

As I mentioned earlier, I have been giving talks about pattern-based development, best practices, and agile development processes for quite a few years now. Generally, I feel that these talks have been very beneficial for my audiences. I have tried to expose them to concepts and workflows that they may not have heard before and these will no doubt help them when working in groups and on large projects. However, what I failed to do in these talks, which I now wish I had, was to wrap everything up in a huge caveat: Knowing all of this is great but don't ever let it stifle your creativity.

I have seen developers stuck in front of their computers, unable to start working on a project because they are afraid to make a mistake. Because they have heard that there are better ways of architecting things, "best ways" perhaps even, and they are not sure if what they are about to write is going to be "correct".

I was devastated when I first saw this (and I've seen it many times, at different levels, in many different developers since). There I was, talking about agile development and pattern-based programming that was supposed to make it easier for multiple developers to work together, communicate and talk about code. There I was, trying to spread best practices that were supposed to make developer's lives easier. All positive, dynamic things that were meant to improve the daily welfare (and happiness) of developers. And there I was, seeing that it could sometimes have the opposite effect: Stifling creativity, creating fear and uncertainty, leading developers to think along the lines of "right" and "wrong" rather than simply creating, experimenting and having fun.

(There is never a "wrong" in development -- it's a continuous process of learning. There are no bugs, only feature requests.)

So, yes, patterns, knowledge of good practices and agile development processes are important but the most important thing, above all of these, is to not be afraid.

Don't be afraid to create, experiment and make mistakes. Remember, there are no mistakes -- it's all a process of discovery. Go ahead: write sloppy code, then throw it away and write it better. Throw stuff on the timeline, try different ideas, break things, then put them back together again. You can always tidy things up later. Don't let fear of imperfection lead you to inaction. There is no such thing as perfect. Do something, anything and then evolve it. Don't think too much about it or you may end up only thinking about it. Do, make, share, evolve!

Above all, and this is the really important bit: have fun! It's OK to have fun! And don't let anyone tell you otherwise.

I hope SWX helps you have more fun with Flash. That's what it's about. And that's why it's necessary.