Preloading

First of all, components require library symbols to be exported for ActionScript. For them to be preloaded properly, you’d need to go through the hassle of dragging the component onto the stage in a keyframe following a preloader, then individually disable “Export in first frame” for each symbol. Depending on the number of components and their level of complexity, not doing such would result in a bloated first frame with a hefty file size. Thus making any preloader innaccurate.

With a normal class, it can be placed on any frame and are preloaded properly as a result. Of course if the class references library instances, they’ll have to be set up using the technique mentioned above. But the beauty of a class is that unless you’re working with images, no library instances are required at all. Everything can be created, drawn and animated with 100% script. Additionally, the classes themselves can be contained in external files and included (via #include) for compiling a SWF.

Speed

While a component is just a variant of a normal class, they provide less performance. In a simple benchmark test, a normal class was compared to a component containing the exact same routine. The machine tested on was an Intel® Celeron 500 (representing an average clock speed of the Internet’s population). The class was averaged at 15,554ms while the component averaged at 15,774ms. Not a very big difference with a single for() loop. However, with a few simultaneous frame loops running their own routines, components could fall further behind.

Here is the component’s code:

#initclip
 
function testComponent()
{
	this.init();
}
 
testComponent.prototype = new MovieClip();
 
testComponent.prototype.init = function()
{
	for (var i=0; i<5000; i++)
	{
		this.createEmptyMovieClip("mc"+i, i);
	}
}
 
Object.registerClass("linkageID", testComponent);
 
#endinitclip

Here is the class’ code:

function testClass(target)
{
	this.target = target;
	this.init();
}
 
testClass.prototype.init = function()
{
	for (var i=0; i<5000; i++)
	{
		this.target.createEmptyMovieClip("mc"+i, i);
	}
}

Sloppy

Because of the target audience, FUI Component code quality seems to have been ignored. They have inefficient code and are spread out across dozens of MovieClips. That rules out the possibility of making any changes in a reasonable amount of time.

Bulky

Seeing that all objects used in the FUI Components must all be editable by a designer through the Flash MX user interface, they are forced into being stored in the library. Depending on the component, the library for a single component can rise to nearly 100 MovieClips.

File Size

Components are too big for their purpose. Below is a list of the FUI Components and their respective (compressed) file sizes.

Granted that certain components share other components and library objects. Therefore if all components were placed in a single movie, the file size would not be 68 KB. Although shared objects open up another issue.

Shared Library Objects

Since components share objects to minimize file size, we run into issues when trying to differentiate design elements between two components. That can be problematic when the very object you are trying to make unique is shared. As a result, making a visual change to one makes the same change to another component. Working around this involves duplicating the MovieClip and changing its library name and linkage identifier (if applicable).