Some devs coming from other languages feel like they can only build a few large, spaghetti JavaScript files for their app. I tend to think this may be caused by three reasons:

• That’s the way JavaScript has been done in the past.
• Loading many JavaScript files requires many HTTP requests resulting in longer load times.
• Dependency management is hard in JavaScript.

Don’t stoop to these excuses. We can do better than that and today there are fantastic libraries and standards that can help us out. However, let’s see what the above problems mean.

That’s the way JavaScript has been done in the past. Unfortunately, that’s true. For years many teams developed within one or two large JavaScript files containing thousands of lines of code. It goes without saying that maintainability was very poor. It’s difficult to wrap our minds and IDEs around thousand of lines of interoperating code and also a nightmare with version control in a team environment. I do believe this is a large contributor to why JavaScript has had a bad wrap in the dev community for so long.

Loading many JavaScript files requires many HTTP requests resulting in longer load times. It’s true. Each time a JavaScript file is loaded it requires the overhead of an inidiviual HTTP request and, unfortunately, if you list many script tags in your page the files will load in sequence, not in parallel.

Dependency management is hard in JavaScript. By splitting code out into many files, you must keep track of which files depend on each other and make sure they’re loaded in the right order. This can be a messy long list and easy to mess up later down the line. For example:

<script src="script3.js"></script>
<script src="script1.js"></script>
<script src="script13.js"></script>
<script src="script7.js"></script>
<script src="script6.js"></script>
<script src="script12.js"></script>
<script src="script4.js"></script>
<script src="script11.js"></script>
<script src="script5.js"></script>
<script src="script9.js"></script>
<script src="script8.js"></script>
<script src="script10.js"></script>
<script src="script2.js"></script>

This is troubling enough on a single-man project but even more-so within a team.

Modules

Let’s get nostalgic for a moment. A few years back, using JavaScript on the server-side was just starting to get hot. Server-side libraries and JavaScript engines were being deployed but they didn’t have a good, standard API for working with one another and defining dependencies. Getting one library to work with another required some finagling and it was obvious that if JavaScript were to scale it would need some common APIs.

In January 2009, Kevin Dangoor wrote a blog post titled What Server Side JavaScript Needs outlining just that–what server-side JavaScript needed. The list included:

• Cross-interpreter standard library
• Standard interfaces
• Standard way to include other modules
• Package up code for deployment and distribution
• Install packages and their dependencies
• Package repository

As a means to fulfill these needs, he created a Google group named ServerJS where like-minded folk could collaborate. Soon enough, the group realized that many of these goals weren’t necessarily limited to the server-side and renamed the group to CommonJS.

One of the standards that CommonJS worked toward was that of a module. A module is a contained piece of code (How’s that for vague?) that defines not only that it is a module itself but which other modules it depends on to correctly function. When calling for module B, module B might call for module G and module M, which might call for modules D and W. By having a module standard, dependency management becomes easier. Rather than keeping some sort of implicit master list that must be kept in order, each module just defines its own dependencies and that mapping can be used to determine required resources and the order in which they must be loaded.

AMD

The module concept was great for server-side development as it addressed how to synchronously load modules based on dependency definitions, but the JavaScript devs on the browser-side got a bit jealous. Why should such awesomeness be confined to the server? Sure, module loading needs to be done asynchronously in the browser, but that didn’t mean the concept of modules and dependency definitions couldn’t be applied.

The Asynchronous Module Definition, or AMD, was born for this purpose. It takes the module and dependency definition API from the server-side and applies it to the asynchronous paradigm of the browser.

RequireJS

So what does RequireJS have to do with this? Well, even though we can define our modules and their dependencies with AMD, we need something smart that can take this dependency map, load the modules, and execute the modules in order. That’s the role RequireJS plays. Both RequireJS and AMD are open source, popular, and well-curated by James Burke.

Defining and Requesting Modules

At this point let’s jump straight into some code and hopefully the concepts will start to solidify. Almost always, a module is defined within a single file and, vice-versa, a single file only contains a single module definition. Defining a module, at its core, is as simple as the code below. Let’s assume it’s within a file called book.js.

define({
    title: "My Sister's Keeper",
    publisher: "Atria"
});

We now have a book module. define() is a RequireJS function. When we call it, we’re essentially saying, “Register what I’m passing you as a module.” By default, RequireJS assumes the module name is the file path following the base url (don’t get your panties in a twist–we’ll get to that in a minute) excluding the extension. In this case, that means that “book” is our assumed module name. When other code asks RequireJS for the “book” module, RequireJS will return the object we just defined above. Now let’s make a “bookshelf” module in a new file named bookshelf.js and see how we can request the book module into it.

define([
	'book'
], function(book) {
	return {
		listBook: function() {
			alert(book.title);
		}
	};
});

Notice this one’s a bit different than the book module. The book module didn’t have any dependencies so it was a bit simpler. Here, we’re defining an array of dependencies for our bookshelf–in this case, book. The second parameter is a callback function. If book.js hasn’t been loaded into the app yet, RequireJS will go fetch it from the server. Once book.js is loaded and the book module is registered, RequireJS will execute our callback function and pass the module (the book object we defined previously) in as a parameter. The argument name isn’t technically significant. We could have just as easily said function(a1337Book) or used whatever name we wanted. In this case, it makes sense to have our argument name match the module name. Whatever object we return from this callback function will be registered with RequireJS as the bookshelf module. In our case, it’s an object with an listBook() method that alerts the book’s title.

RequireJS tries to be as efficient as possible when loading multiple modules. For example, if multiple dependencies are listed, RequireJS will load all the dependencies as fast as possible in parallel.

App Setup

So…how do we get this party started? Let’s first start by getting our html page set up. Here’s how it looks:

<!DOCTYPE html>
<html>
	<head>
		<title>RequireJS Example</title>
		<script data-main="js/main" src="js/libs/require.js"></script>
	</head>
	<body/>
</html>

Quite literally, you can build a large application without adding anything else to your html file just by manipulating the body’s content using JavaScript and loading html snippets/templates using Require. We’ll get there. For now, take notice that there’s a data-main attribute. This tells RequireJS where our bootstrap file is–in our case, it’s main.js that lives under a js directory (it assumes main has a js extension).

main.js is what we could call our bootstrap file. We’ll make ours look like this:

require([
	'bookshelf'
], function(bookshelf) {
	bookshelf.listBook();
});

Because we specified this file as our data-main in our html file, RequireJS will load it as soon as possible and it will be immediately executed. You’ll notice this has a lot of similarities to our previous modules but instead of calling define() it calls require(). The define() function–at least when dependencies are defined–really does three things: (1) loads the dependencies specified, (2) calls the callback function once dependencies are loaded, and (3) registers the return value from the callback function as the module. The require() function only does #1 and #2, not #3–hence the function names “define” vs. “require”. In the case of main.js, it’s just a bootstrap file. I don’t need to have a “main” module registered with RequireJS because nothing will be calling for it as a dependency.

Our bootstrap lists our “bookshelf” module as a dependency. Assuming the bookshelf module hasn’t already been registered with RequireJS, it will load bookshelf.js. Once it loads bookshelf.js, it will see that bookshelf has the book module listed as a dependency. If the book module hasn’t already been registered, it will then load book.js. Once that’s done and book and then bookshelf have registered their respective objects as modules with RequireJS, the callback in main.js will be executed and bookshelf will be passed through. At that point we can do whatever we want with bookshelf. If needed, we can list multiple module dependencies and they will all be passed into the callback as soon as they’re all loaded and registered with RequireJS.

Configuration

Previously I mentioned the concept of a base url. By default, the base url is whatever directory contains the bootstrap file. In my case, I put main.js under a js directory along with book.js and bookshelf.js. This means, in my case, my base url is /js/. Now let’s say instead of placing all my js files directly under the js directory, I moved book.js and bookshelf.js to /js/model/. Now my main.js would need to look like this:

require([
	'model/bookshelf'
], function(bookshelf) {
	bookshelf.listBook();
});

Now main knows the correct location of bookshelf.js. Likewise, bookshelf.js would list the book dependency as model/book even though book and bookshelf live in the same directory.

This brings us to RequireJS configuration. At the top of my bootstrap file, I usually perform my configuration. main.js might look like this:

require.config({
	baseUrl: '/another/path',
	paths: {
		'myModule': 'a/b/c/d/myModule'
		'templates': '../templates',
		'text': 'libs/text',
	}
});
 
require([
	'bookshelf'
], function(bookshelf) {
	bookshelf.listBook();
});

In this case, I’ve manually changed my base url to something completely different. Personally, I’ve never needed to configure this but it’s there to demonstrate one of the many configuration options available. I also demonstrated how to configure paths. Paths are really just shortcuts. In this case, rather than having to type out “a/b/c/d/myModule” when listing dependencies, I can just type “myModule”. I’ve set up a path (shortcut) for accessing a templates directory that is a sibling to my js directory. I’ve also set up a path (shortcut) for accessing the RequireJS text! plugin more easily.

Class Modules

So far, our modules have all been object instances; bookshelf was an object and book was an object. In reality, modules are very often classes. When using Backbone, modules are classes much more often than not. The bookshelf class needs the book class, for instance. It can then instantiate a bunch of books or whatever it needs to do using the book class. If an instance of the class needs to be passed to different Backbone views, for example, it would be passed through the recipient view’s constructor or other method. You’ll start to see that listing dependencies is similar to listing imports in languages like Java or ActionScript. It’s essentially giving you access to another class that you can then use within the class you’re defining. You just so happen have the ability to also define and retrieve object instances as modules if you really want to. Hopefully this will become more obvious in the next example.

RequireJS + Backbone

Using the knowledge from the previous articles in this series and our new-found knowledge of modules, let’s see an integrated example. In essence, we have a collection of book models. We’re calling the collection a bookshelf. We have a bookshelf view that loops through the books in the bookshelf, creating a book view for each book in the bookshelf. The book view displays information about the book. The views, frankly, are over-architected for the simple stuff we’re doing here, but I think this demonstrates the integration of RequireJS and Backbone nicely. If it’s still unclear, please post a comment and I’ll do my best to answer.

index.html:

<!DOCTYPE html>
<html>
	<head>
		<title>RequireJS Example</title>
		<script data-main="js/main" src="js/libs/require.js"></script>
	</head>
	<body/>
</html>

js/main.js:

require.config({
	'paths': {
		'jquery': 'libs/jquery',
		'backbone': 'libs/backbone',
		'underscore': 'libs/underscore'
	}
});
 
require([
	'view/bookshelf-view'
], function(BookshelfView) {
	$(document).ready(function() {
		new BookshelfView({
			el: $('body')
		});
	});
});

js/view/bookshelf-view.js:

define([
	'backbone',
	'underscore',
	'model/bookshelf',
	'view/book-view'
], function(Backbone, _, Bookshelf, BookView) {
	return Backbone.View.extend({
		initialize: function() {
			this.collection = new Bookshelf([
				{
					title: 'A Tale of Two Cities',
					author: 'Charles Dickens'
				},
				{
					title: 'The Good Earth',
					author: 'Pearl S. Buck'
				}
			]);
 
			this.render();
		},
 
		render: function() {
			this.collection.each(function(book) {
				var bookView = new BookView({
					model: book
				})
				this.$el.append(bookView.$el);
			}, this);
		}
	});
});

js/view/book-view.js:

define([
	'backbone',
	'underscore'
], function(Backbone, _) {
	return Backbone.View.extend({
		initialize: function() {
			this.render();
		},
 
		render: function() {
			this.$el.html('Title: ' + this.model.get('title') +
					'; Author: ' + this.model.get('author'));
		}
	});
});

js/model/bookshelf.js:

define([
	'backbone',
	'model/book'
], function(Backbone, Book) {
	return Backbone.Collection.extend({
		model: Book
	})
});

js/model/book.js:

define([
	'backbone'
], function(Backbone) {
	return Backbone.Model.extend({
		// Intended attributes:
		// title
		// author
		// genre
 
		defaults: {
			genre: 'historical'
		}
	})
});

Loading Non-Modules

Some libraries you want to use in your project don’t conform to the AMD spec. In fact, Backbone and Underscore have had their flirts with conforming to AMD but, at the moment of this writing, aren’t AMD modules. This means if we add backbone.js to our project and list the Backbone module as a dependency in one of our modules, it won’t work. RequireJS will load backbone.js, but nothing in backbone.js registers itself as a module with RequireJS. RequireJS will throw up its hands and say something like, “Well, I loaded the file, but there’s still no Backbone module.” But, you may have astutely observed that I did exactly that in my previous example and I didn’t seem to run into problems. Well, James Burke, the same guy that curates AMD and RequireJS, maintains a Backbone branch and Underscore branch that register themselves with RequireJS as modules when they are loaded. In my example above, I’m using these Backbone and Underscore branches–not the official trunk versions. Technically, you can use the official trunk versions, but some finagling must be done to get them to load in the right order using RequireJS plugins like order! or use! and then you would access the global Backbone and _ variables as would if you weren’t using RequireJS. Believe me, you won’t be the first one to go through your options and figure this one out.

Quite honestly, dealing with non-AMD libraries is by far the most frustrating part about working with RequireJS. Once you have them set up, though, RequireJS is silky smooth like butter on hot bread. The good news is that jquery does register itself as an AMD module so you don’t have to worry about that one.

Alright, so Backbone and Underscore aside, let’s say we just want to load a single non-AMD JavaScript library file we downloaded off the web. It doesn’t depend on anything else and we don’t want to modify its code to make it register itself as an AMD module. We just want to make sure the file is loaded and then just access the global variable like you normally would if you weren’t using RequireJS. Here’s an example:

define([
	'js/libs/coolLib.js'
], function() {
	console.log(window.coolLib);
});

A few things to notice here: First, our path to the file includes everything from the directory where our html file is located. This is unlike loading a module that includes everything after our “base url” (read above if you don’t remember what this is). Second, our path includes the extension. This is unlike loading a module where the extension is omitted. Third, because it’s not a module, RequireJS won’t pass anything into our callback function. At that point we just reference coolLib however the coolLib library dictates. RequireJS is just loading the file and, once it’s loaded, calls our callback function. Nothing special.

Loading Templates

Back in JavaScript Architecture: Underscore.js, we discussed how to break our HTML into templates to prevent it from mingling to closely with our JavaScript. In the examples we used, we put our HTML templates within script tags. I then posed the question, “You might rightfully be wondering how this is scalable if you start to have hundreds of templates in your html file or how you might be able to load them asynchronously only when needed.” This is also where RequireJS helps out.

RequireJS has a nice plugin called text!. You might think I’m really excited about it because I put an exclamation point next to it. While I do admit it’s pretty south-beach sexy, really that’s just the nomenclature of RequireJS plugins because you type something like “text!myTemplate” when using them. The text! plugin allows us to load in files of text–in our case, HTML templates. Let’s see how this works.

First we’ll download and place the text! plugin file in js/libs.

We’ll place book.tpl.html located under a templates directory that’s a sibling to our js directory:

<span class="label">Title:</span><span class="value"><%= title %></span><br/>
<span class="label">Author:</span><span class="value"><%= author %></span><br/>
<span class="label">Genre:</span><span class="value"><%= genre %></span>

Add some paths to our RequireJS configuration in our main.js to make it easier to use in our modules:

require.config({
	'paths': {
		'jquery': 'libs/jquery',
		'backbone': 'libs/backbone',
		'underscore': 'libs/underscore',
		'templates': '../templates',
		'text': 'libs/text'
	}
});

Then use the template in book-view.js:

define([
	'backbone',
	'underscore',
	'text!templates/book.tpl.html'
], function(Backbone, _, template) {
	return Backbone.View.extend({
		_template: _.template(template),
 
		initialize: function() {
			this.render();
		},
 
		render: function() {
			this.$el.html(this._template(this.model.toJSON()));
		}
	});
});

Notice that the template argument is a string variable holding the exact html as found in our template html file. Then, we use underscore to convert it to a compiled template. We run our book model attributes through the template on render(). Finally, we update our element’s inner html with the result.

So what about all those potential HTTP requests? Here’s where we optimize…

Optimization

We’ve broken down all our JavaScript and HTML into granular pieces. Now we potentially have hundreds of files and unless we do some optimization we would be making hundreds of HTTP requests. Fortunately, we can leverage the RequireJS optimizer.

Generally, you set up the optimizer to run on your server before deploying code. The RequireJS optimizer takes your app files, minifies them (shortens your code to make the files really small), and then concatenates them (smashes them together to make a single file). In the end, you end up with a single file that contains both your JavaScript and your HTML templates. After index.html loads RequireJS, it will load our main.js file. Our main.js file, this time, will not only contain our expected main.js code but all the minified, concatenated code of the rest of our app–both JavaScript and HTML templates. Everything in the file will register itself with RequireJS. When main starts asking for dependencies and those dependencies start asking for dependencies, RequireJS will recognize that all those modules have already been loaded and forego loading them again.

The optimizer smattering of options. You can optimize your app down to a few different files representing sections of your app instead of a single large file. You can also use different minifier libraries, exclude files from concatenation, or even minify CSS.

Learn More

We’ve covered a lot of content but there’s plenty more to learn about dependency management. The RequireJS website is a great place to start. If you’re interested in seeing more examples of Backbone + RequireJS, dig into this Todos App example. And, as always, feel free to provide feedback or ask questions below!

// Loading a language resource module:
resourceManager.loadResourceModule('http://aaronhardy.com/en_US_ResourceModule.swf');
 
// Loading a style module (e.g., a compiled font swf):
StyleManager.loadStyleDeclarations("http://aaronhardy.com/fonts/Astroid.swf");
 
// Loading miscellaneous modules:
var moduleInfo:IModuleInfo = ModuleManager.getModule('http://aaronhardy.com/MyModule.swf');
moduleInfo.load();

But these methods of importing modules result in errors like the following:

Unable to load resource module from http://aaronhardy.com/en_US_ResourceModule.swf
Error: Unable to load style(SWF is not a loadable module): http://aaronhardy.com/fonts/Astroid.swf.

One way to solve these issues is by using a crossdomain policy file on the server and then using a local apache instance to run the application. In my talks with the folks at Adobe, this seems to be their standard workflow which may be why we haven’t heard more about these problems. However, my workflow is to NOT have a local web hosting server running and I don’t want to have one running just to get around these errors.

As of Flex SDK 3.2, Adobe introduced a new parameter to IModuleInfo.load() for raw module bytes. As a result, we can now retrieve the remote module’s raw bytes using a URLLoader and then load them directly as a module using the IModuleInfo.load() method. The module is now part of the same security domain as the main application and no errors are thrown.

I’ve bundled up this logic into a class called ModuleMarshaller which is found below.

package com.aaronhardy
{
	import flash.events.ErrorEvent;
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IOErrorEvent;
	import flash.events.SecurityErrorEvent;
	import flash.net.URLLoader;
	import flash.net.URLLoaderDataFormat;
	import flash.net.URLRequest;
	import flash.utils.ByteArray;
 
	import mx.events.ModuleEvent;
	import mx.modules.IModuleInfo;
	import mx.modules.ModuleManager;
 
	/**
	 * Dispatched once module loading is complete.
	 */
	[Event(name="ready", type="mx.events.ModuleEvent")]
 
	/**
	 * Dispatched if an error is encountered while loading the module.
	 */
	[Event(name="error", type="mx.events.ModuleEvent")]
 
	/**
	 * Loads a remote module.  Specifically, this is a workaround to allow an application being run
	 * locally (not using a web server) to load a module residing on a remote server.
	 * Usually, when attemping to do so using resourceManager.loadResourceModule(),
	 * StyleManager.loadStyleDeclarations(), or IModuleInfo.load() without passing in bytes
	 * results in errors such as the following:
	 *
	 * Error: Unable to load resource module from http://aaronhardy.com/locales/en_US.swf
	 * Error: Unable to load style(SWF is not a loadable module): http://aaronhardy.com/fonts/Astroid.swf.
	 *
	 * Be aware that any module imported with this class may have access to anything within
	 * your application's security sandbox.
	 */
	public class ModuleMarshaller extends EventDispatcher
	{
		protected var url:String;
 
		/**
		 * Appears to need to be stored in the class scope, otherwise garbage collection
		 * wipes out some of the event handling within IModuleInfo.
		 */
		protected var module:IModuleInfo;
 
		/**
		 * Constructor.
		 * @param url The external module to load into the application.
		 */
		public function ModuleMarshaller(url:String)
		{
			this.url = url;
		}
 
		/**
		 * Starts the loading process by loading in the module as bytes.
		 */
		public function loadModule():URLLoader
		{
			var urlRequest:URLRequest = new URLRequest(url);
			var urlLoader:URLLoader = new URLLoader(urlRequest);
			urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
			urlLoader.addEventListener(Event.COMPLETE, bytesLoadedHandler);
			urlLoader.addEventListener(IOErrorEvent.IO_ERROR, errorHandler);
			urlLoader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, errorHandler);
			return urlLoader;
		}
 
		/**
		 * Once the module bytes are loaded, convert them back into a module within the
		 * application's security domain.
		 */
		protected function bytesLoadedHandler(event:Event):void
		{
			var styleModuleBytes:ByteArray = ByteArray(URLLoader(event.target).data);
			module = ModuleManager.getModule(url);
			module.addEventListener(ModuleEvent.READY, modReadyHandler);
			module.addEventListener(ModuleEvent.ERROR, errorHandler);
			module.load(null, null, styleModuleBytes);
		}
 
		/**
		 * Once the module information is loaded, use the factory to create an instance of the
		 * module.
		 */
		protected function modReadyHandler(event:ModuleEvent):void
		{
			ModuleManager.getModule(url).factory.create();
			dispatchEvent(event.clone());
		}
 
		/**
		 * Reports errors that may have occurred.
		 */
		protected function errorHandler(event:Event):void
		{
			if (event is ModuleEvent)
			{
				dispatchEvent(event.clone());
			}
			else if (event is ErrorEvent)
			{
				dispatchEvent(new ModuleEvent(ModuleEvent.ERROR, false, false, 0, 0,
					ErrorEvent(event).text));
			}
		}
 
	}
}

If you’re loading a style module, you may also want this class, which ensures the style module takes effect in your application immediately after the module is loaded.

package com.aaronhardy
{
	import mx.events.ModuleEvent;
 
	/**
	 * Provides the module marshalling functionality of ModuleMarshaller with the ability to
	 * update styles immediately after the module is loaded.
	 */
	public class StyleModuleMarshaller extends ModuleMarshaller
	{
		/**
		 * If true, forces an immediate update of the application's styles after the module is
		 * loaded.
		 */
		protected var updateStylesImmediately:Boolean = true;
 
		/**
		 * Constructor.
		 * @param url The external module to load into the application.
		 * @param update If true, forces an immediate update of the application's styles after
		 *        the module is loaded.
		 */
		public function StyleModuleMarshaller(url:String, updateStylesImmediately:Boolean=true)
		{
			super(url);
			this.updateStylesImmediately = updateStylesImmediately;
		}
 
		/**
		 * @inheritDoc
		 */
		override protected function modReadyHandler(event:ModuleEvent):void
		{
			ModuleManager.getModule(url).factory.create();
 
			if (updateStylesImmediately)
			{
				mx.core.Singleton.getInstance("mx.styles::IStyleManager2").styleDeclarationsChanged();
			}
 
			dispatchEvent(event.clone());
		}
	}
}

The Dirty Details

So, why does the ModuleMarshaller function without errors while Flex’s built-in classes do not? You might not care, but in case you do, here’s what I know–and don’t know. First, all the built-in functions end up using ModuleInfo.load() found in ModuleManager.as. This function uses a Loader to load in the contents of the module. When the loaded SWF file is accessible and ready for use (i.e., the Loader’s LoaderInfo object dispatches an Event.INIT event), ModuleInfo.initHandler() is called. In this function we have the following segment of code:

factoryInfo = new FactoryInfo();
 
try
{
    factoryInfo.factory = loader.content as IFlexModuleFactory;
}
catch(error:Error)
{
}
 
if (!factoryInfo.factory)
{
    var moduleEvent:ModuleEvent = new ModuleEvent(
        ModuleEvent.ERROR, event.bubbles, event.cancelable);
    moduleEvent.bytesLoaded = 0;
    moduleEvent.bytesTotal = 0;
    moduleEvent.errorText = "SWF is not a loadable module";
    dispatchEvent(moduleEvent);
    return;
}

Notice how it takes the content from the loader and attempt to cast it as an IFlexModuleFactory object. In this case, loader.content is NOT an IFlexModuleFactory instance, resulting in factoryInfo.factory being set to null. Later in the function, it checks to see if factoryInfo.factory is null. If it is, an error is thrown. This is the origin of the errors you see in your application.

So why does ModuleMarshaller work? When ModuleMarshaller makes this call:

module.load(null, null, styleModuleBytes);

It ultimately ends up in the same ModuleInfo.initHandler() function as we saw above. In both cases the Flex Builder debugger shows that loader.content is of type GeneratedResourceModule1975496797516746634_mx_core_FlexModuleFactory. However, when we load the module using the raw bytes loaded with a URLLoader, it IS able to cast the object as an IFlexModuleFactory object, resulting in a non-null factoryInfo.factory object and avoiding any error.

Why such similarity yet one is able to be cast while the other is not? I don’t know. That’s as far as I can go in my debugging quests with what’s open source. I assume it has to do with the Flash Player security but I haven’t read anything that would specifically explain why the content cannot be cast as an IFlexModuleFactory object when using built-in Flex module loading methods. If you can fill in the gap or have questions, please feel free to post a comment. Bon appetit!