Joeflash’s Enigmacopaedia


Announcing the WTFPL License

Posted in Geekness by Joeflash on the February 22nd, 2008

I was just reading Doug McCune’s blog where he discusses FlexSpy, which is covered under the Do What The Fuck You Want To Public License.

HA! I love it! That’s really what I call open source software, LOL!

Flex Websites are a Round Peg in a Square Hole (and Why Flash is Just As Good as Flex)

Posted in Flash, Flex, Workflow by Joeflash on the February 18th, 2008

As both a Flash and a Flex developer, I can say that designing and developing a highly visual experience such as a promotional website for an automaker like this recent Volkswagen site seems to me like putting a round peg in a square hole.

One of the main roadblocks to building highly visual experiences in Flex, as Yacov Fain mentions, is that performance, particularly load times, can suffer dramatically.

Up until recently this was thought to be due primarily to the weight of the Flex framework itself, adding at least another 150-250K onto your SWF file size. Thinking that the weight of the Flex framework is the only performance bottleneck in this regard, people are looking to have Flex do what Flash does — “Now that we have persistent framework caching, we don’t have to worry about SWF filesize anymore, right?” Wrong.

This assumption highlights a growing attitude that Flash-built applications are somehow “less sophisticated or evolved,” which tends to result in the shoehorning of all Flash Platform Development though the Flex framework. Wrong again.

Just because an application does not use the Flex framework or MXML, does not mean developers need to resort to the pathetically inadequate Flash IDE code editor. One can very easily lay out the application and its animations in Flash, use Flex Builder, FDT or FlashDevelop as the coding environment, and back to Flash for compilation.

As Flex developers we are spoiled. We have layout managers, GUI interaction managers, a component framework and a whole host of RPC communications tools that really make our lives a whole lot easier, to name a few. But that ease of use comes at a cost, and it isn’t just filesize. It comes with a programming mindset that encourages one to find the solution to a problem in the Flex framework first, and in the core ActionScript API second. This can lead to over-architecting simple applications.

Flash projects which enable more visually-engaging than data-oriented experiences are usually built under tighter deadlines which don’t lend themselves well to planning of architectural frameworks. But this doesn’t mean that they are not sophisticated. You can’t possibly look at the class structure of an open source library like Papervision 3D and say it’s unsophisticated. And yet there is a perception that projects of a certain complexity need to be developed in Flex. Which is simply not true.

As a Flash ActionScript 2 developer, before AS3 came out, I remember we had to build almost everything from scratch, as compared to the toolsets we have in Flex. Macromedia had a component architecture and data components, but to me they seemed bloated and sometimes even buggy compared to what could be done from a custom implementation. Every Flash developer had their own personal class library built up over the duration of their career, cobbled together from bits of open source code, personal experiments, and blood sweat and tears pored over late night projects. And the measure of how good you were as a Flash developer was not how many blog posts per day or twitters per minute you published, but the strength of your personal coding library, giving you the ability to whip out a manager or a utility class to suit almost any need. Every Flash development firm also had their own custom class libraries, sometimes jealously guarded under pain of legal action. A few brave souls and companies even shared their discoveries and their code base with the rest of the community, and a few key open source libraries were available to do common tasks like bitmap effects, tweening and data communications. The trend continues to this day.

As an aside, having to maintain your own private coding libraries as a matter of survival, and learning to adapt to any possible combination of coding techniques of other developers, from the ridiculously procedural spaghetti code to the rube-goldberg-esque constructs of some over-zealous patterns fanatics, really forces you to grow as a programmer. So I don’t care what anyone says: Flex developers are not necessarily better programmers just because they know Java or can use J2EE patterns which have never seen the light of day in a SWF before Flex. Flash developers who have been in the trenches and sweat blood to help the Flash Platform evolve into the ActionScript 3.0 powerhouse of today are just as good. So don’t give me any of this Flash versus Flex crap. Just Stop it. Flash dudes, you’re just as good as the Flex guys. And Java-come-lately Flex developers, stop looking down your nose at the Flash guys. As a Flash-turned-Flex developer, I have a great respect for both kinds of developers.
Can’t we all just get along?

(and now, back to our regularly scheduled blog post)

The problem with the coding library diversity present in ActionScript 2.0 development was that, as a Flash developer, very rarely would I come to a Flash project and see the same coding libraries, or even coding methodologies, used to build a project. There were virtually no standards IMO apart from a few well-used Macromedia components and popular open source class libraries like Fuse or MCTween. So literally half the Flash projects I worked on involved fixing or updating someone else’s code. This is where Flex shines as opposed to Flash, I think, because it gives the developer the safety of a standard toolset and class library to work with.

But today in the world of Flash development, there is a much richer base of open source libraries available for the ActionScript 3 developer, thanks in part to the growing popularity of the Flex platform, and the rest thanks to the increased power of the new ActionScript 3.0 API and virtual machine. Some that come to mind are Sandy, PaperVision3D, Pure MVC, Alive PDF and Degrafa.

But there is still the perception remaining from the ActionScript 2.0 days that coding standards and libraries are not as abundant for Flash/ActionScript 3.0 projects as opposed to Flex projects. Again this is simply not true.

Working with the Flash IDE as the “layout editor and compiler,” along with one’s choice of coding editor, assumes a certain coding methodology, and that is that most of the functionality will be done from scratch (i.e. build on the core AS3 API), or rely on a patchwork of custom and/or open source libraries, including the lightweight CS3 components.

In Flex, one also assumes a certain coding methodology. This means working with the Flex Framework first, and getting down and dirty with the AS3 API second. In the case of loaders, this means that most Flex applications rely on the creation policies of ViewStacks and States, and the default behaviours of Module loaders or the Loader class for external assets.

The first and most important rule of web usability for RIAs, in my book, is that the loader is the very first thing a user will see, therefore it must be the most optimized and streamlined part of the entire application. In the words of Chris Tucker, a loader must Pop! Pop! Pop! :)

The problem is that, for all the ease of use and capability of the Flex framework, the loading of assets and modules leaves much to be desired. I have yet to see a loader in Flex which utilizes load queue prioritization, an essential feature to any intelligent loading strategy. Whereas loading queue classes have existed in the Flash coding world since 2003 and earlier.

By using Flex, one adds the architectural weight necessary to build a solid application, with none of the loading intelligence. And this can cause critical performance issues.

Now, I am not saying that all these assumptions were present in the creation of the WV website, and in all fairness they did a fantastic job, but was Flex really the appropriate thing to use? Perhaps.

When you’re thinking about designing a website with a highly visual experience, think of developing it without the Flex framework first. In this I agree entirely with Ryan Stewart’s sentiments. And if you find you need the data components, or you absolutely need to have certain utility classes, or part of the experience is very component driven, then think about using Flex. But don’t assume you automatically need Flex simply because you’re publishing for the Flash runtime, because that assumption may cost you in performance, and ultimately, in eyeballs to your site, as it no doubt will for the newest poster child for Flex website development.

A Plea To Adobe: Open Source The v2 Architecture!

Posted in Flash, ActionScript 2.0, ActionScript 3.0, Flex, Adobe, Components, Macromedia by Joeflash on the February 6th, 2008

I always wondered if this day would come. Now, hopefully, it just might.

Following is a reply to a post on the Open at Adobe blog entitled Is dead code ever a good line?

If someone cares that the program continues, and is will to commit their resources, why shouldn’t the code be released? If the code is good enough, and doesn’t include other properties, why not release it? If a community is available to control and govern it, why not? If the product was good enough to build a market on its own right, why should we believe it can’t continue?

So, to both of my readers , what do you think? Should dead code be released? Are there examples of it working, or failing? And what do you think are the steps that would help us decide?

I knew exactly what I would write. The same thing that’s been on my mind since I started doing serious actionscript development back in 2002, and the one reason I switched to being a Flex developer:

I think the answer is hell yes, particularly in Adobe’s case.

I’m going to take a moment and gripe about a typical situation which underscores the importance of this point.

I can think of a few situations in the past where open sourcing the code for the Macromedia Flash v2 (i.e. MX 2004) components would have saved a lot of developers, including myself, from a lot of pain and grief. The fact that Macromedia had abandoned the v2 component code back in 2005 (maybe earlier?), and yet would not open source it, left the Flash development community with little alternative than to use 3rd party component frameworks, because patching up holes in the component framework was simply not a legal option. I remember back when the v2 components were released, a few bright stars in the community found fixes and patches for them, but were unable to distribute this code because of the closed policies surrounding these components. This made a lot of people extremely unhappy.

None of the alternate component sets were satisfactory, because none of them were as complete or feature-rich as the v2 component set. And so we waited for someone, anyone to step up to the plate. We waited for MCOM to complete its vaunted component set, which would supposedly save us all from the bugginess of the v2 architecture. But by the time they were released, Flex 2 and AS3 was just around the corner — why bother?

I say this not to gripe for the sake of it, the past is the past, but to emphasize that Adobe should never, ever, EVER repeat this mistake ever again. This one goof nearly killed component-based development for the Flash Platform back in the day, only to be saved at the 11th hour by Flex 2 and AS3. So obviously MacromediaAdobe has learned since then.

Many of us cheered a massive hurah when Adobe announced plans to open source the Flex SDK. Alas, we were now saved from a fate worse than death by having to use closed source components. To the Flash developers in the trenches, the ones who sweat blood and tears to make Flash live up to its potential, we are glad not to have to hack our way through closed code with a chainsaw just to build good apps. Thank you for opening up, and later open sourcing the Flex SDK.

But lot of developers working with legacy AS2 code are still not happy. I’ve even seen development teams violating the EULA and decompiling the entire component architecture, just so they can fix a few things and put out a stable version of their application. So it would be a bit of an understatement to say that it would be a saving grace for them, or if nothing else offer some sort of closure on the issue for the rest of us who have moved on, if the MacromediaAdobe Flash v2 component set were open sourced, at long last. Better late than never.

And while you’re at it, Flex 1 & 1.5 and all the cool MM Dev Kit components that rarely saw the light of day outside of Flex 1-land.

Adobe, if you really want to embrace the open source movement, you need to do this, for your loyal community of Flash developers who have stood by the technology through the years and helped nurture it to what it is today.

Sincerely,

A plea from a passionate Flash and Flex Developer.

Everyone who feels the same way that I do, lend your voice here or on the Open at Adobe blog, and maybe we can finally get that train into the station at long last.