An interesting conversation has been happening for a while over on flexcoders. The conversation started with a simple question… Whether or not using the Flex framework is a good idea when developing widgets.
First a little background about me.
A little while back, I worked for a small startup named Snapvine. Snapvine currently has many widget offerings, one of which still gets loaded millions of times each week. These widgets are deployed across hundreds of social networks (who knew there were so many). As the lone flash developer in the company, it was my job was to create and maintain all of these widgets.
The great thing about Snapvine was that I was surrounded by brilliant people, we discussed the Flex framework in extraordinary detail, weighing the pros and cons of using such a framework in our widgets.
So that brings me to the whole point of this blog post… pros and cons for building widgets for the Adobe Flash Platform using Flex.
My experience in widget development was mostly focused on development for social networks, so I might say some things that may not apply to other types of widget development.
– Pros –
Flex does a lot of the work for you
Flex does so much of the heavy lifting for us. If you’re ever bored, skim through the Flex documentation. It’s not uncommon for me to find things within the framework I didn’t know existed.
Also, If you haven’t already done so, I highly recommend picking up the O’Reilly Flex 3 Cookbook, or thumbing through it at your local bookstore. I’ve found some really great things in there that I didn’t know about the Flex Framework.
Flex allows quicker development time because there is less code YOU have to write.
Once again, Thanks Adobe… for doing my work for me.
RSLs decrease frequent loading time
The use of Adobe’s Runtime Shared Library significantly reduces multiple loads of your widget. This is because parts of the Flex Framework become cached inside the Flash Player itself. One of the big benefits of the framework RSLs is that not only your widget benefit from them. The framework is cached the first time ANY Flex content, on any site, using framework RSLs is loaded.
One caveat to Runtime Shared Libraries is that you have to configure your widget to utilize them during compilation. They don’t just get used magically. This also means that when you deploy the widget on your web server, you need to also upload and distribute the RSLs.
So if a user visits Picnik, which uses the Flex framework RSLs. Then the user visits a myspace profile page with your widget on it, they wouldn’t download the framework RSLs again (if you and picnik.com are using the same version of the SDK).
Myspace wants users to use Flash Player 9 and above
A while back Adobe and MySpace scratched each other’s back a little bit. Adobe added support for MySpace to disallow navigation events from flash widgets (allowNetworking=”internal”), and MySpace in turn highly recommend users to upgrade to Flash Player 9 (I’m pretty sure they also did this for the video support in Flash Player 9). Myspace did this by prompting users to update their Flash Player if they detected version 8 and below.
That’s a BIG pro for us widget developers, because that means the majority of our widget market is using a player with loads of the features we know and love. At the time of this writing, I’m unsure if MySpace is pushing Flash Player 10, I haven’t noticed it yet.
I’m currently writing this post aboard an airplane at 33,000 feet. Would the person who keeps passing gas, please knock it off, this is an enclosed air system for heaven’s sake.
– Cons –
Flex is huge, comparatively
300 KB is still too big for dial-up. Many people argue that if people are using MySpace on dial-up, that they’re used to slow loading times. It’s not uncommon for a MySpace profile to be littered with hundreds of 100 KB photos, music, etc… However, that brings me to one of my main points.
By keeping your widget small, It’s more than likely going to load prior to other things on the profile. This is key for getting your brand out there. In Snapvine’s case, this meant that before pictures of friends, before the music players, before the slideshows… Snapvine’s logo was spinning on the page.
Bandwidth is expensive
If your goal if for your widget to go viral, bandwidth is something you should consider. It is bandwidth which drives how much money you are going to spend.
This calculator estimates how much it would cost if you were hosting your widget on Amazon S3 (US).
If you want a direct link… Widget Bandwidth Calculator
If you are curious, you can view the source.
Why is this a con? Using the Flex framework bloats a swf’s file size, and ultimately costs you more money, even if you are using Runtime Shared Libraries.
A simple application which is JUST a combo box, is still 56 KB, even when using Runtime Shared Libraries.
Flex was built primarily for Enterprise Development
This means that lots of the components within the framework, are pretty much useless within widgets. For example, using a datagrid to show massive amounts of data… not really a good use for a widget.
Remember, we’re talking about widgets, not about widgapplications (my spellcheck doesn’t like that word). Most widgets are fairly simple apps. Examples – a music player, slideshow, awesome video slideshow, small game, etc…
Keep your widget fairly simple, if it begins to become too complex, you should probably ask yourself, “Should I be building a 3rd party application (OpenSocial or FBML) instead of a widget?”
It’s hard to selectively use pieces of Flex
I’m not going to say that it is impossible, but loads of classes in the Flex framework are dependent upon each other. Which means that if you’re going to use one Flex class within your widget, it will import ALL of it’s dependencies, whether you use them or not.
– Nate’s opinion –
If I’m building a widget whose soul purpose is to go viral and be loaded millions of times a day, I’m going to write it in straight ActionScript.
Sure, it will take a bit more time, but in the end I’ll save money, have more granular control over my widget, and feel good about myself.