… main.js is a concatenated and minified version of all the js. Just wondering why do you still need requirejs if you concatenate and minify your js in a single file [via r.js].

Is there an advantage of using requirejs in this instance? Or can you just straight target main.js?

I’ve seen 2 clients now who put all of their JavaScript into a single, large file vs. using classes, modules, and packages; traditional computer science concepts that Require does its best to enable in JavaScript.

There is a development build: load a bunch of js files, sometimes on the fly.

Development vs. Production Build (or deployment)

There is a production build: a single, minified, js file, up front.

Production allows me to have a small file with a single http request which can possibly lead to a faster app. However, it’s next to impossible to debug. If there is a problem, I cannot set a breakpoint in the code, nor identify what line, nor what file the issue is in.

In development, I can (sometimes) identify what file and on what line the issue is. I can also change the variables value at runtime to test things, see their current values, and run other console statements at runtime or while the code is paused to verify. Using Chrome you an even edit the code while it’s running to test. Finally, require allows loading classes on the fly. For some mobile apps where you don’t want to load everything at once, this leads to a faster app.

Concurrent Development With a Team (also called RAD or Rapid Application Development)

Development is actually a rabbit hole of reasons, though. For example, when you are working on a team who are all working on the same code base, I can be inside of the deviceEditView.js while another developer is handling all the data in the getAffiliateCDNService.js. When we go to check into source control, it’s highly unlikely we’ll have conflicts or have to merge because they are 2 separate files. As long as you communicate, this scales pretty well for larger applications and teams.

Relevant Encapsulation and Organization

Additionally, it’s easier to find code that’s relevant. If it’s one big-ole file, it’s harder to find the function or “area of functionality” you’re looking for whereas if it’s in a class, you know that that particular class is for a specific piece of functionality. This becomes even more relevant as your application gets larger and you start to utilize packages to organize “all of your services” and “all of your models” and “all of your models that just deal with user authentication and management”.

Unit Testing and Continuos Integration via Mocks/Fixtures

Yet another example is when you’re dealing with unit testing / mocking. It’s easier to mock a use of a class vs. a whole chunk of code in a large file. For example, if you’re trying to run some unit tests against parts of your application offline (check out Zombie JS), then you can write mocks or fixtures; basically mock services so your app “thinks” it’s hitting a Ruby on Rails back-end but in reality, it’s just making a function call to a class that returns fake data it needs after a timer of 3 seconds. You can then use require or some Dependency Injection framework to full fill those dependencies with Mocks vs. Reals. Without using classes, or separate files, it becomes challenging to do that.

Compensating for Pathetic/Non-existent Tooling

Also, the currently tooling in the market, namely Chrome, struggles to debug 13,000 lines of code or more. When they are in smaller class files of 300 lines or less, it”s more responsive. It’s also easier to tell a fellow developer “check line 102 of the DeviceItemRenderer” vs. “12,456”.

Intro

• Jesse Warden
• Software Consultant at Web App Solution
• growing software firm
• Require JS
• why, what, and some examples
• basic, not covering optimizations/compiling for production
• ActionScript, java, python, ruby, C#, Lua
• classes
• packages
• libraries
• scope

Why?

• code organization
• code scalability
• optimize code
• multi-developer teams
• nested dependencies
• ease of use vs. compilation
• asynchronous

What?

• define
• require
• config

Examples

• unit tests
• router example
• handle bars example
• typescript

The following article describes what Gaia and Robotlegs are, why you would use them, and how you go about using them together.

What?

Gaia: A framework for building Flash websites with built-in deep linking, modules, and code generation.

Robotlegs: A MVCS framework for Flex, Flash, and pure AS3 applications.

Why?

Gaia is great for building websites, but it’s just a platform for you to build on, a bunch of helpful scaffolding; it doesn’t prescribe a way to build your applications.  Specifically, you have to write your own code for Business logic and Application/Domain logic.  You still have to write code to hit back-end services, parse the returning XML/JSON/AMF, and act on that data.  You can do this just fine for smaller websites in Gaia; Gaia doesn’t get in your way, nor prescribe how to build your site.  However, for larger sites, it may get confusing on who does what, where that code goes, and how to work with other developers.

This is where an application framework like RobotLegs comes in.  You’re domain model goes in the Model classes, your Business logic goes in the Service classes, and your Domain/Application logic goes in your Commands & Mediators.

Examples: If a logged in User object needs to be persisted globally across pages in your site, put it on the Model.  If you have a large amount of web services to get dynamic data from, and each is different, some requiring parameters, create Services out of them.  If you need to do different things depending upon which user is logged in, and what permissions they have, utilize a Medaitor/Command for such code.  Gaia can just handle the state of your application and what it looks like.

Gaia builds your site, and RobotLegs makes it work with dynamic data.

While you can utilize this combination on smaller websites, it is recommend for larger, Enterprise sites.  Metrics include more than 12 pages each requiring dynamic data from a live middle tier, more than 10 web services, and/or a significant amount of application logic that the server doesn’t handle.

How?

1. Setup your Gaia project.
2. Drop your Robotlegs SWC into the “libs” folder.
3. Check “Export SWC” under File > Publish Settings.
4. Add the Robotlegs SWC to the Library Path (File > Publish Settings, Flash tab, Settings Button, Library Path tab, Browse To SWC button).
5. Open Main.as and instantiate your Robotlegs Context in the overridden “onAddedToStage” before it calls super, passing it “stage” as the first and only parameter.

override protected function onAddedToStage(event:Event):void
{
	stage.align = StageAlign.TOP_LEFT;
	stage.scaleMode = StageScaleMode.NO_SCALE;
	mainContext = new MainContext(stage); // notice before super
	super.onAddedToStage(event);
}

For Mediator’s, instead of a View reference, create an interface, and use a String for the class in mapMediator (more info below).

Mediator’s

Mediator’s are little tricky since Gaia is built on top of modules.  Since you don’t want to defeat the purpose of using modules in the first place, having separate SWF’s each containing unique content to save download/initialization time/memory usage, you need to utilize Robotleg’s built in support of this workflow.

Mediator’s can be created for Gaia Page classes, or View children of a Gaia Page class.  Not all Gaia pages necessarily need Mediator’s, only those that wish to interact with Robotlegs.

1. Create an interface for whatever View you wish to have a Mediator for; put the functions your Mediator needs for the View to have in the interface.
2. Have your View implement this Interface.
3. When registering your Mediator in the Context, do it like so:

mediatorMap.mapView("yourViewClass", YourMediator, IInterface);

First, notice the 1st parameter, the class name, is a String instead of a strongly-typed class name.  This ensures that your main.fla does not compile your View code into your main.swf.  It is only downloaded, initialized, and loaded into memory once the user navigates to that page.

Second, notice the 3rd optional parameter is the interface you created.  This ensure’s Robotlegs know’s what class to look for to be Mediated when the Gaia page is navigated to and your View comes onto the DisplayList, and thus create your Mediator with it’s injected View.  This also ensure’s you can still get strong-typing while talking with your View in your Mediator.

Conclusions

For larger applications, I would encourage the use of Flex.  However, for multimedia heavy sites, it’s a lot easier to utilize Gaia since it already has modules built in, they are easier to work with and unload than Flex modules, as well as all the other media centric features that Gaia comes with.  Also keep in mind that just because you utilize Robotlegs doesn’t shield you from dependencies like Flex does via -load-externs.  If you have a Gaia page class that imports a class that has dependencies, that Gaia page will import them, either negating the positives that modules give you or causing your application not to work/compile.

When building Flash websites, it’s a given you’ll probably utilize Gaia.  For larger sites, though, you may wish to utilize a framework to help manage the large amounts of code you’ll accrue for hitting a variety of services, as well as managing application logic (if the user is logged in, do this, else do this).  Robotlegs is a fine choice because of it’s support for dynamic Mediators through the use of Interfaces shown above.

Questions about Gaia?  Documentation | Forum

Questions about Robotlegs? Documentation & Forum